From report at bugs.python.org  Tue Jun  1 00:20:15 2010
From: report at bugs.python.org (Christian Schubert)
Date: Mon, 31 May 2010 22:20:15 +0000
Subject: [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>


New submission from Christian Schubert <bugs at apexo.de>:

invoking select.poll.poll() concurrently from multiple threads frequently yields garbage in one thread:

while poll_poll in thread 1 is parsing its result, another thread 2 calling poll may overwrite revents; assuming poll_result was 1 in thread 1 and thread 2 managed to clear all revents before thread 1 started scanning ufds, thread 1 would iterate straight through all ufds, past its bounds (no bound checks there), and return the first out-of-bounds entry that happens to have revents != 0

this issue needs at least documentation (although bounds-checking to prevent garbage in the result wouldn't hurt)

also, since there doesn't seem to be any locking w/ regards to ufds, it might be possible to corrupt python's heap, by concurrently invoking poll_register and poll_poll. poll_register could move the ufds array to another location while resizing it and poll_poll would subsequently overwrite memory that is not allocated anymore or allocated by someone else (did not test that)

python 2.5.5

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 106815
nosy: apexo, docs at python
priority: normal
severity: normal
status: open
title: select.poll is not thread safe
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Jun  1 00:24:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 May 2010 22:24:09 +0000
Subject: [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1275344649.95.0.716754337947.issue8865@psf.upfronthosting.co.za>


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

Do you have a script that reproduces it?

----------
assignee: docs at python -> 
components:  -Documentation
nosy: +pitrou
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

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

From report at bugs.python.org  Tue Jun  1 00:50:12 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 31 May 2010 22:50:12 +0000
Subject: [issue8866] socket.getaddrinfo() should support keyword arguments
In-Reply-To: <1275346212.88.0.3146354655.issue8866@psf.upfronthosting.co.za>
Message-ID: <1275346212.88.0.3146354655.issue8866@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

As of now socket.getaddrinfo() only supports positional arguments, so that if I want to, say, specify "flags" argument I'm forced to specify "0" for other missing arguments:

>>> socket.getaddrinfo("www.python.org", 0, 0, 0, socket.SOL_TCP)
[(2, 1, 6, '', ('82.94.164.162', 0)), (10, 1, 6, '', ('2001:888:2000:d::a2', 0, 0, 0))]
>>>
>>> socket.getaddrinfo("www.python.org", flags=socket.SOL_TCP)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: getaddrinfo() takes no keyword arguments
>>>

----------
components: Library (Lib)
messages: 106817
nosy: exarkun, giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: socket.getaddrinfo() should support keyword arguments
versions: Python 3.2

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

From report at bugs.python.org  Tue Jun  1 00:52:19 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 31 May 2010 22:52:19 +0000
Subject: [issue8866] socket.getaddrinfo() should support keyword arguments
In-Reply-To: <1275346212.88.0.3146354655.issue8866@psf.upfronthosting.co.za>
Message-ID: <1275346339.69.0.986122127955.issue8866@psf.upfronthosting.co.za>


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

...also, the returning tuples could be named tuples instead.

----------

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

From report at bugs.python.org  Tue Jun  1 00:52:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 May 2010 22:52:21 +0000
Subject: [issue8864] multiprocessing: undefined struct/union member:
	msg_control
In-Reply-To: <1275342146.08.0.266544809639.issue8864@psf.upfronthosting.co.za>
Message-ID: <1275346341.77.0.802008656849.issue8864@psf.upfronthosting.co.za>


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


----------
nosy: +movement, zooko

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

From report at bugs.python.org  Tue Jun  1 01:22:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 May 2010 23:22:37 +0000
Subject: [issue8867] serve.py (using wsgiref) cannot serve Python docs under
	Python3 due to encoding issues
In-Reply-To: <1275348157.42.0.660423745202.issue8867@psf.upfronthosting.co.za>
Message-ID: <1275348157.42.0.660423745202.issue8867@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

If you do a 'make serve' in the docs directory (after doing a make html, of course) and try to open the What's New link in the served doc pages, the following error results:

ValueError: Unicode data must contain only code points representable in ISO-8859-1 encoding

----------
components: Library (Lib)
messages: 106819
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: serve.py (using wsgiref) cannot serve Python docs under Python3 due to encoding issues
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Jun  1 01:54:43 2010
From: report at bugs.python.org (John Levon)
Date: Mon, 31 May 2010 23:54:43 +0000
Subject: [issue8864] multiprocessing: undefined struct/union member:
	msg_control
In-Reply-To: <1275342146.08.0.266544809639.issue8864@psf.upfronthosting.co.za>
Message-ID: <1275350083.23.0.880687640297.issue8864@psf.upfronthosting.co.za>


John Levon <movement at users.sourceforge.net> added the comment:

This appears to be one of the few cases where there's incompatibilities between different versions of the standards. Old BSD sockets use msg_accrights*, whereas the more modern way is msg_control*
pointing to a struct cmsghdr.

In terms of user/kernel interface, this difference is encoded as a MSG_XPG4_2 flag via a __xnet_recvmsg() re-define depending upon #ifdef _XPG4_2.

The result being that it's impossible to use C99 and a modern struct msghdr together. This is less than ideal and I'm following it up internally.

In terms of getting Python building again, it should be sufficient to define _XPG4_2 for the multiprocessing module compile only.

----------

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

From report at bugs.python.org  Tue Jun  1 03:34:11 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Jun 2010 01:34:11 +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: <1275356051.6.0.566311776287.issue8845@psf.upfronthosting.co.za>


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

Committed in r81632.

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

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

From report at bugs.python.org  Tue Jun  1 03:49:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Jun 2010 01:49:16 +0000
Subject: [issue7583] Improve explanation of tab expansion in doctests
In-Reply-To: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>
Message-ID: <1275356956.88.0.796053308276.issue7583@psf.upfronthosting.co.za>


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

In the absence of feedback about the doc patch, I have applied it in r81634.

@techtonic: if I recall correctly I explained in your issue that had the patch what the problem was.  Short summary: there are two equally valid ways in which tabs in the output and the spacing in the sample output could be reconciled; both have their problems.  Therefore it is better to have the user handle it explicitly one way or another.

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

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

From report at bugs.python.org  Tue Jun  1 05:19:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 01 Jun 2010 03:19:23 +0000
Subject: [issue5023] Segfault in datetime.time.strftime("%z")
In-Reply-To: <1232556285.78.0.999173961019.issue5023@psf.upfronthosting.co.za>
Message-ID: <1275362363.35.0.870996981868.issue5023@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Philipp,

Why do you think you see the same problem as Eric?

Can you set a trace on &tuple and see when it gets modified?

Do you see the crash with zone_failure.py, test_datetime.py or both?

----------

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

From report at bugs.python.org  Tue Jun  1 05:38:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 01 Jun 2010 03:38:57 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1275363537.73.0.966478848772.issue8860@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Mark> (2) seems like overkill to me.

I agree, however it would be interesting to figure out when accumulated errors can produce an inaccurate result.  ISTM that leftover is the sum of up to 7 doubles each between 0 and 1 which is then rounded to the nearest integer.  I don't see how accumulated error can exceed 1 and affect the result.

----------

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

From report at bugs.python.org  Tue Jun  1 05:54:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 01 Jun 2010 03:54:41 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1275364481.73.0.412336942918.issue8860@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I wonder if it would be justified to expose something like

int
_PyLong_IsOdd(PyObject *self)
{
   PyLongObject *lo = (PyLongObject *)self;
   return Py_SIZE(lo) != 0 && ((lo->ob_digit[0] & 1) != 0);
}

in longobject.h?

----------

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

From report at bugs.python.org  Tue Jun  1 07:21:03 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 01 Jun 2010 05:21:03 +0000
Subject: [issue8864] multiprocessing: undefined struct/union member:
	msg_control
In-Reply-To: <1275342146.08.0.266544809639.issue8864@psf.upfronthosting.co.za>
Message-ID: <1275369663.4.0.716082224212.issue8864@psf.upfronthosting.co.za>


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

Defining _XPG4_2 is surely the wrong thing to do, right? It's an internal flag only, not meant to be used by applications.

----------

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

From report at bugs.python.org  Tue Jun  1 08:35:22 2010
From: report at bugs.python.org (Christian Schubert)
Date: Tue, 01 Jun 2010 06:35:22 +0000
Subject: [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1275374122.79.0.768137848872.issue8865@psf.upfronthosting.co.za>


Christian Schubert <bugs at apexo.de> added the comment:

okay, I've managed to put together a script that fairly consistently reproduces the problem on my (core2 duo 2,something GHz) machine

some parameters (sleep times) are randomized in each iteration, the script runs for 30 iterations, each for 1 second, and counts the number of events where the fd looks bogus (max 1 per iteration); some other events (fd correct, revents bogus are also reported, but not counted)

example output:
poll returned [(-3, 65535)], we were looking for fd 3
poll returned [(-3, 65535)], we were looking for fd 3
poll returned [(-3, 65535)], we were looking for fd 3
poll returned [(-3, 65535)], we were looking for fd 3
poll returned [(-3, 65535)], we were looking for fd 3
poll returned [(-1, 65535)], we were looking for fd 3
poll returned [(-1, 65535)], we were looking for fd 3
poll returned [(-1627358347, 60497)], we were looking for fd 3
should not get here; poll returned [(3, 0)]
poll returned [(-3, 65535)], we were looking for fd 3
9 events in 30 iterations

----------
Added file: http://bugs.python.org/file17510/select_threads.py

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

From report at bugs.python.org  Tue Jun  1 08:59:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 01 Jun 2010 06:59:37 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1275375577.66.0.214035966135.issue8860@psf.upfronthosting.co.za>


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

The accumulated error doesn't need to exceed 1;  it just needs to be enough to make (e.g.) leftover appear to be >= 0.5 when it's actually just less than 0.5.  It shouldn't be too hard to find examples where this happens, but I haven't thought about it.

> I wonder if it would be justified to expose something like
> int _PyLong_IsOdd(PyObject *self) {...}

Yes, that could work.  I'd be happier with this if there are other uses (even within longobject.c);  there might well be, but I haven't looked.  I also have a mild preference for _PyLong_IsEven over _PyLong_IsOdd.  :)

----------

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

From report at bugs.python.org  Tue Jun  1 09:09:28 2010
From: report at bugs.python.org (Christian Schubert)
Date: Tue, 01 Jun 2010 07:09:28 +0000
Subject: [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1275376168.66.0.275641078025.issue8865@psf.upfronthosting.co.za>


Christian Schubert <bugs at apexo.de> added the comment:

the other issue (poll_register freeing data structures that poll_poll currently uses) can be reproduced by the attached script (at least I can)

depending on the parameters/circumstances it either segfaults or prints garbage results from poll, e.g. [(1684955474, 28192)]; the expected result would be [(3, 1)]

----------
Added file: http://bugs.python.org/file17511/concurrent_poll_and_register.py

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

From report at bugs.python.org  Tue Jun  1 10:02:58 2010
From: report at bugs.python.org (Philipp Gortan)
Date: Tue, 01 Jun 2010 08:02:58 +0000
Subject: [issue5023] Segfault in datetime.time.strftime("%z")
In-Reply-To: <1232556285.78.0.999173961019.issue5023@psf.upfronthosting.co.za>
Message-ID: <1275379378.0.0.106340554655.issue5023@psf.upfronthosting.co.za>


Philipp Gortan <mephinet at gmx.net> added the comment:

Unfortunately, I'm no longer able to reproduce this issue as I upgraded to gcc 4.3 sometime within the last nine months...
With 4.3, I don't see this segfault any longer.

----------

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

From report at bugs.python.org  Tue Jun  1 10:31:12 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 01 Jun 2010 08:31:12 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1275381072.68.0.694530842599.issue8860@psf.upfronthosting.co.za>


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

An example where getting correct rounding is awkward: the following rounds up, with or without the patch:

>>> datetime.timedelta(seconds=0.6112295)
datetime.timedelta(0, 0, 611230)

But in this case, the result should actually be rounded down (with either rounding mode), since the exact value of float('0.6112295') is a little less than 0.6112295:

>>> print(Decimal(0.6112295))
0.61122949999999998116351207499974407255649566650390625

The problem is that leftover_us ends up being exactly 0.5 in this case.  Again, this could be worked around if we really care, but I'm not convinced it's worth it.

----------

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

From report at bugs.python.org  Tue Jun  1 10:35:02 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 01 Jun 2010 08:35:02 +0000
Subject: [issue8867] serve.py (using wsgiref) cannot serve Python docs under
	Python3 due to encoding issues
In-Reply-To: <1275348157.42.0.660423745202.issue8867@psf.upfronthosting.co.za>
Message-ID: <1275381302.77.0.340865361278.issue8867@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/issue8867>
_______________________________________

From report at bugs.python.org  Tue Jun  1 11:36:18 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 01 Jun 2010 09:36:18 +0000
Subject: [issue8853] getaddrinfo should accept port of type long
In-Reply-To: <1275155293.8.0.373298822378.issue8853@psf.upfronthosting.co.za>
Message-ID: <1275384978.45.0.90067524158.issue8853@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/issue8853>
_______________________________________

From report at bugs.python.org  Tue Jun  1 14:18:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Jun 2010 12:18:44 +0000
Subject: [issue4769] b64decode should accept strings or bytes
In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za>
Message-ID: <1275394724.01.0.128751514231.issue4769@psf.upfronthosting.co.za>


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

The patch appears to be fixing the wrong functions.  It is decode that needs to accept unicode.  Encode should still be restricted to bytes.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Tue Jun  1 14:25:54 2010
From: report at bugs.python.org (John Levon)
Date: Tue, 01 Jun 2010 12:25:54 +0000
Subject: [issue8864] multiprocessing: undefined struct/union member:
	msg_control
In-Reply-To: <1275342146.08.0.266544809639.issue8864@psf.upfronthosting.co.za>
Message-ID: <1275395154.43.0.75755619195.issue8864@psf.upfronthosting.co.za>


John Levon <movement at users.sourceforge.net> added the comment:

Right, it should be one of the "official" ways of enabling that.

----------

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

From report at bugs.python.org  Tue Jun  1 15:09:27 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 01 Jun 2010 13:09:27 +0000
Subject: [issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum
	recursion depth exceeded in cmp
In-Reply-To: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za>
Message-ID: <1275397767.99.0.85828774593.issue8797@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

This is fixed in r81636, r81637, r81638, r81637.
Just like the Digest Authentication, the urllib2 will try for 5 times before failing for any authentication failure ( It won't lead to recursion).

I had a thought that Basic Authentication need not be retried (no where in the RFC it mentions about it), but I found some references that clients do present the dialog a couple of times for retry on wrong authentication, so we are going for the same.

This is tested with actual resource setup. Closing this issue as this bug is fixed.

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

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

From report at bugs.python.org  Tue Jun  1 15:48:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Jun 2010 13:48:48 +0000
Subject: [issue1368247] unicode in email.MIMEText and email/Charset.py
Message-ID: <1275400128.55.0.603112232396.issue1368247@psf.upfronthosting.co.za>


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

I don't think either of the previous patches are correct.  I found a note in Issue1685453 that Barry would like for this to work, and after poking around in the code for a bit I think it can be done without breaking anything.

Attached is a patch that adds unicode support to MIMEText, including unit tests and docs updates.  Note that it is necessary to specify a charset if you have non-ASCII text in your unicode string, since the default charset is us-ascii.  The unit tests confirm this behavior.

Now the question is, is this a bug-fix or an enhancement?  I *think* it is safe to apply and backport, since I think the only behavior it changes is to make unicode input work, whereas before it would give a traceback.  But I've been wrong before :(

----------
resolution: invalid -> fixed
stage: committed/rejected -> patch review
versions: +Python 3.2 -Python 3.0
Added file: http://bugs.python.org/file17512/mimetext_unicode_input.patch

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

From report at bugs.python.org  Tue Jun  1 15:54:04 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 01 Jun 2010 13:54:04 +0000
Subject: [issue8618] test_winsound fails when no playback devices configured
In-Reply-To: <1273019000.91.0.843326391671.issue8618@psf.upfronthosting.co.za>
Message-ID: <1275400444.88.0.946980216647.issue8618@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Committed in r81640 through r81643

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

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

From report at bugs.python.org  Tue Jun  1 15:56:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Jun 2010 13:56:36 +0000
Subject: [issue1368247] unicode in email.MIMEText and email/Charset.py
Message-ID: <1275400596.03.0.826563347686.issue1368247@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file17512/mimetext_unicode_input.patch

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

From report at bugs.python.org  Tue Jun  1 15:56:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Jun 2010 13:56:50 +0000
Subject: [issue1368247] unicode in email.MIMEText and email/Charset.py
Message-ID: <1275400610.61.0.795637393489.issue1368247@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file17513/mimetext_unicode_input.patch

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

From report at bugs.python.org  Tue Jun  1 16:05:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Jun 2010 14:05:44 +0000
Subject: [issue1368247] unicode in email.MIMEText and email/Charset.py
Message-ID: <1275401144.35.0.957561085878.issue1368247@psf.upfronthosting.co.za>


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

Ah, it's not 100% true that it doesn't change "working" behavior.  Before the patch, the first example in this ticket doesn't raise an error until the as_string call.  After this patch, the error is raised as soon as MIMEText is called without the charset parameter.  Since without the patch the code still fails eventually, I think this is an acceptable behavior change for a bug fix, but it does make me a little nervous :)

Updated patch with doc change to Message.set_charset attached.

----------
Added file: http://bugs.python.org/file17514/mimetext_unicode_input.patch

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

From report at bugs.python.org  Tue Jun  1 16:13:03 2010
From: report at bugs.python.org (Michiel de Hoon)
Date: Tue, 01 Jun 2010 14:13:03 +0000
Subject: [issue8868] Framework install does not behave as a framework
In-Reply-To: <1275401583.76.0.0937518467482.issue8868@psf.upfronthosting.co.za>
Message-ID: <1275401583.76.0.0937518467482.issue8868@psf.upfronthosting.co.za>


New submission from Michiel de Hoon <mdehoon at users.sourceforge.net>:

(The discussion for this bug started on the pythonmac-sig mailing list; see http://mail.python.org/pipermail/pythonmac-sig/2010-May/022362.html)

When I try to install Python as a framework:

./configure --enable-framework
make
make install

then Python gets installed under /Library/Frameworks/Python.framework/Versions/2.7, but it doesn't seem to function as a framework:

>>> import MacOS
>>> MacOS.WMAvailable()
False
>>> 

Python 2.6.5 returns True here. This is important for GUI extension modules; such modules do not interact correctly with the window manager if Python is not installed as a framework.

I see the same behavior with the current Python in trunk with Mac OS X 10.4 and 10.5 both with Python installed from source and the precompiled python 2.7b2. Python revision 77030 seems to be the last revision without this problem. In revision 77031, posix_spawn() was introduced instead of execv() in pythonw.c to start the Python executable.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 106838
nosy: mdehoon, ronaldoussoren
priority: normal
severity: normal
status: open
title: Framework install does not behave as a framework
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun  1 16:17:28 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 01 Jun 2010 14:17:28 +0000
Subject: [issue8868] Framework install does not behave as a framework
In-Reply-To: <1275401583.76.0.0937518467482.issue8868@psf.upfronthosting.co.za>
Message-ID: <1275401848.19.0.0614577783207.issue8868@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The pythonw executable always uses execv on OSX 10.4 because posix_spawnv isn't available there.

A possibly significant change is the value of argv[0] as passed to the Python.app executable.

Could you check if this patch fixes the issue?


Index: Mac/Tools/pythonw.c
===================================================================
--- Mac/Tools/pythonw.c	(revision 81605)
+++ Mac/Tools/pythonw.c	(working copy)
@@ -149,6 +149,8 @@
 main(int argc, char **argv) {
     char* exec_path = get_python_path();
 
+    argv[0] = exec_path;
+
 #ifdef HAVE_SPAWN_H
 
     /* We're weak-linking to posix-spawnv to ensure that

----------

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

From report at bugs.python.org  Tue Jun  1 16:23:22 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 01 Jun 2010 14:23:22 +0000
Subject: [issue8868] Framework install does not behave as a framework
In-Reply-To: <1275401583.76.0.0937518467482.issue8868@psf.upfronthosting.co.za>
Message-ID: <1275402202.55.0.241827650728.issue8868@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Note that the subject is not entirely correct: the framework install is a framework install, but the python commandline doesn't behave like an application bundle.

----------
priority: normal -> high
stage:  -> needs patch

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

From report at bugs.python.org  Tue Jun  1 16:40:38 2010
From: report at bugs.python.org (stier08)
Date: Tue, 01 Jun 2010 14:40:38 +0000
Subject: [issue8869] execfile does not work with UNC paths
In-Reply-To: <1275403238.02.0.475988525563.issue8869@psf.upfronthosting.co.za>
Message-ID: <1275403238.02.0.475988525563.issue8869@psf.upfronthosting.co.za>


New submission from stier08 <stier08 at gmail.com>:

execfile() builtin function does not work with UNC paths on Windows platform (Windows 7 x64 has been tested, python 2.6.5)

Since standard IO operations successfully process UNC paths, therefore this behavior of execfile() seems to be a bug.

Code to reproduce (assuming drive c: is present and you have rw permissions)
>>> a=u'\\\\?\\c:\\a.py'
>>> open(a,"w").write("print 'hellow'") # successful write to UNC file 
>>> file(a).read() # successful read from UNC file 
"print 'hellow'"
>>> execfile(a) # ERROR
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory: '\\\\?\\c:\\a.py'

See description of UNC naming convention
at msdn http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx
at wikipedia http://en.wikipedia.org/wiki/Path_(computing)#Uniform_Naming_Convention

----------
components: Unicode, Windows
messages: 106841
nosy: stier08
priority: normal
severity: normal
status: open
title: execfile does not work with UNC paths
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun  1 16:54:14 2010
From: report at bugs.python.org (Tim Golden)
Date: Tue, 01 Jun 2010 14:54:14 +0000
Subject: [issue8869] execfile does not work with UNC paths
In-Reply-To: <1275403238.02.0.475988525563.issue8869@psf.upfronthosting.co.za>
Message-ID: <4C051F10.8030208@timgolden.me.uk>


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

Since execfile is basically shorthand for exec (open (filename).read ()),
and since open (filename) *does* support the full range of filepath
syntax on Windows, and since execfile has been removed in py3k in favour
of exec (open ...)), and since Python 2.x is nearing its end-of-life,
I doubt this issue will garner much sympathy.

I haven't actually looked at the code to discover just *why* execfile
doesn't support that style of filename. But is there any reason you
can't use exec (open (...))?

----------
nosy: +tim.golden

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

From report at bugs.python.org  Tue Jun  1 17:18:19 2010
From: report at bugs.python.org (Michiel de Hoon)
Date: Tue, 01 Jun 2010 15:18:19 +0000
Subject: [issue8868] Framework install does not behave as a framework
In-Reply-To: <1275401583.76.0.0937518467482.issue8868@psf.upfronthosting.co.za>
Message-ID: <1275405499.47.0.35737199106.issue8868@psf.upfronthosting.co.za>


Michiel de Hoon <mdehoon at users.sourceforge.net> added the comment:

The patch fixes the problem on Mac OS X 10.4. I'll try on 10.5 tomorrow.
Thanks!

----------

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

From report at bugs.python.org  Tue Jun  1 17:49:22 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 01 Jun 2010 15:49:22 +0000
Subject: [issue8869] execfile does not work with UNC paths
In-Reply-To: <1275403238.02.0.475988525563.issue8869@psf.upfronthosting.co.za>
Message-ID: <1275407362.47.0.0449070610722.issue8869@psf.upfronthosting.co.za>


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

Reproduced on WinXP.
execfile() does not work because it calls the system function stat(); 
this function does accept UNC paths (like \\machine\share\file), but not paths which contain a wildcard character ('?' or '*')

I suggest to remove the leading '\\\\?\\'.

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

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

From report at bugs.python.org  Tue Jun  1 18:12:29 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 01 Jun 2010 16:12:29 +0000
Subject: [issue8864] multiprocessing: undefined struct/union member:
	msg_control
In-Reply-To: <1275350083.23.0.880687640297.issue8864@psf.upfronthosting.co.za>
Message-ID: <C311201B-4152-48FE-8805-A41FE7C79B61@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On 2010-05-31, at 4:54 PM, John Levon wrote:

> In terms of getting Python building again, it should be sufficient to define _XPG4_2 for the multiprocessing module compile only.

I can verify that the following patch works around this issue (for now);

--- python.org/Modules/_multiprocessing/multiprocessing.c       2010-05-31 17:04:08.499559243 -0700
+++ python/Modules/_multiprocessing/multiprocessing.c   2010-05-31 17:04:28.568723434 -0700
@@ -6,6 +6,11 @@
  * Copyright (c) 2006-2008, R Oudkerk --- see COPYING.txt
  */

+/* 
+ * Workaround for http://bugs.python.org/issue8864#msg106820
+ */
+#define _XPG4_2
+
 #include "multiprocessing.h"

 #ifdef SCM_RIGHTS

On 2010-06-01, at 5:25 AM, John Levon wrote:

> Right, it should be one of the "official" ways of enabling that.

So I presume this should be the right way to fix this bug?

----------

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

From report at bugs.python.org  Tue Jun  1 18:40:18 2010
From: report at bugs.python.org (Jess Austin)
Date: Tue, 01 Jun 2010 16:40:18 +0000
Subject: [issue5434] datetime.monthdelta
In-Reply-To: <1236402290.49.0.02662803662.issue5434@psf.upfronthosting.co.za>
Message-ID: <1275410418.05.0.498943364241.issue5434@psf.upfronthosting.co.za>


Jess Austin <jess.austin at gmail.com> added the comment:

Yeah, the masses have spoken, and their silence is deafening.  I was going to downplay the "health" of the package based on the number of downloads, but then I looked at the "futures" page.  b^)  Seriously, getting this in would require a core developer wanting it in, and at this point it seems none do.

On the subject of float operations, while there may be some question about the integerness or floatness of timedelta, monthdelta is definitely an integer.  As monthdelta already supports multiplication by integers and floor division by integers or monthdeltas, I don't see anything missing.  To use monthdeltas with floats is to miss the point entirely.

----------
status: pending -> open

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

From report at bugs.python.org  Tue Jun  1 18:40:50 2010
From: report at bugs.python.org (John Levon)
Date: Tue, 01 Jun 2010 16:40:50 +0000
Subject: [issue8864] multiprocessing: undefined struct/union member:
	msg_control
In-Reply-To: <1275342146.08.0.266544809639.issue8864@psf.upfronthosting.co.za>
Message-ID: <1275410450.92.0.935414898348.issue8864@psf.upfronthosting.co.za>


John Levon <movement at users.sourceforge.net> added the comment:

defining _XOPEN_SOURCE=600 or similar is better, as Martin pointed out.

----------

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

From report at bugs.python.org  Tue Jun  1 18:47:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 01 Jun 2010 16:47:36 +0000
Subject: [issue8864] multiprocessing: undefined struct/union member:
	msg_control
In-Reply-To: <1275342146.08.0.266544809639.issue8864@psf.upfronthosting.co.za>
Message-ID: <1275410856.88.0.766313060552.issue8864@psf.upfronthosting.co.za>


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

Would such a workaround also be necessary if we want to add support for recvmsg() to the socket module (as in issue6560), or is it totally unrelated?

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

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

From report at bugs.python.org  Tue Jun  1 18:57:09 2010
From: report at bugs.python.org (John Levon)
Date: Tue, 01 Jun 2010 16:57:09 +0000
Subject: [issue8864] multiprocessing: undefined struct/union member:
	msg_control
In-Reply-To: <1275342146.08.0.266544809639.issue8864@psf.upfronthosting.co.za>
Message-ID: <1275411429.75.0.416031981758.issue8864@psf.upfronthosting.co.za>


John Levon <movement at users.sourceforge.net> added the comment:

Yes, we would almost certainly want something similar.

----------

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

From report at bugs.python.org  Tue Jun  1 19:27:56 2010
From: report at bugs.python.org (stier08)
Date: Tue, 01 Jun 2010 17:27:56 +0000
Subject: [issue8869] execfile does not work with UNC paths
In-Reply-To: <1275403238.02.0.475988525563.issue8869@psf.upfronthosting.co.za>
Message-ID: <1275413276.24.0.309293340301.issue8869@psf.upfronthosting.co.za>


stier08 <stier08 at gmail.com> added the comment:

yep exec (open (...)) is OK here thanks

----------

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

From report at bugs.python.org  Tue Jun  1 19:56:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 01 Jun 2010 17:56:52 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1275415012.12.0.149529474732.issue8591@psf.upfronthosting.co.za>


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

I?ve started to review your patch but I find it a bid unwieldy to read. Would you mind exporting changesets to patches? I tried to look at your repo, but didn?t know which branch to look at.

So, thanks for giving us the occasion of thinking about the patch workflow. Using changesets seems more natural since we use Bitbucket, while OTOH using regular diffs can streamline the history and remove unnecessary details (e.g. I?m not sure we want branch names to clutter the history forever (see http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ for more info)). Would it be too much of a hassle to provide links or a Mercurial bundle of a set of small changesets? Having different patches would help us separate the non-controversial stuff (whitespace) from the refactoring and improvements.

That said, I can offer a few remarks on the patch.

- Don?t put editor settings in the files.

- Changing ?if s in 'yn'? to ?if s in ('y', 'n')? is not really an improvement. It?s not more readable to always use tuples or frozensets for membership testing; str has __contains__ for a reason :)

- Not sure how your print_ indirection is helpful.

- I don?t know how much reST we want in the docstrings: None, some constructs, Sphinx extensions?

Don?t worry if there are no replies in a few days, people are pretty busy. I?ll ask about the meta-issues (workflow, reST) on the ML if Tarek doesn?t answer here. Cheers :)

----------

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

From report at bugs.python.org  Tue Jun  1 20:38:01 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 01 Jun 2010 18:38:01 +0000
Subject: [issue8870] --user-access-control=force produces invalid installer on
	Vista
In-Reply-To: <1275417481.6.0.247175279763.issue8870@psf.upfronthosting.co.za>
Message-ID: <1275417481.6.0.247175279763.issue8870@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Running `python setup.py bdist_wininst --user-access-control=force` produces invalid installer that fails to install with the error message:

Failed to start elevated process (ShellExecute returned 5)

----------
assignee: tarek
components: Distutils
messages: 106852
nosy: tarek, techtonik
priority: normal
severity: normal
status: open
title: --user-access-control=force produces invalid installer on Vista
type: crash
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Jun  1 20:56:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 01 Jun 2010 18:56:06 +0000
Subject: [issue6641] strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1275418566.42.0.898994361765.issue6641@psf.upfronthosting.co.za>


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


----------
nosy: +merwok

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

From report at bugs.python.org  Tue Jun  1 21:08:13 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 01 Jun 2010 19:08:13 +0000
Subject: [issue8867] serve.py (using wsgiref) cannot serve Python docs under
	Python3 due to encoding issues
In-Reply-To: <1275348157.42.0.660423745202.issue8867@psf.upfronthosting.co.za>
Message-ID: <1275419293.41.0.492446594072.issue8867@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/issue8867>
_______________________________________

From report at bugs.python.org  Tue Jun  1 21:08:26 2010
From: report at bugs.python.org (Jess Austin)
Date: Tue, 01 Jun 2010 19:08:26 +0000
Subject: [issue5434] datetime.monthdelta
In-Reply-To: <1236402290.49.0.02662803662.issue5434@psf.upfronthosting.co.za>
Message-ID: <1275419306.35.0.0704336192377.issue5434@psf.upfronthosting.co.za>


Changes by Jess Austin <jess.austin at gmail.com>:


----------
status: open -> pending

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

From report at bugs.python.org  Tue Jun  1 21:22:19 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 01 Jun 2010 19:22:19 +0000
Subject: [issue8871] --user-access-control=auto has no effect
In-Reply-To: <1275420139.65.0.104008426141.issue8871@psf.upfronthosting.co.za>
Message-ID: <1275420139.65.0.104008426141.issue8871@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Seems like `--user-access-control=auto` option [1] introduced in Python 2.6 for to bdist_wininst has no effect on Vista. 

Test.
1. Get a Vista.
2. `hg clone http://bitbucket.org/techtonik/python-wget/`
3. Add
{{{
    scripts=['wget.py'],
}}}
to setup.py
4. `python setup.py bdist_wininst --user-access-control=auto`
5. Execute wget-0.6.win32.exe
6. Watch the error
{{{
Access is denied.
CreateFile (C:\Python27\Scripts\wget.py)
}}}
7. Python is always installed for "All users" on Vista

[1] http://docs.python.org/distutils/builtdist.html#vista-user-access-control-uac

----------
assignee: tarek
components: Distutils
messages: 106853
nosy: tarek, techtonik
priority: normal
severity: normal
status: open
title: --user-access-control=auto has no effect
type: crash
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Jun  1 21:59:37 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 01 Jun 2010 19:59:37 +0000
Subject: [issue2581] Vista UAC/elevation support for bdist_wininst
In-Reply-To: <1207622587.48.0.467176827447.issue2581@psf.upfronthosting.co.za>
Message-ID: <1275422377.7.0.584987491508.issue2581@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Doesn't seem to work anymore. Please, see:
http://bugs.python.org/issue8870
http://bugs.python.org/issue8871

----------
nosy: +techtonik

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

From report at bugs.python.org  Tue Jun  1 22:08:59 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 01 Jun 2010 20:08:59 +0000
Subject: [issue7833] Bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1275422939.68.0.348849292687.issue7833@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I see that this issue mentions --user-access-control option. Can somebody also check if issue8870 and issue8871 are related to this one?

----------
nosy: +techtonik

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

From report at bugs.python.org  Tue Jun  1 22:11:03 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 01 Jun 2010 20:11:03 +0000
Subject: [issue8870] --user-access-control=force produces invalid installer on
	Vista
In-Reply-To: <1275417481.6.0.247175279763.issue8870@psf.upfronthosting.co.za>
Message-ID: <1275423063.46.0.214616984932.issue8870@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

See also issue8871 and original report http://scons.tigris.org/issues/show_bug.cgi?id=2533

----------

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

From report at bugs.python.org  Tue Jun  1 22:12:18 2010
From: report at bugs.python.org (Chris)
Date: Tue, 01 Jun 2010 20:12:18 +0000
Subject: [issue8872] if/else stament bug?
In-Reply-To: <1275423138.87.0.563453181958.issue8872@psf.upfronthosting.co.za>
Message-ID: <1275423138.87.0.563453181958.issue8872@psf.upfronthosting.co.za>


New submission from Chris <chrits44 at gmx.com>:

i am trying to learn to program in Python from a book on programming that says to use Python 3 

i downloaded the Python 3.1.2 Windows x86 MSI installer for my machine aka an HP DV2500 running Win 7

it runs fine, but when i try to write the test program from my book i can't get past the if/else statement aka it gives me a syntax error when i get to the point of an if/else statement aka i program to ask the user to guess the number .. and then i try to create an if/else statement to print a you lose type statement if the input guess is not equal to the number specified by the program. for example i program the game to = 777 and print the you lose type message if the user's guess is not equal to 777, however i use the check module command from the run window in IDLE and it gave me a syntax error when i typed it the way the book said ... I've tried to figure this out myself but have had no success .. so i looked up if statements in the Python tutorials on python.org and tried that format and am still getting a syntax error

----------
components: IDLE, Windows
files: hash.py
messages: 106857
nosy: chrits55
priority: normal
severity: normal
status: open
title: if/else stament bug?
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file17515/hash.py

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

From report at bugs.python.org  Tue Jun  1 22:25:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Jun 2010 20:25:46 +0000
Subject: [issue8872] if/else stament bug?
In-Reply-To: <1275423138.87.0.563453181958.issue8872@psf.upfronthosting.co.za>
Message-ID: <1275423946.03.0.990642544983.issue8872@psf.upfronthosting.co.za>


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

The bug tracker is not the place to get help on learning python.  Please try python-list or python-help (see mail.python.org).

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Jun  1 22:30:48 2010
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 01 Jun 2010 20:30:48 +0000
Subject: [issue8870] --user-access-control=force produces invalid installer on
	Vista
In-Reply-To: <1275417481.6.0.247175279763.issue8870@psf.upfronthosting.co.za>
Message-ID: <1275424248.45.0.213908375532.issue8870@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Is it possible the installer is being run from a network share?  A comment from PC/bdist_wininst/install.c:

	// interesting failure scenario that has been seen: initial executable
	// runs from a network drive - but once elevated, that network share
	// isn't seen, and ShellExecute fails with SE_ERR_ACCESSDENIED.

SE_ERR_ACCESSDENIED is 5, so googling for that might offer more insights.

----------
nosy: +mhammond

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

From report at bugs.python.org  Tue Jun  1 22:42:39 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 01 Jun 2010 20:42:39 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1275424959.86.0.316971541464.issue8857@psf.upfronthosting.co.za>


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

A patch which adds some basic tests is in attachment.
It basically tests what told in the documentation without going too deeper.

----------
Added file: http://bugs.python.org/file17516/getaddrinfotest.patch

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

From report at bugs.python.org  Tue Jun  1 23:13:29 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 01 Jun 2010 21:13:29 +0000
Subject: [issue8864] multiprocessing: undefined struct/union member:
	msg_control
In-Reply-To: <1275342146.08.0.266544809639.issue8864@psf.upfronthosting.co.za>
Message-ID: <1275426809.49.0.721424174427.issue8864@psf.upfronthosting.co.za>


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

Most likely, we wouldn't be able to support recvmsg on Solaris. We would need to run configure tests to determine whether the APIs are available, and that would require defining _XOPEN_SOURCE in pyconfig.h.in, which (according to #1759169) we must not do.

----------

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

From report at bugs.python.org  Wed Jun  2 00:18:46 2010
From: report at bugs.python.org (Hugh Secker-Walker)
Date: Tue, 01 Jun 2010 22:18:46 +0000
Subject: [issue8873] Popen uses 333 times as much CPU as a shell pipe on Mac
	OS X
In-Reply-To: <1275430726.49.0.216093303643.issue8873@psf.upfronthosting.co.za>
Message-ID: <1275430726.49.0.216093303643.issue8873@psf.upfronthosting.co.za>


New submission from Hugh Secker-Walker <hughsw at users.sourceforge.net>:

Popen seems to be *very* costly, CPU wise, on Mac OS X.

I need to read and process bytes from the stdout of another process that outputs bytes in a rate-limited fashion, e.g. 80000 bytes per second.  If I use a shell pipeline and a simple Python script to read the bytes and log some details then top and time both agree that the Python script is using roughly 1 second of CPU time for every 2000 seconds of elapsed time.

If I change the script to use Popen to start the first process and to read from proc.stdout, then top and time both agree that the Python script uses roughly 1 second of CPU time for every 6 seconds of elapsed time.  That is, using Popen uses 333 times as much CPU as using a shell pipeline.

In practice, this means that using a shell pipeline has no measureable impact on system performance, and I can run 300 concurrent pipeline jobs, whereas using Popen limits me to running 6 such concurrent jobs.

This is on an up-to-date Mac OS X 10.5.8 system.  The behavior happens with both the stock Python 2.5 from Apple and with Python 2.6 from Macports.

On Ubuntu Linux the Popen solution is perhaps 2% slower than using a shell pipeline.

I'll attach three scripts:
bytestream -- simple program that sends bytes to its stdout
pull0 -- Python script that reads its stdin and logs a couple of stats
pull1 -- Python script that uses Popen to start bytestream and pulls from proc.stdout and runs abysmally slowly.

Use this with a concurrent top to see the shell pipeline behavior:
$ ./bytestream 80000 4 | time ./pull0 11000

Use this with a concurrent top to see the Popen behavior:
$ time ./pull1 ./bytestream 80000 4 11000

In both cases you'll see that system and user time are approximately equal, but that they're roughly 333 times higher for pull1.  Is there a clue in the fact that both times go up by about the same huge factor?

-Hugh

----------
components: Library (Lib)
files: bytestream
messages: 106862
nosy: hughsw
priority: normal
severity: normal
status: open
title: Popen uses 333 times as much CPU as a shell pipe on Mac OS X
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file17517/bytestream

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

From report at bugs.python.org  Wed Jun  2 00:19:32 2010
From: report at bugs.python.org (Hugh Secker-Walker)
Date: Tue, 01 Jun 2010 22:19:32 +0000
Subject: [issue8873] Popen uses 333 times as much CPU as a shell pipe on Mac
	OS X
In-Reply-To: <1275430726.49.0.216093303643.issue8873@psf.upfronthosting.co.za>
Message-ID: <1275430772.77.0.302387387888.issue8873@psf.upfronthosting.co.za>


Changes by Hugh Secker-Walker <hughsw at users.sourceforge.net>:


Added file: http://bugs.python.org/file17518/pull0

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

From report at bugs.python.org  Wed Jun  2 00:20:11 2010
From: report at bugs.python.org (Hugh Secker-Walker)
Date: Tue, 01 Jun 2010 22:20:11 +0000
Subject: [issue8873] Popen uses 333 times as much CPU as a shell pipe on Mac
	OS X
In-Reply-To: <1275430726.49.0.216093303643.issue8873@psf.upfronthosting.co.za>
Message-ID: <1275430811.66.0.91094680263.issue8873@psf.upfronthosting.co.za>


Changes by Hugh Secker-Walker <hughsw at users.sourceforge.net>:


Added file: http://bugs.python.org/file17519/pull1

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

From report at bugs.python.org  Wed Jun  2 00:47:31 2010
From: report at bugs.python.org (John Levon)
Date: Tue, 01 Jun 2010 22:47:31 +0000
Subject: [issue8864] multiprocessing: undefined struct/union member:
	msg_control
In-Reply-To: <1275342146.08.0.266544809639.issue8864@psf.upfronthosting.co.za>
Message-ID: <1275432451.03.0.645231734623.issue8864@psf.upfronthosting.co.za>


John Levon <movement at users.sourceforge.net> added the comment:

It's not clear why you'd need configure tests, but you could easily add the define in the body of the autoconf test AFAIK - is there a reason this is difficult?

----------

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

From report at bugs.python.org  Wed Jun  2 00:52:38 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 01 Jun 2010 22:52:38 +0000
Subject: [issue8870] --user-access-control=force produces invalid installer on
	Vista
In-Reply-To: <1275417481.6.0.247175279763.issue8870@psf.upfronthosting.co.za>
Message-ID: <1275432758.74.0.391480709888.issue8870@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

It is local Ext2 partition system accessible through http://www.fs-driver.org/ on the same HDD as primary system partition. But there is definitely issue with difference between drives.

There is no problem if the package is executed from the NTFS system drive - permissions asked as expected, no errors. On the Ext2 partition VLC and other installers that require elevated privileges fail. I do not remember any such problems last year, but it just can be that most applications on this drive are not windows specific or do not require elevated privileges.

I still doesn't explain why this drive is threatened as "network". It would be nice to see how Windows treats other partition types - FAT32 or FAT16.

----------

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

From report at bugs.python.org  Wed Jun  2 00:54:06 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 01 Jun 2010 22:54:06 +0000
Subject: [issue8870] --user-access-control=force produces invalid installer on
	Vista
In-Reply-To: <1275417481.6.0.247175279763.issue8870@psf.upfronthosting.co.za>
Message-ID: <1275432846.92.0.537561727481.issue8870@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Attaching installer file for testing.

----------
Added file: http://bugs.python.org/file17520/wget-0.6.win32.exe

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

From report at bugs.python.org  Wed Jun  2 01:17:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 01 Jun 2010 23:17:40 +0000
Subject: [issue8669] lack of bdist_rpm module raises error on 'setup.py
	--help-commands'
In-Reply-To: <1273369633.98.0.458470159807.issue8669@psf.upfronthosting.co.za>
Message-ID: <1275434260.56.0.0717721271543.issue8669@psf.upfronthosting.co.za>


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

Can you still reproduce it? I think it?s fixed by http://bitbucket.org/tarek/distutils2/changeset/19f1965a304d

----------
nosy: +merwok

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

From report at bugs.python.org  Wed Jun  2 01:41:06 2010
From: report at bugs.python.org (Koen van de Sande)
Date: Tue, 01 Jun 2010 23:41:06 +0000
Subject: [issue7833] Bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1275435666.47.0.441119286395.issue7833@psf.upfronthosting.co.za>


Koen van de Sande <koen at tibed.net> added the comment:

issue8870 and issue8871 are not related to this one. There, the UAC elevation fails, here the issue is with the MS runtimes, elevation is working fine.

----------

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

From report at bugs.python.org  Wed Jun  2 01:43:39 2010
From: report at bugs.python.org (Koen van de Sande)
Date: Tue, 01 Jun 2010 23:43:39 +0000
Subject: [issue8870] --user-access-control=force produces invalid installer on
	Vista
In-Reply-To: <1275417481.6.0.247175279763.issue8870@psf.upfronthosting.co.za>
Message-ID: <1275435819.18.0.652610423672.issue8870@psf.upfronthosting.co.za>


Koen van de Sande <koen at tibed.net> added the comment:

This is listed as a known limitation of the Ext2 FS driver. From http://www.fs-driver.org/relnotes.html :

===
Running programs on an Ext2/Ext3 volume on Windows Vista 

Currently it is not possible to start a program on Vista if UAC is enabled and the program's executable is stored on an Ex2/Ext3 volume. An "invalid parameter" message box appears, but the program does not start. 

UAC is the feature of Vista that prompts the user to elevate the user privileges to administrator level when necessary. UAC is enabled by default. It is not recommended to disable it. 

The problem is caused by Vista's internals: There is some code that compares whether the name of the file system type is one of the following: "NTFS", "FAT", "FAT32", "CDFS", "NPFS", "MSFS" or "UDF". If there is a match, it is one of Microsoft's file system types and a lot of code is skipped in the Multiple UNC Provider (MUP) implementation of Vista. If the file system type is a third-party type, for example "Ext2", some code runs in the MUP of Vista that always generates an ERROR_INVALID_PARAMETER error status code due to a bug of Vista.
===

So the bug is in that FS (or in Windows if you will). It is not something Python can fix.

----------
nosy: +koen

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

From report at bugs.python.org  Wed Jun  2 01:45:43 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Tue, 01 Jun 2010 23:45:43 +0000
Subject: [issue8874] py3k documentation mentions deprecated opcode LOAD_LOCALS
In-Reply-To: <1275435943.68.0.198055718764.issue8874@psf.upfronthosting.co.za>
Message-ID: <1275435943.68.0.198055718764.issue8874@psf.upfronthosting.co.za>


New submission from Yaniv Aknin <yaniv.aknin at gmail.com>:

The documentation of the dis module mentions LOAD_LOCALS, which used to exist in Python 2.x and I believe was removed from py3k (doesn't appear in recent Include/opcode.h).

The exact offending section is: http://docs.python.org/py3k/library/dis.html#opcode-LOAD_LOCALS
I think it should just be edited out.

----------
assignee: docs at python
components: Documentation
messages: 106869
nosy: Yaniv.Aknin, docs at python
priority: normal
severity: normal
status: open
title: py3k documentation mentions deprecated opcode LOAD_LOCALS
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jun  2 02:40:05 2010
From: report at bugs.python.org (Dan Buch)
Date: Wed, 02 Jun 2010 00:40:05 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1275439205.5.0.26690129864.issue8591@psf.upfronthosting.co.za>


Dan Buch <daniel.buch at gmail.com> added the comment:

@merwok much thanks for the feedback.  After seeing how you're working via bitbucket I've decided to create a fresh fork from tarek and recreate my patch in multiple changesets all within the default branch.  I'll update the issue when finished.

----------

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

From report at bugs.python.org  Wed Jun  2 03:09:30 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 02 Jun 2010 01:09:30 +0000
Subject: [issue6521] Contradictory documentation for email.mime.text.MIMEText
In-Reply-To: <1248009581.26.0.315231370095.issue6521@psf.upfronthosting.co.za>
Message-ID: <1275440970.27.0.243638426931.issue6521@psf.upfronthosting.co.za>


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

This is not quite a duplicate of issue 1368247, but in the patch for that issue the doc changes should clarify the ambiguity.

----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Wed Jun  2 04:01:21 2010
From: report at bugs.python.org (Michiel de Hoon)
Date: Wed, 02 Jun 2010 02:01:21 +0000
Subject: [issue8868] Framework install does not behave as a framework
In-Reply-To: <1275401583.76.0.0937518467482.issue8868@psf.upfronthosting.co.za>
Message-ID: <1275444081.3.0.709810104968.issue8868@psf.upfronthosting.co.za>


Michiel de Hoon <mdehoon at users.sourceforge.net> added the comment:

The patch solves the problem also on Mac OS X 10.5 (I tried 32-bits and 64-bits with the current python in trunk, after applying the patch).
Thanks again!

----------

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

From report at bugs.python.org  Wed Jun  2 04:19:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 02 Jun 2010 02:19:09 +0000
Subject: [issue1555842] email package and Unicode strings handling
Message-ID: <1275445149.64.0.279491580132.issue1555842@psf.upfronthosting.co.za>


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

It took me a while to figure out why latin-1 works.  I turns out to be an accident: latin-1 uses quoted-printable encoding, and the email quoprimime module accidentally manages to quote unicode characters in the latin-1 range.

The Header example, as noted by the OP, is working as documented.  This confusing interface isn't going to get fixed in the current email package.  The equivalent email6 API will be cleaner.

The MIMEText portion is a duplicate of issue 1368247.

----------
resolution:  -> duplicate
stage: unit test needed -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Jun  2 04:31:52 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 02 Jun 2010 02:31:52 +0000
Subject: [issue8788] urllib.urlencode documentation unclear on doseq
In-Reply-To: <1274542983.4.0.702068503568.issue8788@psf.upfronthosting.co.za>
Message-ID: <1275445912.19.0.752031506174.issue8788@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Agree to your concern that doseq parameter is not properly explained.
Fixed in r81645, r81646, r81647 and r81648.

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

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

From report at bugs.python.org  Wed Jun  2 04:45:31 2010
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 02 Jun 2010 02:45:31 +0000
Subject: [issue8875] XML-RPC improvement is described twice.
In-Reply-To: <1275446731.65.0.0364952757342.issue8875@psf.upfronthosting.co.za>
Message-ID: <1275446731.65.0.0364952757342.issue8875@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/dev/whatsnew/2.7.html#new-and-improved-modules

"The XML-RPC client and server, provided by..." appears twice.

----------
assignee: docs at python
components: Documentation
messages: 106875
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: XML-RPC improvement is described twice.
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun  2 04:53:23 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 02 Jun 2010 02:53:23 +0000
Subject: [issue8875] XML-RPC improvement is described twice.
In-Reply-To: <1275446731.65.0.0364952757342.issue8875@psf.upfronthosting.co.za>
Message-ID: <1275447203.2.0.672581162715.issue8875@psf.upfronthosting.co.za>


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


----------
nosy: +akuchling, ezio.melotti
stage:  -> needs patch

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

From report at bugs.python.org  Wed Jun  2 05:51:35 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 02 Jun 2010 03:51:35 +0000
Subject: [issue8868] Framework install does not behave as a framework
In-Reply-To: <1275401583.76.0.0937518467482.issue8868@psf.upfronthosting.co.za>
Message-ID: <1275450695.22.0.570592147062.issue8868@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Thanks for testing.

I've applied the patch (with some additional documentation) in r81649 (2.7) and r81650 (3.2).  Other versions are not affected.

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

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

From report at bugs.python.org  Wed Jun  2 06:05:00 2010
From: report at bugs.python.org (Ionut Turturica)
Date: Wed, 02 Jun 2010 04:05:00 +0000
Subject: [issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum
	recursion depth exceeded in cmp
In-Reply-To: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za>
Message-ID: <1275451500.5.0.334374085999.issue8797@psf.upfronthosting.co.za>


Ionut Turturica <jonozzz at yahoo.com> added the comment:

Why would you waste the time and resources to test 5 times for a known to be wrong credential ?!

This is not like in a browser where the user is presented with a dialog box 5 times and he/she can try different credentials.

I don't see the point...

----------

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

From report at bugs.python.org  Wed Jun  2 06:13:35 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 02 Jun 2010 04:13:35 +0000
Subject: [issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum
	recursion depth exceeded in cmp
In-Reply-To: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za>
Message-ID: <1275452015.19.0.252471762447.issue8797@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

The point of retry is for auth failure, which can happen due to any reason. It is not just for a wrong password.

I was thinking just doing a single verification and failing, but did find some resources (not just browsers) which adopt this approach of retry.

BTW, Basic auth is gone now and Digest auth has some recommendations so I found its fine to do the same way as Digest auth does.

----------

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

From report at bugs.python.org  Wed Jun  2 08:38:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Jun 2010 06:38:51 +0000
Subject: [issue8873] Popen uses 333 times as much CPU as a shell pipe on Mac
	OS X
In-Reply-To: <1275430726.49.0.216093303643.issue8873@psf.upfronthosting.co.za>
Message-ID: <1275460731.19.0.225900184175.issue8873@psf.upfronthosting.co.za>


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

Have you tried specifying a value for the bufsize argument to Popen? Either 1 for line buffering or e.g. 4096 for a decent size block buffering.

----------
nosy: +gregory.p.smith, pitrou

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

From report at bugs.python.org  Wed Jun  2 10:39:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Jun 2010 08:39:01 +0000
Subject: [issue1038909] pydoc method documentation lookup enhancement
Message-ID: <1275467941.43.0.624264166945.issue1038909@psf.upfronthosting.co.za>


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


----------
nosy: +merwok

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

From report at bugs.python.org  Wed Jun  2 10:40:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Jun 2010 08:40:03 +0000
Subject: [issue1185124] pydoc doesn't find all module doc strings
Message-ID: <1275468003.43.0.987136933461.issue1185124@psf.upfronthosting.co.za>


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


----------
nosy: +merwok

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

From report at bugs.python.org  Wed Jun  2 14:25:39 2010
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Wed, 02 Jun 2010 12:25:39 +0000
Subject: [issue8848] Deprecate or remove "U" and "U#" formats of
	Py_BuildValue()
In-Reply-To: <1275097128.66.0.216673219733.issue8848@psf.upfronthosting.co.za>
Message-ID: <1275481539.54.0.156127799067.issue8848@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

The code for case 's'/'z' in py3k is indeed the same as for case 'U'. The patch looks good to me.

IMHO removing 'U' should only be done once Py2 is dead.

----------

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

From report at bugs.python.org  Wed Jun  2 15:38:36 2010
From: report at bugs.python.org (samtygier)
Date: Wed, 02 Jun 2010 13:38:36 +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: <1275485916.86.0.44676570948.issue8876@psf.upfronthosting.co.za>


New submission from samtygier <samtygier at yahoo.co.uk>:

distutils will currently try to use hardlinks if os has a 'link' attribute, however sometimes os.link() will fail, for example the filesystem may not support it (see attached traceback).

in commands/sdist.py in make_release_tree() there is the test:
        if hasattr(os, 'link'):        # can make hard links on this system
            link = 'hard'
            msg = "making hard links in %s..." % base_dir

'link' is then passed to copy_file() in file_util.py, which trusts that if link == 'hard', then hardlinking will work.

there has been discussion in the past, but i dont think it has been fixed
http://thread.gmane.org/gmane.comp.python.distutils.devel/2076

----------
assignee: tarek
components: Distutils
files: hardlink-traceback.txt
messages: 106881
nosy: samtygier, tarek
priority: normal
severity: normal
status: open
title: distutils should not assume that hardlinks will work
versions: Python 2.6
Added file: http://bugs.python.org/file17521/hardlink-traceback.txt

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

From report at bugs.python.org  Wed Jun  2 15:40:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Jun 2010 13:40:59 +0000
Subject: [issue8876] distutils should not assume that hardlinks will work
In-Reply-To: <1275485916.86.0.44676570948.issue8876@psf.upfronthosting.co.za>
Message-ID: <1275486059.16.0.499281910791.issue8876@psf.upfronthosting.co.za>


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


----------
components: +Distutils2

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

From report at bugs.python.org  Wed Jun  2 16:09:05 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 02 Jun 2010 14:09:05 +0000
Subject: [issue8877] 2to3 fixes stdlib import wrongly
In-Reply-To: <1275487745.39.0.469741822942.issue8877@psf.upfronthosting.co.za>
Message-ID: <1275487745.39.0.469741822942.issue8877@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

djc at enrai src $ ls -l test/*
-rw-r--r-- 1 djc users 34 Jun  2 16:00 test/http.py
-rw-r--r-- 1 djc users  0 Jun  2 16:00 test/__init__.py
djc at enrai src $ cat test/http.py
from httplib import BadStatusLine
djc at enrai src $ 2to3 test/*
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
--- test/http.py (original)
+++ test/http.py (refactored)
@@ -1,1 +1,1 @@
-from httplib import BadStatusLine
+from .http.client import BadStatusLine
RefactoringTool: Files that need to be modified:
RefactoringTool: test/http.py

... which doesn't work, of course. On the other hand, http.py is not in a package, it works correctly. If test/http.py is moved to test/blah.py instead, it also works correctly. 2to3 should be able to conclude that the "httplib" it was before did not refer to .http, but refered to http.client.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 106882
nosy: djc
priority: normal
severity: normal
status: open
title: 2to3 fixes stdlib import wrongly
versions: Python 3.1

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

From report at bugs.python.org  Wed Jun  2 16:17:03 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 02 Jun 2010 14:17:03 +0000
Subject: [issue2459] speedup for / while / if with better bytecode
In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za>
Message-ID: <1275488223.89.0.827357919347.issue2459@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Is this still relevant / will it get some love in the future?

----------
nosy: +djc

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

From report at bugs.python.org  Wed Jun  2 16:33:48 2010
From: report at bugs.python.org (Tal Einat)
Date: Wed, 02 Jun 2010 14:33:48 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1275489228.47.0.542405176524.issue1766304@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

I'd like to implement this for 2.x, if there's any chance of this being accepted. Is there still a chance of getting this into 2.7?

This will be my first patch for the Python core, so please tell me if I'm missing something. Currently I'm thinking of:
1. starting with the original patch
2. applying the required changes as mentioned Mark Dickinson, looking at the the accepted 3.x patch for guidance
3. back-porting the tests
4. checking for later additional changes in the source history, and back-porting any such relevant changes

----------
nosy: +taleinat

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

From report at bugs.python.org  Wed Jun  2 16:36:22 2010
From: report at bugs.python.org (samtygier)
Date: Wed, 02 Jun 2010 14:36:22 +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: <1275489382.98.0.798193175281.issue8876@psf.upfronthosting.co.za>


samtygier <samtygier at yahoo.co.uk> added the comment:

here is a patch against http://svn.python.org/projects/python/trunk

it moves the return statements into the individual file copying sections, and takes the final call to _copy_file_contents() out of the else. this allows an error in hardlinking to fall through by passing the exception.

i have only tested on Linux.

when running it still prints out
"hard linking CHANGES -> pyzgoubi-0.4dev"
because of how the message is generated in line 130. do you think this needs to be changed. do we need a
"hardlinking failed, falling back to copy"
message? it might cause unnecessary worry (distutils already suppresses tracebacks to avoid scaring non-python-programmers).

i have a patch that applies to 2.6 as well, is there much chance of that being accepted?

----------
keywords: +patch
Added file: http://bugs.python.org/file17522/distutil-hardlink-trunk.diff

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

From report at bugs.python.org  Wed Jun  2 16:43:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Jun 2010 14:43:50 +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: <1275489830.28.0.649889871202.issue8876@psf.upfronthosting.co.za>


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

Distutils is a special case: Many third-party code relies on its undocumented quirks and bugs, so it?s basically frozen. Some non-disruptive bugfixes are accepted, in which case the normal Python rules apply (e.g., no new features in 2.7 which is in beta). Work has been moved to Distutils2, which breaks compatibility in order to fix things and add needed features.

If Tarek (maintainer of both packages) agrees this can go into Distutils, Benjamin Peterson (release manager) will say whether he agrees or not. Patient a while for Tarek to see this bug report, and thanks for your work :)

----------
nosy: +merwok

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

From report at bugs.python.org  Wed Jun  2 16:47:42 2010
From: report at bugs.python.org (Neil Crouch)
Date: Wed, 02 Jun 2010 14:47:42 +0000
Subject: [issue8878] IDLE - str(integer) - TypeError: 'str' object is not
	callable
In-Reply-To: <1275490062.25.0.32490402155.issue8878@psf.upfronthosting.co.za>
Message-ID: <1275490062.25.0.32490402155.issue8878@psf.upfronthosting.co.za>


New submission from Neil Crouch <neil.crouch at tradingtechnologies.com>:

Unable to convert int to str in idle but from the cmd python prompt it work sfine.

----------
components: IDLE
files: IDLE_err.txt
messages: 106887
nosy: Stranger381
priority: normal
severity: normal
status: open
title: IDLE - str(integer) - TypeError: 'str' object is not callable
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17523/IDLE_err.txt

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

From report at bugs.python.org  Wed Jun  2 16:49:31 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 02 Jun 2010 14:49:31 +0000
Subject: [issue8878] IDLE - str(integer) - TypeError: 'str' object is not
	callable
In-Reply-To: <1275490062.25.0.32490402155.issue8878@psf.upfronthosting.co.za>
Message-ID: <1275490171.92.0.817850731031.issue8878@psf.upfronthosting.co.za>


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

You probably did str = '4bf3e914' at some point and overridden str.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Jun  2 16:52:40 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jun 2010 14:52:40 +0000
Subject: [issue8878] IDLE - str(integer) - TypeError: 'str' object is not
	callable
In-Reply-To: <1275490062.25.0.32490402155.issue8878@psf.upfronthosting.co.za>
Message-ID: <1275490360.73.0.874995475595.issue8878@psf.upfronthosting.co.za>


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

The code you show works fine for me.

The error you're seeing is almost certainly the result of inadvertently using 'str' as a variable name earlier in the IDLE session:

Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> str = '4bf3e914'
>>> hell = str(123)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'str' object is not callable
>>> help(str)
no Python documentation found for '4bf3e914'

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Wed Jun  2 17:02:44 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jun 2010 15:02:44 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1275490964.4.0.635886479219.issue1766304@psf.upfronthosting.co.za>


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

A rapidly diminishing chance for 2.7, IMO.  I wouldn't want to try to add this after the first release candidate, which is scheduled for June 5 (and I'm not sure I'll have time to review a patch between now and then).

On the other hand, since this is pure optimization it might be acceptable for 2.7.1.

----------

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

From report at bugs.python.org  Wed Jun  2 17:17:33 2010
From: report at bugs.python.org (Tal Einat)
Date: Wed, 02 Jun 2010 15:17:33 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1275491853.16.0.0244433664453.issue1766304@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

I'd really like to have this in 2.7. Is there no chance of getting it into 2.7 after rc1 is released?

If so, I can have the patch ready by Friday 14:00 GMT, but if nobody will have time to review (and possibly commit) in time for RC1 I guess I'll take my time with this.

----------

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

From report at bugs.python.org  Wed Jun  2 17:32:29 2010
From: report at bugs.python.org (Hugh Secker-Walker)
Date: Wed, 02 Jun 2010 15:32:29 +0000
Subject: [issue8873] Popen uses 333 times as much CPU as a shell pipe on Mac
	OS X
In-Reply-To: <1275430726.49.0.216093303643.issue8873@psf.upfronthosting.co.za>
Message-ID: <1275492749.57.0.0370658207184.issue8873@psf.upfronthosting.co.za>


Hugh Secker-Walker <hughsw at users.sourceforge.net> added the comment:

OK.  Using bufsize=4096 or bufsize=-1 eliminates the CPU-hogging problem on Mac OS X.  Thank you.

I have to say that the Popen() doc could be better.  It says: "bufsize, if given, has the same meaning as the corresponding argument to the built-in open() function!" which implies behavior like open(), which is to use the system's default buffering, generally a good thing.

I think the default of 0, meaning unbuffered, is a poor choice.  I'm guessing many many Mac users are getting a big slowdown from this default behavior (as I've now discovered elsewhere in our project!).  I request that you change the default to be the same as open(), i.e. use the system default.

Barring that semantic change, please add a note to the doc:  "Most users will want to set bufsize=4096 for pipe-like buffering, or bufsize=1 for line-based buffering."  

Thanks again for the quick response and resolution.

-Hugh

----------

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

From report at bugs.python.org  Wed Jun  2 17:34:35 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jun 2010 15:34:35 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1275492875.14.0.999454748426.issue1766304@psf.upfronthosting.co.za>


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

Benjamin?

> I'd really like to have this in 2.7. Is there no chance of getting it
> into 2.7 after rc1 is released?

----------

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

From report at bugs.python.org  Wed Jun  2 17:56:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Jun 2010 15:56:42 +0000
Subject: [issue8873] Popen uses 333 times as much CPU as a shell pipe on Mac
	OS X
In-Reply-To: <1275492749.57.0.0370658207184.issue8873@psf.upfronthosting.co.za>
Message-ID: <1275494197.3180.0.camel@localhost.localdomain>


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

> I think the default of 0, meaning unbuffered, is a poor choice.

So do I, but I'm not sure whether it's acceptable to change behaviour in
a potentially incompatible way.

> Barring that semantic change, please add a note to the doc:  "Most
> users will want to set bufsize=4096 for pipe-like buffering, or
> bufsize=1 for line-based buffering."  

Yes, it deserves a documentation note indeed.

----------

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

From report at bugs.python.org  Wed Jun  2 18:42:52 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 02 Jun 2010 16:42:52 +0000
Subject: [issue8870] --user-access-control=force produces invalid installer on
	Vista
In-Reply-To: <1275417481.6.0.247175279763.issue8870@psf.upfronthosting.co.za>
Message-ID: <1275496972.22.0.893734727591.issue8870@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Thanks for thorough explanation. Can somebody close it with some resolution like "Can't fix. OS level problem"?

----------

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

From report at bugs.python.org  Wed Jun  2 18:51:23 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 02 Jun 2010 16:51:23 +0000
Subject: [issue8873] Popen uses 333 times as much CPU as a shell pipe on Mac
	OS X
In-Reply-To: <1275430726.49.0.216093303643.issue8873@psf.upfronthosting.co.za>
Message-ID: <1275497483.18.0.708907591538.issue8873@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

This problem has come up before.  It was a bug introduced I think when
the subprocess module was first incorporated into Python.  I don't
recall if the default was changed in 2.7 or 3.x.  Can you demonstrate
the problem with Python 2.7 or 3.1?  If not, I'd recommend this 
ticket just be closed.

----------
nosy: +skip.montanaro

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

From report at bugs.python.org  Wed Jun  2 19:07:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 02 Jun 2010 17:07:32 +0000
Subject: [issue8877] 2to3 fixes stdlib import wrongly
In-Reply-To: <1275487745.39.0.469741822942.issue8877@psf.upfronthosting.co.za>
Message-ID: <1275498452.05.0.697710691604.issue8877@psf.upfronthosting.co.za>


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

Just in case it isn't clear: this is because of the order of fixes. The first fixer replaces httplib with http.client, then the next fixer thinks this is a relative import.

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

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

From report at bugs.python.org  Wed Jun  2 19:09:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Jun 2010 17:09:19 +0000
Subject: [issue8873] Popen uses 333 times as much CPU as a shell pipe on Mac
	OS X
In-Reply-To: <1275497483.18.0.708907591538.issue8873@psf.upfronthosting.co.za>
Message-ID: <1275498555.3180.6.camel@localhost.localdomain>


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

> This problem has come up before.  It was a bug introduced I think when
> the subprocess module was first incorporated into Python.  I don't
> recall if the default was changed in 2.7 or 3.x.

According to the docs it is still unbuffered by default. I've added a
documentation note about performance issues in r81652.

----------

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

From report at bugs.python.org  Wed Jun  2 20:03:00 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 02 Jun 2010 18:03:00 +0000
Subject: [issue1766304] improve xrange.__contains__
In-Reply-To: <1275491853.16.0.0244433664453.issue1766304@psf.upfronthosting.co.za>
Message-ID: <AANLkTik__xjCRqCvE1QJJU2z9dhWyNq_Hx9FpS-XQvHx@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Jun 2, 2010 at 11:17 AM, Tal Einat <report at bugs.python.org> wrote:
..
> If so, I can have the patch ready by Friday 14:00 GMT, but if nobody will have time to review
> (and possibly commit) in time for RC1 I guess I'll take my time with this.

I'll review your patch, but why are you so eager to get this into 2.7?
 You realize that for integer x, x in xrange(a, b) is just another way
to spell a <= x < b.  What is your use case?

----------

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

From report at bugs.python.org  Wed Jun  2 20:03:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 02 Jun 2010 18:03:23 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1275501803.22.0.830208969467.issue1766304@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky

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

From report at bugs.python.org  Wed Jun  2 20:03:56 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 02 Jun 2010 18:03:56 +0000
Subject: [issue8877] 2to3 fixes stdlib import wrongly
In-Reply-To: <1275487745.39.0.469741822942.issue8877@psf.upfronthosting.co.za>
Message-ID: <1275501836.97.0.652809570021.issue8877@psf.upfronthosting.co.za>


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

And this has been fixed in the lastest versions of 2to3.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Wed Jun  2 20:07:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Jun 2010 18:07:03 +0000
Subject: [issue1766304] improve xrange.__contains__
In-Reply-To: <AANLkTik__xjCRqCvE1QJJU2z9dhWyNq_Hx9FpS-XQvHx@mail.gmail.com>
Message-ID: <1275502018.3180.7.camel@localhost.localdomain>


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

> > If so, I can have the patch ready by Friday 14:00 GMT, but if nobody will have time to review
> > (and possibly commit) in time for RC1 I guess I'll take my time with this.
> 
> I'll review your patch, but why are you so eager to get this into 2.7?
>  You realize that for integer x, x in xrange(a, b) is just another way
> to spell a <= x < b.  What is your use case?

I really think this shouldn't go into 2.7.  We certainly have better
things to do than potentially break something for an almost useless
non-feature.

----------

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

From report at bugs.python.org  Wed Jun  2 20:07:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Jun 2010 18:07:30 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1275502050.83.0.293025647318.issue1766304@psf.upfronthosting.co.za>


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

Rescheduling to 3.2, if applicable (otherwise I suggest closing).

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

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

From report at bugs.python.org  Wed Jun  2 20:09:12 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 02 Jun 2010 18:09:12 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1275502152.68.0.230819078529.issue1766304@psf.upfronthosting.co.za>


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

I don't really see the point. I would be more inclined towards it if there was a patch already, but patching this doesn't strike me as a key feature.

----------

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

From report at bugs.python.org  Wed Jun  2 20:10:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 02 Jun 2010 18:10:18 +0000
Subject: [issue1766304] improve xrange.__contains__
In-Reply-To: <1275502050.83.0.293025647318.issue1766304@psf.upfronthosting.co.za>
Message-ID: <AANLkTilqQ0krTqWb3lKM_pgoiRDfXr_R8moZVC9VwpbY@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This is already in 3.x.  The only reason I can think of to get this in
2.7 is to have fewer performance surprises between 2.x and 3.x.

----------

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

From report at bugs.python.org  Wed Jun  2 20:10:32 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 02 Jun 2010 18:10:32 +0000
Subject: [issue8874] py3k documentation mentions deprecated opcode LOAD_LOCALS
In-Reply-To: <1275435943.68.0.198055718764.issue8874@psf.upfronthosting.co.za>
Message-ID: <1275502232.16.0.0084436930389.issue8874@psf.upfronthosting.co.za>


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

Thanks. Removed in r81656.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Wed Jun  2 20:14:43 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 02 Jun 2010 18:14:43 +0000
Subject: [issue5434] datetime.monthdelta
In-Reply-To: <1236402290.49.0.02662803662.issue5434@psf.upfronthosting.co.za>
Message-ID: <1275502483.77.0.152802810593.issue5434@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Rejecting this for stdlib.  A 3rd party package is available at http://pypi.python.org/pypi?name=MonthDelta&:action=display .

----------
stage:  -> committed/rejected
status: pending -> closed

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

From report at bugs.python.org  Wed Jun  2 20:18:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Jun 2010 18:18:42 +0000
Subject: [issue1766304] improve xrange.__contains__
In-Reply-To: <AANLkTilqQ0krTqWb3lKM_pgoiRDfXr_R8moZVC9VwpbY@mail.gmail.com>
Message-ID: <1275502717.3180.8.camel@localhost.localdomain>


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

Le mercredi 02 juin 2010 ? 18:10 +0000, Alexander Belopolsky a ?crit :
> This is already in 3.x.  The only reason I can think of to get this in
> 2.7 is to have fewer performance surprises between 2.x and 3.x.

Since you are supposed to forward-port from 2.x and 3.x, the surprise
will be a good one anyway.

----------

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

From report at bugs.python.org  Wed Jun  2 20:47:38 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 02 Jun 2010 18:47:38 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

Add os.link support for Windows


(mostly a reminder to myself to finish the patch I have)

----------
assignee: brian.curtin
components: Extension Modules, Windows
messages: 106908
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: Implement os.link on Windows
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Wed Jun  2 21:51:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Jun 2010 19:51:26 +0000
Subject: [issue8870] --user-access-control=force produces invalid installer on
	Vista
In-Reply-To: <1275417481.6.0.247175279763.issue8870@psf.upfronthosting.co.za>
Message-ID: <1275508286.31.0.25490446936.issue8870@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Jun  2 22:08:19 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 02 Jun 2010 20:08:19 +0000
Subject: [issue8866] socket.getaddrinfo() should support keyword arguments
In-Reply-To: <1275346212.88.0.3146354655.issue8866@psf.upfronthosting.co.za>
Message-ID: <1275509299.01.0.620807770539.issue8866@psf.upfronthosting.co.za>


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

The patch in attachment implements keyword arguments.

----------
keywords: +patch
Added file: http://bugs.python.org/file17524/kwargs.patch

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

From report at bugs.python.org  Wed Jun  2 22:30:58 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 02 Jun 2010 20:30:58 +0000
Subject: [issue8870] --user-access-control=force produces invalid installer on
	Vista
In-Reply-To: <1275417481.6.0.247175279763.issue8870@psf.upfronthosting.co.za>
Message-ID: <1275510658.88.0.0316425617173.issue8870@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Is it possible to detect this situation and display more user-friendly error message with a reference to this issue?

----------

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

From report at bugs.python.org  Wed Jun  2 22:49:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 02 Jun 2010 20:49:53 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275511793.79.0.181481529342.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Here is my first attempt to implement fixed offset timezone type.  The patch is based on Brett's next-patch.txt and while I changed the type name from datetime.UTC to datetime.timezone, I did not change the name of the related C structures.  I would like to ask for comments on the following questions:

1. How to call the new type?  I like "timezone" because it is likely to be the only concrete tzinfo subclass in datetime module, so we don't really need to call it fixedoffsetfromutctimezone.

2. Do we want to add a dst indicator and altname attributes? I would say: no. I would rather treat DST as a different fixed offset timezone.

3. I am not quite happy about having to specify offset in minutes.  I think timezone(hours[, minutes]) may be clearer.  Alternatively we may just take offset as a timedelta.  Note issue5288.  There is some interest in supporting sub-minute timezones.

4. I have fixed a reference leak in utcnow, but I am still against giving it tz_aware argument.

----------
Added file: http://bugs.python.org/file17525/issue5094.diff

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

From report at bugs.python.org  Wed Jun  2 23:01:38 2010
From: report at bugs.python.org (Edwin Pozharski)
Date: Wed, 02 Jun 2010 21:01:38 +0000
Subject: [issue8880] ConfigParser.set does not convert non-string values
In-Reply-To: <1275512498.11.0.636017814706.issue8880@psf.upfronthosting.co.za>
Message-ID: <1275512498.11.0.636017814706.issue8880@psf.upfronthosting.co.za>


New submission from Edwin Pozharski <pozharski at gmail.com>:

set() method of ConfigParser accepts boolean True/False as values at runtime without converting them to strings internally.  As a result, getboolean() method reports the following error

  File "/usr/lib/python2.6/ConfigParser.py", line 350, in getboolean
    if v.lower() not in self._boolean_states:
AttributeError: 'bool' object has no attribute 'lower'

since it expects get() method to return strings.  (Same problem occurs if other types are used, int/float, etc)

Altering set() behavior may be not the best thing to do, I'd rather suggest that getboolean() converts the get() output to string.

Of course, the way to avoid this problem is always convert values submitted to set() to strings, but it's a hard-to-catch bug.  In my case, I was stuck with problematic configuration when assigning values to wx.CheckBox.GetValue(), which returns boolean.

----------
messages: 106912
nosy: Edwin.Pozharski
priority: normal
severity: normal
status: open
title: ConfigParser.set does not convert non-string values
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Jun  2 23:08:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Jun 2010 21:08:05 +0000
Subject: [issue8880] ConfigParser.set does not convert non-string values
In-Reply-To: <1275512498.11.0.636017814706.issue8880@psf.upfronthosting.co.za>
Message-ID: <1275512885.87.0.531743561958.issue8880@psf.upfronthosting.co.za>


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

Would that mean that booleans would be converted to strings on set and converted back on get? Seems wasteful.

(I?ve changed the version field for this bug. Its meaning is not ?versions this applies to? but ?versions that will get a fix?, and 3.2 is the only active branch now. Some bugfixes may still go into 2.7.)

----------
components: +Library (Lib)
nosy: +merwok
versions: +Python 3.2 -Python 2.6

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

From report at bugs.python.org  Wed Jun  2 23:24:02 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Jun 2010 21:24:02 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275513842.77.0.021274202719.issue5094@psf.upfronthosting.co.za>


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

My thoughts on Alexander's questions:

1. Call it FixedTimezone or something (remember it has to be CapWords). Calling it simply Timezone does not convey the fact that DST is not supported and people might naively think it will. Its limited abilities should be portrayed in the name.

2. Keep the class dead-simple. The primary motivator is to support UTC, maybe the %z directive for strptime. Otherwise everything else should be left out of the stdlib and let third-parties manage it as they will be the ones that need to manage the bazillion timezone instances they need. We don't need to dictate an interface to them.

3. Taking a timedelta makes sense since the class represents the fixed time offset from UTC.

As for the tz_aware argument to utcnow and friends, I am fine with letting go of them if we have a utc attribute on datetime and we simply document that to get a UTC-aware value do ``now(datetime.utc)`` and consider deprecating utcnow.

----------

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

From report at bugs.python.org  Wed Jun  2 23:27:26 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Wed, 02 Jun 2010 21:27:26 +0000
Subject: [issue6470] Tkinter import fails when running Python.exe from a
	network share
In-Reply-To: <1247430164.29.0.0724763544583.issue6470@psf.upfronthosting.co.za>
Message-ID: <1275514046.64.0.450423883571.issue6470@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

Any chance to get this fixed in 2.7? On Windows, the bug prevents some popular applications and packages, such as pymol and matplotlib, to be used when installed on network shares, as is common practice in computer labs.

----------

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

From report at bugs.python.org  Wed Jun  2 23:31:28 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 02 Jun 2010 21:31:28 +0000
Subject: [issue8881] socket.getaddrinfo() should return named tuples
In-Reply-To: <1275514288.42.0.225628200657.issue8881@psf.upfronthosting.co.za>
Message-ID: <1275514288.42.0.225628200657.issue8881@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

As of right now socket.getaddrinfo() returns a sequence of 5-tuples reflecting family, type, protocol, canonname, and address of a socket:

>>> socket.getaddrinfo(None, 0)
[(10, 1, 6, '', ('::1', 0, 0, 0)), (10, 2, 17, '', ('::1', 0, 0, 0)), (10, 3, 0, '', ('::1', 0, 0, 0)), (2, 1, 6, '', ('127.0.0.1', 0)), (2, 2, 17, '', ('127.0.0.1', 0)), (2, 3, 0, '', ('127.0.0.1', 0))]

For readability it would be good if they were named tuples instead:

>>> socket.getaddrinfo(None, 0)[0]
addr_info(family=10, type=1, protocol=6, canonname='', address=('::1', 0, 0, 0))

Optionally, integers can be replaced by socket constant names:

>>> socket.getaddrinfo(None, 0)[0]
addr_info(family=socket.AF_INET6, type=socket.SOCK_STREAM, protocol=socket.IPPROTO_TCP, canonname='', address=('::1', 0, 0, 0))

----------
components: Library (Lib)
messages: 106916
nosy: exarkun, giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: socket.getaddrinfo() should return named tuples
versions: Python 3.2

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

From report at bugs.python.org  Wed Jun  2 23:33:15 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 02 Jun 2010 21:33:15 +0000
Subject: [issue8866] socket.getaddrinfo() should support keyword arguments
In-Reply-To: <1275346212.88.0.3146354655.issue8866@psf.upfronthosting.co.za>
Message-ID: <1275514395.22.0.994378159429.issue8866@psf.upfronthosting.co.za>


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

Created issue 8881 to treat the named tuples issue separately.

----------

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

From report at bugs.python.org  Wed Jun  2 23:33:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 02 Jun 2010 21:33:19 +0000
Subject: [issue8880] ConfigParser.set does not convert non-string values
In-Reply-To: <1275512498.11.0.636017814706.issue8880@psf.upfronthosting.co.za>
Message-ID: <1275514399.16.0.8441694431.issue8880@psf.upfronthosting.co.za>


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

Use SafeConfigParser instead, then you can't make the mistake of passing non-strings to set.

We really should update the docs so that ConfigParser is doced only in a 'deprecated' section.  But that's a different issue.  (Care to open it, merwok? :)

----------
nosy: +r.david.murray
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Jun  2 23:47:22 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 02 Jun 2010 21:47:22 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1275515242.92.0.926711054703.issue8879@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/issue8879>
_______________________________________

From report at bugs.python.org  Wed Jun  2 23:52:51 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 02 Jun 2010 21:52:51 +0000
Subject: [issue8881] socket.getaddrinfo() should return named tuples
In-Reply-To: <1275514288.42.0.225628200657.issue8881@psf.upfronthosting.co.za>
Message-ID: <1275515571.26.0.575076245422.issue8881@psf.upfronthosting.co.za>


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

Keep in mind this isn't an entirely backwards compatible change. See issue 8413, for example.

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

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

From report at bugs.python.org  Thu Jun  3 00:02:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 02 Jun 2010 22:02:12 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1275513842.77.0.021274202719.issue5094@psf.upfronthosting.co.za>
Message-ID: <AANLkTikkb8mwmV2XL53O1lsZV4li9dab9CTP3E7NqhdU@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Jun 2, 2010 at 5:24 PM, Brett Cannon <report at bugs.python.org> wrote:
..
> 1. Call it FixedTimezone or something (remember it has to be CapWords).

I thought consistency within module trumps PEP 8 naming standards.
The datetime module (for better or worse) uses lowercase names for its
types: date, time, datetime, tzinfo.  Shouldn't the new type follow
the suit? (This will also avoid a source of typos TimeZone vs.
TimeZone).

I don't like "fixed timezone" - it is not clear what it is fixed:
offset, geographical location or historical set of rules.  I think we
should promote the notion that timezone is just an offset.  EST is -5
hours, EDT is -4.  New York uses EST in winter and EDT in summer.   A
zoneinfo database (external to python) is a mapping from place and
time to timezone.

----------

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

From report at bugs.python.org  Thu Jun  3 00:05:51 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 02 Jun 2010 22:05:51 +0000
Subject: [issue6470] Tkinter import fails when running Python.exe from a
	network share
In-Reply-To: <1247430164.29.0.0724763544583.issue6470@psf.upfronthosting.co.za>
Message-ID: <1275516351.61.0.179665974139.issue6470@psf.upfronthosting.co.za>


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

Can somebody please explain how the test and the reported bug are related? The patch seems to deal with paths that have "UNC" in them; and the test seems not to.

----------

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

From report at bugs.python.org  Thu Jun  3 00:08:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 02 Jun 2010 22:08:05 +0000
Subject: [issue6470] Tkinter import fails when running Python.exe from a
	network share
In-Reply-To: <1247430164.29.0.0724763544583.issue6470@psf.upfronthosting.co.za>
Message-ID: <1275516485.28.0.532491795231.issue6470@psf.upfronthosting.co.za>


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

Also, cgohlke, can you please provide complete, detailed instructions on how to reproduce this issue? How do I get python.exe into \\Server\Share in the first place? And why did you not map a network drive letter?

----------

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

From report at bugs.python.org  Thu Jun  3 00:26:22 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Jun 2010 22:26:22 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275517582.78.0.459951794992.issue5094@psf.upfronthosting.co.za>


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

Forgot about datetime breaking the PEP 8 rules. You're right, consistency wins.

As for fixedtimezone being odd, that's why my mind went with FixedOffsetTimezone to start, but that doesn't go with the naming of the module, and fixedoffsettimezone is just hard to read.

As long as the documentation is VERY clear that the timezone class only supports a fixed offset from UTC and nothing else I can live with the "timezone".

----------

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

From report at bugs.python.org  Thu Jun  3 00:26:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 02 Jun 2010 22:26:28 +0000
Subject: [issue1368247] unicode in email.MIMEText and email/Charset.py
Message-ID: <1275517588.58.0.12880379504.issue1368247@psf.upfronthosting.co.za>


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

Committed to 2.7 in r81658 and 2.6 in r81659.  I'm leaving this open for the moment because while py3 doesn't have this problem, the tests should still pass and they don't.

----------
stage: patch review -> committed/rejected
versions:  -Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Jun  3 00:49:37 2010
From: report at bugs.python.org (David Watson)
Date: Wed, 02 Jun 2010 22:49:37 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1275518977.23.0.723998927336.issue6560@psf.upfronthosting.co.za>


David Watson <baikie at users.sourceforge.net> added the comment:

OK.  I don't like creating/using a Google account, but here it is:

http://codereview.appspot.com/1487041/show

----------

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

From report at bugs.python.org  Thu Jun  3 00:50:09 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 02 Jun 2010 22:50:09 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and
	tuple	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1275519009.24.0.608239947113.issue1820@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/issue1820>
_______________________________________

From report at bugs.python.org  Thu Jun  3 00:57:05 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Jun 2010 22:57:05 +0000
Subject: [issue6470] Tkinter import fails when running Python.exe from a
	network share
In-Reply-To: <1247430164.29.0.0724763544583.issue6470@psf.upfronthosting.co.za>
Message-ID: <1275519425.05.0.718070740913.issue6470@psf.upfronthosting.co.za>


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

to reproduce: on Vista, start

\\%COMPUTERNAME%\c$\python26\python.exe -c "import Tkinter; print Tkinter"

In this case, the path returned by GetFinalPathNameByHandle starts with \\?\UNC\.

----------

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

From report at bugs.python.org  Thu Jun  3 01:02:13 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Wed, 02 Jun 2010 23:02:13 +0000
Subject: [issue6470] Tkinter import fails when running Python.exe from a
	network share
In-Reply-To: <1247430164.29.0.0724763544583.issue6470@psf.upfronthosting.co.za>
Message-ID: <1275519733.07.0.465892593629.issue6470@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

Btw, this bug is also present in Python 3.1, of course when using tkinter instead of Tkinter.

Here is how to reproduce the bug on your local system: Install python-2.7b2.msi into C:\Python27. Then open a command prompt with administrator privileges and start python.exe as follows:

\\%COMPUTERNAME%\C$\Python27\python.exe -c "from Tkinter import *"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "\\KLAPAUCIUS\C$\Python27\lib\lib-tk\Tkinter.py", line 38, in <module>
    import FixTk
  File "\\KLAPAUCIUS\C$\Python27\lib\lib-tk\FixTk.py", line 56, in <module>
    for name in os.listdir(prefix):
WindowsError: [Error 3] The system cannot find the path specified: 'UNC\\KLAPAUCIUS\\C$\\Python27\\tcl/*.*'



It does not matter whether the network share is mapped as a drive letter or not, the Tkinter import fails with the same WindowsError. Also mounted network drives do have problems with UAC.

A local Python installation can simply be copied to a network share and used from there from several other computers. All that eventually needs attention is the python*.dll, some scripts, and the MSVC runtime. I have deployed Python like this for years in several computer labs.

----------

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

From report at bugs.python.org  Thu Jun  3 02:11:33 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Thu, 03 Jun 2010 00:11:33 +0000
Subject: [issue6470] Tkinter import fails when running Python.exe from a
	network share
In-Reply-To: <1247430164.29.0.0724763544583.issue6470@psf.upfronthosting.co.za>
Message-ID: <1275523893.64.0.824392757878.issue6470@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

> The patch seems to deal with paths that have "UNC" in them; 
> and the test seems not to.

The UNCW path is a result of the call to ctypes.windll.kernel32.GetFinalPathNameByHandleW() in FixTk.py, which translates "\\Server\Share\File" paths to "\\?\UNC\Server\Share\File".

Simply removing the leading "\\?\" from the UNCW path, as it is done in Python 2.6.5 and 2.7b2 FixTk.py, results in an invalid "UNC\Server\Share\File" path. The proposed patch removes "UNC" and prepends a "\\", which gives a valid "\\Server\Share\File" path.

----------

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

From report at bugs.python.org  Thu Jun  3 02:42:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Jun 2010 00:42:35 +0000
Subject: [issue5423] Exception raised when attempting to call set_charset on
	an email.mime.multipart once sub-parts have been attached
In-Reply-To: <1236258073.44.0.224242973923.issue5423@psf.upfronthosting.co.za>
Message-ID: <1275525755.83.0.0714523589792.issue5423@psf.upfronthosting.co.za>


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


----------
assignee:  -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Thu Jun  3 03:27:50 2010
From: report at bugs.python.org (Edward Pilatowicz)
Date: Thu, 03 Jun 2010 01:27:50 +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: <1275528470.51.0.813873994417.issue8882@psf.upfronthosting.co.za>


New submission from Edward Pilatowicz <edward.pilatowicz at oracle.com>:

recently i was writing some python code that attempted to bind a unix
domain socket to a long filesystem path.  this code was failing and
telling me that the path name was too long.  tracing python i saw that
it wasn't event issuing a system call for my bind() request.  eventually
i tracked down the problem to socketmodule.c`getsockaddrarg():

http://svn.python.org/view/python/trunk/Modules/socketmodule.c?view=markup

there we see that getsockaddrarg() checks to verify that the specified
path is less than "sizeof addr->sun_path", where addr is a struct
sockaddr_un.  this seems incorrect to me.

on most systems sockaddr_un.sun_path is defined as a small character
array.  this limit is an ancient bit of unix legacy and most modern
systems do not actually limit domain socket names to a path as short as
sun_path.  on solaris the real limit is MAXPATHLEN, there by allowing
unix domain sockets to be bound to any filesystem path.

the posix specification also says that users of the sockaddr_un 
structure should not make any assumptions about the maximum supported
length of sun_path.

from:
    http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/un.h.html

we have:
    char        sun_path[]    socket pathname
    ...

    The size of sun_path has intentionally been left undefined. This is
    because different implementations use different sizes. For example,
    4.3 BSD uses a size of 108, and 4.4 BSD uses a size of 104. Since
    most implementations originate from BSD versions, the size is
    typically in the range 92 to 108.

    Applications should not assume a particular length for sun_path or
    assume that it can hold {_POSIX_PATH_MAX} characters (255).

hence, it seems to me that python should not actually be doing any size
checks on the path passed to getsockaddrarg().  instead is should
dynamically allocate a sockaddr_un large enough to hold whatever string
was pass in.  this structure can then be passed on to system calls which
can they check if the specified path is of a supported length.  (if you
look at the posix definitions for bind() and connect() you'll see that 
they both can return ENAMETOOLONG if the passed in pathname is too 
large.)

----------
components: None
messages: 106929
nosy: Edward.Pilatowicz
priority: normal
severity: normal
status: open
title: socketmodule.c`getsockaddrarg() should not check the length of sun_path
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun  3 04:07:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Jun 2010 02:07:05 +0000
Subject: [issue1368247] unicode in email.MIMEText and email/Charset.py
Message-ID: <1275530825.54.0.458450517193.issue1368247@psf.upfronthosting.co.za>


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

OK, py3k now passes all but one of the tests, and I've disabled that one pending email6 since fixing it would break backward compatibility within the 3.x series.  The fix is different, doing the encoding to output_charset just before calling base64mime.  This makes me think that quopri in py3k probably isn't working right, but that's a different issue.  I did not forward port the doc changes as they are inappropriate for py3k.

py3k patched in r81660, 3.1 in r81661.

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

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

From report at bugs.python.org  Thu Jun  3 08:56:56 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 03 Jun 2010 06:56:56 +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: <4C075234.1020503@v.loewis.de>


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

>      Applications should not assume a particular length for sun_path or
>      assume that it can hold {_POSIX_PATH_MAX} characters (255).
>
> hence, it seems to me that python should not actually be doing any size
> checks on the path passed to getsockaddrarg().

You are misinterpreting the specification. What they say is that the 
right way of doing it is the way Python currently does it.

"not assume a particular length" means "not assume, in the source code,
and specific fixed length, such as 108, or 255". Now, if the program 
must not assume any specific length, it must use sizeof instead to 
determine how large sun_path is.

If your operating system declares sun_path to be shorter than the 
strings it actually supports, complain to your operating system vendor 
that they fix their header files.

----------
nosy: +loewis
title: socketmodule.c`getsockaddrarg() should not check the length of sun_path -> socketmodule.c`getsockaddrarg() should not check the	length of sun_path

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

From report at bugs.python.org  Thu Jun  3 09:30:15 2010
From: report at bugs.python.org (Tal Einat)
Date: Thu, 03 Jun 2010 07:30:15 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1275550215.68.0.0403243027248.issue1766304@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

In my mind, the reason for this patch is that xrange/range can be thought of as a lazy list of integers. However without this patch, membership checking was done trivially instead of in a "smart/lazy" manner, which is unexpected for users. Finally, conditions such as "num in xrange(3, 1000, 5)" are not trivial to express correctly otherwise, and even more so for negative steps.

This patch is already implemented and accepted for 3.2, I just wish to back-port it to 2.7 which should be fairly straightforward.

I'll just have a patch ready by tomorrow, and hope that someone finds the time to review it and possibly commit it in time for rc1. I realize that this is a minor change at the last minute. I will certainly understand if the people responsible for preparing rc1 are too busy for this.

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

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

From report at bugs.python.org  Thu Jun  3 09:31:49 2010
From: report at bugs.python.org (Yuriy Taraday)
Date: Thu, 03 Jun 2010 07:31:49 +0000
Subject: [issue8883] Proxy exception lookup fails on MacOS in urllib.
In-Reply-To: <1275550309.78.0.672707816894.issue8883@psf.upfronthosting.co.za>
Message-ID: <1275550309.78.0.672707816894.issue8883@psf.upfronthosting.co.za>


New submission from Yuriy Taraday <yorik.sar at gmail.com>:

I have straight IP in my proxy exception list like "192.168.0.2" without mask specification.

The proxy_bypass_macosx_sysconf function verifies each item in this list by regexp r"(\d+(?:\.\d+)*)(/\d+)?" that produces two groups: IP and mask. The mask can be None here (as in my case) and this None case isn't handled, so urllib crashes with "TypeError: 'NoneType' object is unsubscriptable".

I couldn't find specification of MacOS proxy exceptions list, so I don't know whether you can use just IP or prefix without mask specification. If you can, here is small patch that adds nesessary check and guesses mask if it is not specified. If you cannot, the last question mark should be removed from regex.

----------
components: Library (Lib)
files: urllib.py.diff
keywords: patch
messages: 106933
nosy: yorik.sar
priority: normal
severity: normal
status: open
title: Proxy exception lookup fails on MacOS in urllib.
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file17526/urllib.py.diff

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

From report at bugs.python.org  Thu Jun  3 11:33:24 2010
From: report at bugs.python.org (Gaz Davidson)
Date: Thu, 03 Jun 2010 09:33:24 +0000
Subject: [issue8884] Allow binding to local address in httplib / http.client
In-Reply-To: <1275557604.57.0.107374927825.issue8884@psf.upfronthosting.co.za>
Message-ID: <1275557604.57.0.107374927825.issue8884@psf.upfronthosting.co.za>


New submission from Gaz Davidson <garethdavidson at gmail.com>:

The option to bind to a local IP address when creating an HTTP connection would be very useful for web testing tools like FunkLoad and webunit. 

For example in FunkLoad it would allow us to run tests with IP-based load balancing.

----------
components: IO
messages: 106934
nosy: Gaz.Davidson
priority: normal
severity: normal
status: open
title: Allow binding to local address in httplib / http.client
type: feature request
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Jun  3 11:48:46 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Jun 2010 09:48:46 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1275558526.03.0.522035955062.issue7724@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've applied a new version of the patch in r81662.

I'll be monitoring the buildbot farm to ensure that any issues that might crop up get fixed ASAP.

----------

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

From report at bugs.python.org  Thu Jun  3 12:18:11 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 03 Jun 2010 10:18:11 +0000
Subject: [issue8833] tarfile:  broken hardlink handling and testcase.
In-Reply-To: <1274976429.42.0.686584361847.issue8833@psf.upfronthosting.co.za>
Message-ID: <1275560291.15.0.13039348457.issue8833@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Thank you very much for this valuable report. Fixed in r81663-81666.

----------
resolution:  -> accepted
status: open -> closed
versions: +Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Jun  3 12:31:42 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 03 Jun 2010 10:31:42 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1275561102.26.0.617425562276.issue3864@psf.upfronthosting.co.za>


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

On 2.6, the tests aren't skipped if test_support.verbose is 0.

David, if the fix looks good to you I can apply it.


test_itimer_virtual: timeout: likely cause: machine too slow or load too high.
test test_signal failed -- Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/2.6.bolen-freebsd/build/Lib/test/test_signal.py", line 183, in test_main
    self.fail(tb)
AssertionError: Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/2.6.bolen-freebsd/build/Lib/test/test_signal.py", line 166, in test_main
    self.run_test()
  File "/usr/home/db3l/buildarea/2.6.bolen-freebsd/build/Lib/test/test_signal.py", line 99, in run_test
    self.assertTrue(self.a_called)
  File "/usr/home/db3l/buildarea/2.6.bolen-freebsd/build/Lib/unittest.py", line 325, in failUnless
    if not expr: raise self.failureException, msg
AssertionError

----------
keywords: +patch
nosy: +skrah
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file17527/issue3864-skip-when-not-verbose.patch

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

From report at bugs.python.org  Thu Jun  3 13:14:11 2010
From: report at bugs.python.org (Mark Nottingham)
Date: Thu, 03 Jun 2010 11:14:11 +0000
Subject: [issue8885] markerbase declaration errors aren't recoverable
In-Reply-To: <1275563651.6.0.351540013915.issue8885@psf.upfronthosting.co.za>
Message-ID: <1275563651.6.0.351540013915.issue8885@psf.upfronthosting.co.za>


New submission from Mark Nottingham <mnot at mnot.net>:

In markupbase.py's ParserBase.parse_declaration, an unexpected character is caught like this:

            else:
                self.error(
                    "unexpected %r char in declaration" % rawdata[j])

However, the position (j) isn't updated, which means that error() will be called again once it returns.

For example, this declaration:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" http://www.w3.org/TR/html4/loose.dtd>

(which I think is generated by MS Office) will trigger this behaviour.

Two possible resolutions:

1) increment J and try the next character in this case

2) document that error() is not recoverable; i.e., it MUST raise an exception.

My preference is strongly for #1 (as HTML parsing should be forgiving, and HTMLParser is based upon markerbase).

----------
components: Library (Lib)
messages: 106938
nosy: mnot
priority: normal
severity: normal
status: open
title: markerbase declaration errors aren't recoverable
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun  3 13:21:39 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 03 Jun 2010 11:21:39 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1275564099.43.0.449773112665.issue7384@psf.upfronthosting.co.za>


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

I think it would be nice to get this into 2.7. I don't expect buildbot
failures, since the 2.7 patch is essentially the same as the py3k version,
which has been tested extensively.

----------
Added file: http://bugs.python.org/file17528/issue7384-5-trunk.patch

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

From report at bugs.python.org  Thu Jun  3 13:35:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 03 Jun 2010 11:35:32 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1275564932.08.0.298108149058.issue7384@psf.upfronthosting.co.za>


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

> I think it would be nice to get this into 2.7.

Agreed.  I think you should go ahead and commit it.

----------

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

From report at bugs.python.org  Thu Jun  3 13:39:27 2010
From: report at bugs.python.org (Erik Carstensen)
Date: Thu, 03 Jun 2010 11:39:27 +0000
Subject: [issue8886] zipfile.ZipExtFile should be a context manager
In-Reply-To: <1275565167.77.0.94387257463.issue8886@psf.upfronthosting.co.za>
Message-ID: <1275565167.77.0.94387257463.issue8886@psf.upfronthosting.co.za>


New submission from Erik Carstensen <sandberg at virtutech.com>:

It's nice that ZipFile is a context manager in 2.7.  It would be nice and more consistent if the objects returned from ZipFile.open() were context managers too.

----------
components: Library (Lib)
messages: 106941
nosy: sandberg
priority: normal
severity: normal
status: open
title: zipfile.ZipExtFile should be a context manager
type: feature request
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Jun  3 13:42:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 11:42:54 +0000
Subject: =?utf-8?b?W2lzc3VlODg4N10g4oCccHlkb2Mgc3Ry4oCdIHdvcmtzIGJ1dCBub3Qg4oCc?=
	=?utf-8?q?pydoc_str=2Etranslate=E2=80=9D?=
In-Reply-To: <1275565374.87.0.956319261544.issue8887@psf.upfronthosting.co.za>
Message-ID: <1275565374.87.0.956319261544.issue8887@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Inconsistent behavior:
pydoc3 str: works
pydoc3 str.translate: doesn?t
pydoc3 builtins.str: works
pydoc3 builtins.str.translate: doesn?t

I think pydoc3 str.translate should work. I?ll be able to try to write a patch in some weeks.

----------
components: Library (Lib)
messages: 106942
nosy: merwok
priority: normal
severity: normal
status: open
title: ?pydoc str? works but not ?pydoc str.translate?
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Jun  3 13:49:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 11:49:59 +0000
Subject: [issue8888] Promote SafeConfigParser and warn about ConfigParser
In-Reply-To: <1275565799.83.0.624762218664.issue8888@psf.upfronthosting.co.za>
Message-ID: <1275565799.83.0.624762218664.issue8888@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Problems like #8880 could be prevented with a deprecation notice for the ConfigParser class, in favor of SafeConfigParser. (Not sure if R.?David Murray meant just a recommendation or a real deprecation.)

----------
assignee: docs at python
components: Documentation
messages: 106943
nosy: docs at python, merwok, r.david.murray
priority: normal
severity: normal
status: open
title: Promote SafeConfigParser and warn about ConfigParser
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Jun  3 13:50:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 11:50:21 +0000
Subject: [issue8880] ConfigParser.set does not convert non-string values
In-Reply-To: <1275512498.11.0.636017814706.issue8880@psf.upfronthosting.co.za>
Message-ID: <1275565821.42.0.844209930836.issue8880@psf.upfronthosting.co.za>


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

See #8888

----------

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

From report at bugs.python.org  Thu Jun  3 14:10:19 2010
From: report at bugs.python.org (Erik Carstensen)
Date: Thu, 03 Jun 2010 12:10:19 +0000
Subject: [issue8886] zipfile.ZipExtFile is a context manager,
	but that is not documented
In-Reply-To: <1275565167.77.0.94387257463.issue8886@psf.upfronthosting.co.za>
Message-ID: <1275567019.29.0.917548486036.issue8886@psf.upfronthosting.co.za>


Erik Carstensen <sandberg at virtutech.com> added the comment:

Sorry, my mistake, ZipExtFile is indeed a context manager: I ran into the problem in 2.6, and checked whether it was fixed in 2.7; when quickly reading zipfile.py I saw that only ZipFile had context manager methods, I missed the BufferedIOBase inheritance. And when reading the tests I didn't see any 'with ZipFile.open(x) as y' expression.

Maybe it still makes sense to document and test this. Changing the title.

----------
title: zipfile.ZipExtFile should be a context manager -> zipfile.ZipExtFile is a context manager, but that is not documented

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

From report at bugs.python.org  Thu Jun  3 14:32:59 2010
From: report at bugs.python.org (Erik Carstensen)
Date: Thu, 03 Jun 2010 12:32:59 +0000
Subject: [issue8886] zipfile.ZipExtFile is a context manager,
	but that is not documented
In-Reply-To: <1275565167.77.0.94387257463.issue8886@psf.upfronthosting.co.za>
Message-ID: <1275568379.96.0.746640158148.issue8886@psf.upfronthosting.co.za>


Erik Carstensen <sandberg at virtutech.com> added the comment:

Patch that makes the zipfile test consistently use with statements to handle the return value of ZipFile.open().

----------
keywords: +patch
Added file: http://bugs.python.org/file17529/with-ZipExtFile-in-test.patch

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

From report at bugs.python.org  Thu Jun  3 14:49:59 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 03 Jun 2010 12:49:59 +0000
Subject: [issue8741] 2.7 regression in tarfile: IOError: link could not be
	created
In-Reply-To: <1274118345.32.0.801692184283.issue8741@psf.upfronthosting.co.za>
Message-ID: <1275569399.04.0.969933185967.issue8741@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I have just committed the fix. I hope that this code is now more robust. See r81667 (trunk) and r81670 (py3k).

Thank you very much for your report!

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

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

From report at bugs.python.org  Thu Jun  3 14:57:14 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 03 Jun 2010 12:57:14 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1275569834.72.0.239551934436.issue7384@psf.upfronthosting.co.za>


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

Mark, thanks. Committed in r81669; I'll keep an eye on the buildbots.

----------

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

From report at bugs.python.org  Thu Jun  3 15:29:35 2010
From: report at bugs.python.org (July Tikhonov)
Date: Thu, 03 Jun 2010 13:29:35 +0000
Subject: [issue8862] curses.wrapper does not restore terminal if
	curses.getkey() gets KeyboardInterrupt
In-Reply-To: <1275330239.59.0.0964939469403.issue8862@psf.upfronthosting.co.za>
Message-ID: <1275571775.74.0.761993511843.issue8862@psf.upfronthosting.co.za>


July Tikhonov <july.tikh at gmail.com> added the comment:

Patch added.

Calls PyErr_CheckSignals(). If nothing happens, raises _curses.error.

----------
keywords: +patch
Added file: http://bugs.python.org/file17530/curses-getkey.patch

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

From report at bugs.python.org  Thu Jun  3 15:37:53 2010
From: report at bugs.python.org (Edwin Pozharski)
Date: Thu, 03 Jun 2010 13:37:53 +0000
Subject: [issue8880] ConfigParser.set does not convert non-string values
In-Reply-To: <1275514399.16.0.8441694431.issue8880@psf.upfronthosting.co.za>
Message-ID: <AANLkTilYkY0dD5xWCsehYuP3HenCvi-ttKC528enMKTh@mail.gmail.com>


Edwin Pozharski <pozharski at gmail.com> added the comment:

Thanks - gotta rtfm :)

On Wed, Jun 2, 2010 at 5:33 PM, R. David Murray <report at bugs.python.org>wrote:

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> Use SafeConfigParser instead, then you can't make the mistake of passing
> non-strings to set.
>
> We really should update the docs so that ConfigParser is doced only in a
> 'deprecated' section.  But that's a different issue.  (Care to open it,
> merwok? :)
>
> ----------
> nosy: +r.david.murray
> resolution:  -> wont fix
> stage:  -> committed/rejected
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8880>
> _______________________________________
>

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8880>
_______________________________________
-------------- next part --------------
Thanks - gotta rtfm :)<br><br><div class="gmail_quote">On Wed, Jun 2, 2010 at 5:33 PM, R. David Murray <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>
R. David Murray &lt;<a href="mailto:rdmurray at bitdance.com">rdmurray at bitdance.com</a>&gt; added the comment:<br>
<br>
Use SafeConfigParser instead, then you can&#39;t make the mistake of passing non-strings to set.<br>
<br>
We really should update the docs so that ConfigParser is doced only in a &#39;deprecated&#39; section. ??But that&#39;s a different issue. ??(Care to open it, merwok? :)<br>
<br>
----------<br>
nosy: +r.david.murray<br>
resolution: ??-&gt; wont fix<br>
stage: ??-&gt; committed/rejected<br>
status: open -&gt; closed<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/issue8880" target="_blank">http://bugs.python.org/issue8880</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Thu Jun  3 15:50:48 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Jun 2010 13:50:48 +0000
Subject: [issue8883] Proxy exception lookup fails on MacOS in urllib.
In-Reply-To: <1275550309.78.0.672707816894.issue8883@psf.upfronthosting.co.za>
Message-ID: <1275573048.61.0.393029298349.issue8883@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Patchs looks file, although the 'None' branch might be a bit too fancy. I haven't found a spec either, and therefore your code is probably the safest way to deduce a mask.

----------
assignee:  -> ronaldoussoren
nosy: +ronaldoussoren

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

From report at bugs.python.org  Thu Jun  3 16:16:38 2010
From: report at bugs.python.org (Yuriy Taraday)
Date: Thu, 03 Jun 2010 14:16:38 +0000
Subject: [issue8883] Proxy exception lookup fails on MacOS in urllib.
In-Reply-To: <1275550309.78.0.672707816894.issue8883@psf.upfronthosting.co.za>
Message-ID: <1275574598.68.0.77190380998.issue8883@psf.upfronthosting.co.za>


Yuriy Taraday <yorik.sar at gmail.com> added the comment:

The strange thing is that in both 2.7 and 3.1 branches there is no such code at all. Inernet Config is used there without mentioning any exceptions despite the fact that ic module is marked as deprecated and proxy bypass is real.

----------

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

From report at bugs.python.org  Thu Jun  3 16:24:54 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Jun 2010 14:24:54 +0000
Subject: [issue8883] Proxy exception lookup fails on MacOS in urllib.
In-Reply-To: <1275550309.78.0.672707816894.issue8883@psf.upfronthosting.co.za>
Message-ID: <1275575094.24.0.990751752895.issue8883@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

2.7 and 3.x use the SystemConfiguration framework (through the _scproxy extension)

----------

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

From report at bugs.python.org  Thu Jun  3 16:33:47 2010
From: report at bugs.python.org (Yuriy Taraday)
Date: Thu, 03 Jun 2010 14:33:47 +0000
Subject: [issue8883] Proxy exception lookup fails on MacOS in urllib.
In-Reply-To: <1275550309.78.0.672707816894.issue8883@psf.upfronthosting.co.za>
Message-ID: <1275575627.68.0.111639666081.issue8883@psf.upfronthosting.co.za>


Yuriy Taraday <yorik.sar at gmail.com> added the comment:

I'm completely lost 2.7 tree in svn.
My last post was about 3.1.2 release. As I understand, System Configuration framework is being used since 2.6.5 and 3.2.
So, this bug is about all this versions.

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

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

From report at bugs.python.org  Thu Jun  3 16:42:48 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Jun 2010 14:42:48 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1275576168.74.0.162099136667.issue7724@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Ported to 3.2 in r81673.

----------

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

From report at bugs.python.org  Thu Jun  3 16:46:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 03 Jun 2010 14:46:51 +0000
Subject: [issue2568] Seconds range in time unit
In-Reply-To: <1207551193.66.0.586350051723.issue2568@psf.upfronthosting.co.za>
Message-ID: <1275576411.02.0.710358184752.issue2568@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am reopening this issue because the following note is still not entirely correct:

"""
The range really is 0 to 61; according to the Posix standard this accounts for leap seconds and the (very rare) double leap seconds. The time module may produce and does accept leap seconds since it is based on the Posix standard ...
""" - http://docs.python.org/library/datetime.html#strftime-and-strptime-behavior


First, the latest POSIX standard (IEEE Std 1003.1, 2004 Edition) defines seconds range as [0, 60]. 

http://www.opengroup.org/onlinepubs/009695399/basedefs/time.h.html

Second, AFAIK, the only way to produce tm structure with tm_sec = 60 using a POSIX function is to explicitly pass "60" to a "%S" field in strptime. Other functions that fill tm structure, such as localtime or gmtime will never produce tm_sec = 60.  This is important because in the current form the comment suggests that the common recipe of passing first six elements of time.struct_time() to datetime constructor is unsafe while it is only unsafe if the time information comes from a non-POSIX system.

Third, POSIX is not a relevant standard for Python.  I have not seen any statement of python compliance to any version of Posix.  The relevant standard, I believe is C89:

"""
 Python now must be compiled with C89 compilers (after 19 years!).
""" - http://docs.python.org/whatsnew/2.6.html

While strictly speaking this is not a compliance statement, at least it has Python and C89 in the same sentence. :-)

AFAIK, the C89 standard does allow double leap seconds.  It may also allow compliant systems to produce leap second times from localtime() or gmtime(), but I don't have access to the text at the moment.  If this is true, the only fix required is s/POSIX/C89/g.

----------
assignee:  -> belopolsky
nosy: +mark.dickinson
resolution: fixed -> 
stage: patch review -> needs patch
status: closed -> open
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jun  3 16:47:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 14:47:24 +0000
Subject: [issue4673] Distutils should provide an uninstall command
In-Reply-To: <1229380134.57.0.765808366709.issue4673@psf.upfronthosting.co.za>
Message-ID: <1275576444.18.0.842220404998.issue4673@psf.upfronthosting.co.za>


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


----------
components: +Distutils2 -Distutils
keywords: +gsoc
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/issue4673>
_______________________________________

From report at bugs.python.org  Thu Jun  3 16:53:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 14:53:13 +0000
Subject: [issue2279] distutils sdist add_defaults does not add data_files
In-Reply-To: <1205333612.66.0.693918609529.issue2279@psf.upfronthosting.co.za>
Message-ID: <1275576793.54.0.739928237281.issue2279@psf.upfronthosting.co.za>


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


----------
resolution: accepted -> fixed
stage:  -> committed/rejected

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

From report at bugs.python.org  Thu Jun  3 16:54:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 14:54:56 +0000
Subject: [issue5300] Distutils ignores file permissions
In-Reply-To: <1234907694.25.0.317480697226.issue5300@psf.upfronthosting.co.za>
Message-ID: <1275576896.42.0.935825454503.issue5300@psf.upfronthosting.co.za>


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


----------
nosy: +merwok

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

From report at bugs.python.org  Thu Jun  3 17:00:30 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Jun 2010 15:00:30 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1275577230.46.0.300204373265.issue7724@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Committed for 2.6 in r81674

----------

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

From report at bugs.python.org  Thu Jun  3 17:06:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 03 Jun 2010 15:06:04 +0000
Subject: [issue6608] asctime causing python to crash
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1275577564.28.0.333979037855.issue6608@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Here is a quote from the relevant CERT advisory (MSC33-C):

"""
This function is supposed to output a character string of 26 positions at most, including the terminating zero. If we count the length indicated by the format directives we arrive at 25. Taking into account the terminating zero, the array size of the string appears sufficient.

However, this implementation assumes that the values of the struct tm data in timeptr are within normal ranges, and does nothing to enforce this. If any of the values print more characters than expected, the sprintf() function may overflow the result array. For instance, if tm_year has the value 12345, then 27 characters (including the terminating null character) are printed, resulting in a buffer overflow.

The asctime() function primarily exists for compatibility with older implementations. Also, the asctime() function does not support localized date and time formats. The POSIX standard developers decided to mark the asctime() function obsolescent even though they are in C99 because of the possibility of buffer overflow.

C99 also provides the strftime() function which can be used to avoid these problems.
""" https://www.securecoding.cert.org/confluence/display/seccode/MSC33-C.+Do+not+pass+invalid+data+to+the+asctime%28%29+function

(I am changing the stage back to "needs patch" because the current patch  is vulnerable to buffer overflow.)

I think it is best to leave the code as is and possibly add a warning in documentation that passing hand-crafted timetuple is unsafe on some systems and that locale aware strftime("%c", ..) is preferable to asctime.

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

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

From report at bugs.python.org  Thu Jun  3 17:30:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Jun 2010 15:30:33 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1275579033.17.0.86646236722.issue3864@psf.upfronthosting.co.za>


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

I can't believe I messed that up.  Yes, the patch looks fine, please apply.

----------

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

From report at bugs.python.org  Thu Jun  3 17:46:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Jun 2010 15:46:46 +0000
Subject: [issue5610] email feedparser.py CRLFLF bug: $ vs \Z
In-Reply-To: <1238435977.23.0.604038870745.issue5610@psf.upfronthosting.co.za>
Message-ID: <1275580006.3.0.646983374289.issue5610@psf.upfronthosting.co.za>


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

I've applied the NLCRE_eol part of the patch, and the test, in r81675.  Tony, can you think of a test case that would demonstrate the problem with the boundaryre?

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

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

From report at bugs.python.org  Thu Jun  3 18:15:42 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 03 Jun 2010 16:15:42 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1275581742.21.0.227733296876.issue3864@psf.upfronthosting.co.za>


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

Thanks for looking at the patch! Committed in r81676.

----------
resolution:  -> accepted
status: open -> closed

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

From report at bugs.python.org  Thu Jun  3 18:21:01 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 03 Jun 2010 16:21:01 +0000
Subject: [issue8424] Test assumptions for test_itimer_virtual and
	test_itimer_prof
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1275582061.78.0.873364891163.issue8424@psf.upfronthosting.co.za>


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

I can't find buildbot failures related to this any longer, so I'm closing
this one.

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

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

From report at bugs.python.org  Thu Jun  3 18:21:44 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Jun 2010 16:21:44 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1275582104.06.0.548041050589.issue7724@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

And for 3.1 in r81677.

----------

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

From report at bugs.python.org  Thu Jun  3 18:31:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Jun 2010 16:31:23 +0000
Subject: [issue4487] Add utf8 alias for email charsets
In-Reply-To: <1228223832.43.0.0399583143577.issue4487@psf.upfronthosting.co.za>
Message-ID: <1275582683.23.0.384513249134.issue4487@psf.upfronthosting.co.za>


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

For various reasons the email module has a table of character sets.  What might be most effective would be for the email module to look a character set name up in the codecs module and find out the cannonical name of the character set, and then look that up in its table (ie: remove the aliases table from email completely, and instead depend on codecs to resolve the cannonical name).  Unfortunately the codecs module does not recognize all of the aliases used by email, nor is there necessarily any guarantee that the two modules will agree on the proper cannonical name.

The attached patch instead uses the codecs module as a fallback if the charset name does not appear in the email package's ALIASES or CHARSETS tables.  It therefore makes both utf8 and utf_8 work, as well as all the other variants the codec module accepts.  The unit test just tests 'utf8', since if that one works all the others should too.

I'm tentatively reclassifying this as a bug rather than a feature request, since I think it is a reasonable expectation that email would support at least the same set of encoding names that the rest of Python does.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Thu Jun  3 18:31:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Jun 2010 16:31:58 +0000
Subject: [issue4487] Add utf8 alias for email charsets
In-Reply-To: <1228223832.43.0.0399583143577.issue4487@psf.upfronthosting.co.za>
Message-ID: <1275582718.61.0.381612082401.issue4487@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file17532/email_accept_codec_aliases.patch

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

From report at bugs.python.org  Thu Jun  3 18:32:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Jun 2010 16:32:28 +0000
Subject: [issue4487] Add utf8 alias for email charsets
In-Reply-To: <1228223832.43.0.0399583143577.issue4487@psf.upfronthosting.co.za>
Message-ID: <1275582748.47.0.10648952378.issue4487@psf.upfronthosting.co.za>


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


----------
assignee:  -> r.david.murray
stage:  -> patch review
type: feature request -> behavior

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

From report at bugs.python.org  Thu Jun  3 18:36:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 16:36:34 +0000
Subject: [issue4487] Add utf8 alias for email charsets
In-Reply-To: <1228223832.43.0.0399583143577.issue4487@psf.upfronthosting.co.za>
Message-ID: <1275582994.43.0.927417300364.issue4487@psf.upfronthosting.co.za>


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

Idea: Import the aliases mapping from codecs and extend it with email-specific aliases. Alternate idea: Add email?s names to codecs.

Side note: ?charset? stands for ?character encoding?, not ?character set?. See <http://www.w3.org/International/questions/qa-what-is-encoding#what>

----------
nosy: +merwok

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

From report at bugs.python.org  Thu Jun  3 19:28:47 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Jun 2010 17:28:47 +0000
Subject: [issue1766304] improve xrange.__contains__
In-Reply-To: <1275550215.68.0.0403243027248.issue1766304@psf.upfronthosting.co.za>
Message-ID: <AANLkTilq64S--4afQ6y5zrUC8ITQm4X_d85srKXnoqup@mail.gmail.com>


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

2010/6/3 Tal Einat <report at bugs.python.org>:
>
> Tal Einat <taleinat at users.sourceforge.net> added the comment:
>
> In my mind, the reason for this patch is that xrange/range can be thought of as a lazy list of integers. However without this patch, membership checking was done trivially instead of in a "smart/lazy" manner, which is unexpected for users. Finally, conditions such as "num in xrange(3, 1000, 5)" are not trivial to express correctly otherwise, and even more so for negative steps.
>
> This patch is already implemented and accepted for 3.2, I just wish to back-port it to 2.7 which should be fairly straightforward.
>
> I'll just have a patch ready by tomorrow, and hope that someone finds the time to review it and possibly commit it in time for rc1. I realize that this is a minor change at the last minute. I will certainly understand if the people responsible for preparing rc1 are too busy for this.

xrange has behaved like this for such a long time that I don't see
what it buys us to commit the patch this late.

----------

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

From report at bugs.python.org  Thu Jun  3 19:32:05 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Jun 2010 17:32:05 +0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1275586325.17.0.17833540344.issue1766304@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> accepted
status: open -> closed

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

From report at bugs.python.org  Thu Jun  3 19:58:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 03 Jun 2010 17:58:05 +0000
Subject: [issue8884] Allow binding to local address in http.client
In-Reply-To: <1275557604.57.0.107374927825.issue8884@psf.upfronthosting.co.za>
Message-ID: <1275587885.53.0.967607394803.issue8884@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
title: Allow binding to local address in httplib / http.client -> Allow binding to local address in http.client
versions: +Python 3.2 -Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Jun  3 20:05:13 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 03 Jun 2010 18:05:13 +0000
Subject: [issue8884] Allow binding to local address in http.client
In-Reply-To: <1275557604.57.0.107374927825.issue8884@psf.upfronthosting.co.za>
Message-ID: <1275588313.52.0.873402365584.issue8884@psf.upfronthosting.co.za>


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

Can you please elaborate? Why would binding be useful?

In any case, what's wrong with 2.7's source_address parameter?

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

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

From report at bugs.python.org  Thu Jun  3 20:16:13 2010
From: report at bugs.python.org (Gaz Davidson)
Date: Thu, 03 Jun 2010 18:16:13 +0000
Subject: [issue8884] Allow binding to local address in http.client
In-Reply-To: <1275557604.57.0.107374927825.issue8884@psf.upfronthosting.co.za>
Message-ID: <1275588973.51.0.13218783457.issue8884@psf.upfronthosting.co.za>


Gaz Davidson <garethdavidson at gmail.com> added the comment:

Oops, I didn't see that in the 2.7 docs, I'll make sure I RTFM in future!

source_address will do perfectly, sorry for wasting your time and thanks for the quick response.

Cheers

Gaz

----------

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

From report at bugs.python.org  Thu Jun  3 20:21:27 2010
From: report at bugs.python.org (Jeff Craig)
Date: Thu, 03 Jun 2010 18:21:27 +0000
Subject: [issue8820] IDLE not launching correctly
In-Reply-To: <1274842084.45.0.257196773636.issue8820@psf.upfronthosting.co.za>
Message-ID: <1275589287.8.0.133647823807.issue8820@psf.upfronthosting.co.za>


Jeff Craig <foxxtrot at foxxtrot.net> added the comment:

I can confirm this behaviour and error. On Windows Server 2008 R2 64-bit.

----------
nosy: +foxxtrot

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

From report at bugs.python.org  Thu Jun  3 20:30:23 2010
From: report at bugs.python.org (Jeff Craig)
Date: Thu, 03 Jun 2010 18:30:23 +0000
Subject: [issue8820] IDLE not launching correctly
In-Reply-To: <1274842084.45.0.257196773636.issue8820@psf.upfronthosting.co.za>
Message-ID: <1275589823.97.0.320115416613.issue8820@psf.upfronthosting.co.za>


Jeff Craig <foxxtrot at foxxtrot.net> added the comment:

Further information, this was an issue for me in 2.6.4, but with 2.6.5 it appears to no longer be an issue.

----------

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

From report at bugs.python.org  Thu Jun  3 20:36:41 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 03 Jun 2010 18:36:41 +0000
Subject: [issue8884] Allow binding to local address in http.client
In-Reply-To: <1275557604.57.0.107374927825.issue8884@psf.upfronthosting.co.za>
Message-ID: <1275590201.29.0.277726338778.issue8884@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


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

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

From report at bugs.python.org  Thu Jun  3 20:46:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 03 Jun 2010 18:46:34 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275590794.55.0.501110507148.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching the next installment of the datetime.timezone class implementation.

Here I add ``utc`` class attribute to timezone.  I decided to place it in class rather than module namespace because this seems to be more inline with how datetime module defines particular instances of its classes such as ``min``, ``max`` and ``resolution``. I also feel that writing ``timezone.utc`` makes it clearer that its is an instance of ``timezone`` class while ``datetime.UTC`` or simply ``UTC`` is more ambiguous.

I also changed ``timezone`` constructor to interpret int or float offset as number of hours and accept arbitrary timedelta between timedelta(hours=-12) and timedelta(hours=12).  The rationale is that most common timezones have offsets at whole hours and less common but existing timezones use 1/2 or 1/4 hour offsets and thus can be specified as a binary float without any issue.

I've added tests and some preliminary documentation.

----------
Added file: http://bugs.python.org/file17533/issue5094a.diff

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

From report at bugs.python.org  Thu Jun  3 20:50:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Jun 2010 18:50:06 +0000
Subject: [issue8889] test_support.transient_internet fails on Freebsd because
	socket has no attribute EAI_NODATA
In-Reply-To: <1275591006.22.0.670569241556.issue8889@psf.upfronthosting.co.za>
Message-ID: <1275591006.22.0.670569241556.issue8889@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

test_support.transient_internet was modified to check for more errors, but one of them, socket.EAI_NODATA, is not supported by FreeBSD.  The attached patch rewrites transient_internet to only test EAI error codes that exist, and also improves the skip message.

----------
components: Tests
files: transient_internet.patch
keywords: patch
messages: 106972
nosy: haypo, r.david.murray
priority: normal
severity: normal
status: open
title: test_support.transient_internet fails on Freebsd because socket has no attribute EAI_NODATA
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17534/transient_internet.patch

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

From report at bugs.python.org  Thu Jun  3 20:50:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Jun 2010 18:50:58 +0000
Subject: [issue8889] test_support.transient_internet fails on Freebsd because
	socket has no attribute EAI_NODATA
In-Reply-To: <1275591006.22.0.670569241556.issue8889@psf.upfronthosting.co.za>
Message-ID: <1275591058.49.0.184963708028.issue8889@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/issue8889>
_______________________________________

From report at bugs.python.org  Thu Jun  3 21:15:58 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 03 Jun 2010 19:15:58 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275592558.56.0.269028568798.issue5094@psf.upfronthosting.co.za>


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

I don't think people would get confused as to what datetime.utc was, but as you pointed out, Alexander, the module seems to like class attributes so timezone.utc is fine.

As for the float/int argument, I personally am wary of it. Since the timedelta constructor accepts hours as a keyword argument, I don't see the benefit of having to support both timedeltas and int/floats. And I can see someone messing up and putting in a float that is not perfectly representable and getting upset at odd behavior. I say keep it simple and just accept timedeltas for now. If there really is demand for accepting integers in the constructor than it can be added without backwards-compatibility issues. Better to keep the API small and expand later than make it too big to start and being burdened with extraneous API stuff.

----------

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

From report at bugs.python.org  Thu Jun  3 21:19:14 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 03 Jun 2010 19:19:14 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275592754.62.0.279269665035.issue5094@psf.upfronthosting.co.za>


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

> accept arbitrary timedelta between timedelta(hours=-12) and
> timedelta(hours=12)

Aren't there valid timezones that are offset by more than 12 hours from UTC?

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Thu Jun  3 21:28:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Jun 2010 19:28:41 +0000
Subject: [issue8889] test_support.transient_internet fails on Freebsd because
	socket has no attribute EAI_NODATA
In-Reply-To: <1275591006.22.0.670569241556.issue8889@psf.upfronthosting.co.za>
Message-ID: <1275593321.11.0.979675722935.issue8889@psf.upfronthosting.co.za>


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

Modified patch based on feedback from Antoine Pitrou on #python-dev.

----------
Added file: http://bugs.python.org/file17535/transient_internet.patch

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

From report at bugs.python.org  Thu Jun  3 21:41:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 03 Jun 2010 19:41:21 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1275592754.62.0.279269665035.issue5094@psf.upfronthosting.co.za>
Message-ID: <AANLkTim0ksjD71bZDANdWxVAHyetQUQ48FBVqc67lse3@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Jun 3, 2010 at 3:19 PM, Mark Dickinson <report at bugs.python.org> wrote:
..
> Aren't there valid timezones that are offset by more than 12 hours from UTC?

I am not sure.   At this stage treat 12 as a placeholder for whatever
the relevant standard says.  I've seen suggestions that the range
should be (-24, 24) excluding ends
<http://www.zope.org/Members/fdrake/DateTimeWiki/BasicDesign> and
[-14, 14] <http://msdn.microsoft.com/en-us/library/bb630289.aspx>.

----------

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

From report at bugs.python.org  Thu Jun  3 21:41:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Jun 2010 19:41:22 +0000
Subject: [issue8889] test_support.transient_internet fails on Freebsd because
	socket has no attribute EAI_NODATA
In-Reply-To: <1275591006.22.0.670569241556.issue8889@psf.upfronthosting.co.za>
Message-ID: <1275594082.78.0.336096440613.issue8889@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file17535/transient_internet.patch

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

From report at bugs.python.org  Thu Jun  3 21:50:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 03 Jun 2010 19:50:46 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <AANLkTim0ksjD71bZDANdWxVAHyetQUQ48FBVqc67lse3@mail.gmail.com>
Message-ID: <AANLkTimLSg_zzF2o_vIsKRdWXapDY0GS5uJfyz3GwiBL@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Jun 3, 2010 at 3:41 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
..
> I am not sure. ? At this stage treat 12 as a placeholder for whatever
> the relevant standard says.

Believe it or not, at least one standard, RFC 2822, allows any offset
representable as HHMM: "the zone MUST be within the range -9959
through +9959" <http://tools.ietf.org/html/rfc2822.html>.

I am inclined to simply remove any range checking and allow arbitrary
timedelta as an offset.

----------

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

From report at bugs.python.org  Thu Jun  3 21:53:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Jun 2010 19:53:24 +0000
Subject: [issue8889] test_support.transient_internet fails on Freebsd because
	socket has no attribute EAI_NODATA
In-Reply-To: <1275591006.22.0.670569241556.issue8889@psf.upfronthosting.co.za>
Message-ID: <1275594804.88.0.990693137742.issue8889@psf.upfronthosting.co.za>


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

A somewhat more clever version.

----------
Added file: http://bugs.python.org/file17536/transient_internet.patch

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

From report at bugs.python.org  Thu Jun  3 22:02:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Jun 2010 20:02:28 +0000
Subject: [issue8889] test_support.transient_internet fails on Freebsd because
	socket has no attribute EAI_NODATA
In-Reply-To: <1275591006.22.0.670569241556.issue8889@psf.upfronthosting.co.za>
Message-ID: <1275595348.34.0.0622589576073.issue8889@psf.upfronthosting.co.za>


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

Final version after more feedback.

----------
Added file: http://bugs.python.org/file17537/transient_internet.patch

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

From report at bugs.python.org  Thu Jun  3 22:06:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 03 Jun 2010 20:06:44 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1275592558.56.0.269028568798.issue5094@psf.upfronthosting.co.za>
Message-ID: <AANLkTinFZtW07lxvrjUrcK4IaW-_6PkNDtSyGQBj4zRZ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Jun 3, 2010 at 3:15 PM, Brett Cannon <report at bugs.python.org> wrote:
..
> As for the float/int argument, I personally am wary of it. Since the
> timedelta constructor accepts hours as a keyword argument, I don't
> see the benefit of having to support both timedeltas and int/floats.

To my taste, timedelta(hours=-5) is just too verbose.  It also forces
you to import timedelta in a module that may otherwise not need it.

> And I can see someone messing up and putting in a float that is not > perfectly representable and getting upset at odd behavior.

Since timedelta accepts floats for hours, this argument does not
really hold.  Also, with timedelta correctly rounding to the nearest
microsecond, it is really hard to mess up with binary vs. decimal
representation.

> I say keep it simple and just accept timedeltas for now. If there
> really is demand for accepting integers in the constructor than it can > be added without backwards-compatibility issues. Better to keep the > API small and expand later than make it too big to start and being
> burdened with extraneous API stuff.
>

This a valid argument.  since it is easier to remove code than to add,
I'll keep int/float support in the patch while we are discussing the
design, but I am ready to remove it.

----------

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

From report at bugs.python.org  Thu Jun  3 22:13:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 03 Jun 2010 20:13:33 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275596013.75.0.883584795143.issue5094@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky

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

From report at bugs.python.org  Thu Jun  3 22:21:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Jun 2010 20:21:16 +0000
Subject: [issue8889] test_support.transient_internet fails on Freebsd because
	socket has no attribute EAI_NODATA
In-Reply-To: <1275591006.22.0.670569241556.issue8889@psf.upfronthosting.co.za>
Message-ID: <1275596476.36.0.688395069733.issue8889@psf.upfronthosting.co.za>


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

Committed to trunk in r81678.  I'll wait until the trunk buildbots show the test_ssl and test_urllib2net error clear before back/forward porting.

----------
stage:  -> commit review

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

From report at bugs.python.org  Thu Jun  3 23:11:55 2010
From: report at bugs.python.org (Henri Salo)
Date: Thu, 03 Jun 2010 21:11:55 +0000
Subject: [issue8890] Module logging has dangerous examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>


New submission from Henri Salo <henri at nerv.fi>:

Module logging has dangerous examples as one can see from: <http://docs.python.org/library/logging.html#simple-examples> 15.6.1.1:

> import logging
> LOG_FILENAME = '/tmp/logging_example.out'
> logging.basicConfig(filename=LOG_FILENAME,level=logging.DEBUG)
> logging.debug('This message should go to the log file')

It is not very wise to guide programmers to create programming mistakes. More information about the situation from: <http://www.owasp.org/index.php/Insecure_Temporary_File>.

----------
components: None
messages: 106982
nosy: Henri.Salo
priority: normal
severity: normal
status: open
title: Module logging has dangerous examples
type: security
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun  3 23:13:38 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 03 Jun 2010 21:13:38 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <1275599618.14.0.926604611145.issue8891@psf.upfronthosting.co.za>
Message-ID: <1275599618.14.0.926604611145.issue8891@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

I am troubleshooting local issue with distutils and UAC on Windows, and I need to compare resulting binary archives. Unfortunately files to bdist archives are added in random order and this complicates comparisons. This patch makes distutils archives more deterministic.

----------
assignee: tarek
components: Distutils
files: sort_files_in_zip.26.patch
keywords: patch
messages: 106983
nosy: tarek, techtonik
priority: normal
severity: normal
status: open
title: sort files before archiving for consistency
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file17538/sort_files_in_zip.26.patch

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

From report at bugs.python.org  Thu Jun  3 23:14:04 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 03 Jun 2010 21:14:04 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <1275599618.14.0.926604611145.issue8891@psf.upfronthosting.co.za>
Message-ID: <1275599644.87.0.360127067043.issue8891@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


Added file: http://bugs.python.org/file17539/sort_files_in_zip.27.patch

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

From report at bugs.python.org  Thu Jun  3 23:32:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 21:32:19 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <1275599618.14.0.926604611145.issue8891@psf.upfronthosting.co.za>
Message-ID: <1275600739.97.0.0663771271963.issue8891@psf.upfronthosting.co.za>


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

This would be a new feature, so it can?t go into 2.6 unless I?m mistaken. It may even not go into 2.7.

Your renaming of z to zip does not add much value and shadows a builtin; I advise against doing that.

----------
nosy: +merwok
versions: +Python 3.2 -Python 2.6

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

From report at bugs.python.org  Thu Jun  3 23:36:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 21:36:22 +0000
Subject: [issue8890] Module logging has dangerous examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275600982.49.0.783731612309.issue8890@psf.upfronthosting.co.za>


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

Would you be kind enough to provide a doc patch that would advertise using the tempfile module?

----------
assignee:  -> docs at python
components: +Documentation -None
nosy: +docs at python, merwok
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Jun  3 23:40:29 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 03 Jun 2010 21:40:29 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <1275600739.97.0.0663771271963.issue8891@psf.upfronthosting.co.za>
Message-ID: <AANLkTimiptMpj6GwUmeoYNAOve2sdbnYltbhrobWmjjA@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Fri, Jun 4, 2010 at 12:32 AM, ?ric Araujo <report at bugs.python.org> wrote:
>
> This would be a new feature, so it can?t go into 2.6 unless I?m mistaken. It may even not go into 2.7.

It is not a feature, but a bugfix for wrong order of files in archive.
That means that on different filesystems you will get different
archives. I doubt that having files in random order is a feature.

> Your renaming of z to zip does not add much value and shadows a builtin; I advise against doing that.

I've just copy-pasted the same block from Python 2.7, so the bug with
shadowing is already there.

----------

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

From report at bugs.python.org  Thu Jun  3 23:51:01 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 03 Jun 2010 21:51:01 +0000
Subject: [issue8890] Module logging has dangerous examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275601861.59.0.287825433162.issue8890@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

import logging
- LOG_FILENAME = '/tmp/logging_example.out'
+ LOG_FILENAME = 'example.log'
  logging.basicConfig(filename=LOG_FILENAME,level=logging.DEBUG)
  logging.debug('This message should go to the log file')

----------
nosy: +techtonik

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

From report at bugs.python.org  Thu Jun  3 23:55:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 21:55:39 +0000
Subject: [issue8890] Module logging has dangerous examples
In-Reply-To: <1275601861.59.0.287825433162.issue8890@psf.upfronthosting.co.za>
Message-ID: <4C0824CE.9070903@netwok.org>


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

Nice, this example doesn?t require explaining tempfile and is shorter.
Add a notice before the code that you need to be in a directory with
write rights for this to work and I?m +1.

----------

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

From report at bugs.python.org  Fri Jun  4 00:05:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 22:05:53 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <1275599618.14.0.926604611145.issue8891@psf.upfronthosting.co.za>
Message-ID: <1275602753.15.0.321033668557.issue8891@psf.upfronthosting.co.za>


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

> It is not a feature, but a bugfix for wrong order of files in archive.

That?s debatable. If the docs did advertise ordering and if it?s not a regression from an older version, it?s a new feature. I?m not saying I don?t like it, just clarifying Python?s process.

> I've just copy-pasted the same block from Python 2.7, so the bug with
> shadowing is already there.

I see in the log that Tarek has done this to respect PEP 8, which advocates using meaningful names. Not a big deal here.

FTR, this function has been moved to shutil, still with the zip shadowing and without the sorting.

I?ll shut up now and let Tarek and the release manager judge whether this is a bugfix or a new feature :)

----------

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

From report at bugs.python.org  Fri Jun  4 00:11:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 22:11:01 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <1275599618.14.0.926604611145.issue8891@psf.upfronthosting.co.za>
Message-ID: <1275603061.19.0.376327576376.issue8891@psf.upfronthosting.co.za>


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

Sorry for writing when tired. Clearer first sentence: If it does not change the code to match the docs or to fix a regression from an older version, it?s a feature.

----------

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

From report at bugs.python.org  Fri Jun  4 00:20:51 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 03 Jun 2010 22:20:51 +0000
Subject: [issue8892] 2to3 fails with assertion failure on "from itertools
	import *"
In-Reply-To: <1275603651.87.0.583205697426.issue8892@psf.upfronthosting.co.za>
Message-ID: <1275603651.87.0.583205697426.issue8892@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

fix_itertools_imports.py fails on a "*" import

2to3 fails on this code:
   from itertools import *

with a traceback:
  File "/home/david/coding/python-svn/trunk-2to3-issues/Lib/lib2to3/tests/test_fixers.py", line 3680, in test_star
    self.warns_unchanged(s, "Cannot handle star imports")
  File "/home/david/coding/python-svn/trunk-2to3-issues/Lib/lib2to3/tests/test_fixers.py", line 49, in warns_unchanged
    self.warns(before, before, message, unchanged=True)
  File "/home/david/coding/python-svn/trunk-2to3-issues/Lib/lib2to3/tests/test_fixers.py", line 43, in warns
    tree = self._check(before, after)
  File "/home/david/coding/python-svn/trunk-2to3-issues/Lib/lib2to3/tests/test_fixers.py", line 32, in _check
    tree = self.refactor.refactor_string(before, self.filename)
  File "/home/david/coding/python-svn/trunk-2to3-issues/Lib/lib2to3/refactor.py", line 359, in refactor_string
    self.refactor_tree(tree, name)
  File "/home/david/coding/python-svn/trunk-2to3-issues/Lib/lib2to3/refactor.py", line 393, in refactor_tree
    self.traverse_by(self.post_order_heads, tree.post_order())
  File "/home/david/coding/python-svn/trunk-2to3-issues/Lib/lib2to3/refactor.py", line 417, in traverse_by
    new = fixer.transform(node, results)
  File "/home/david/coding/python-svn/trunk-2to3-issues/Lib/lib2to3/fixes/fix_itertools_imports.py", line 24, in transform
    assert child.type == syms.import_as_name
AssertionError

(seen when running 2to3 on python-lxml ; see problem in downstream tracker: https://bugzilla.redhat.com/show_bug.cgi?id=600036 )

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 106991
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: 2to3 fails with assertion failure on "from itertools import *"
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun  4 00:22:24 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 03 Jun 2010 22:22:24 +0000
Subject: [issue8892] 2to3 fails with assertion failure on "from itertools
	import *"
In-Reply-To: <1275603651.87.0.583205697426.issue8892@psf.upfronthosting.co.za>
Message-ID: <1275603744.9.0.568015098865.issue8892@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

I'm attaching a reproducer for the test suite (though not a fix)

----------
keywords: +patch
Added file: http://bugs.python.org/file17540/itertools_import_star_reproducer.patch

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

From report at bugs.python.org  Fri Jun  4 00:25:02 2010
From: report at bugs.python.org (Edward Pilatowicz)
Date: Thu, 03 Jun 2010 22:25:02 +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: <1275603902.54.0.546688610953.issue8882@psf.upfronthosting.co.za>


Edward Pilatowicz <edward.pilatowicz at oracle.com> added the comment:

so i wrote a simple test program that tells me the defined length of
sun_path and then uses bind() with increasingly long paths to determine
the actually supported length of sun_path.  here's what i've found:

Solaris:
    defined sun_path = 108
    max sun_path = 1024

FreeBSD 8.0:
    defined sun_path = 104
    max sun_path = 254

Fedora 11:
    defined sun_path = 108
    max sun_path = 108

i have requested access to an AIX system to check what length of
sun_path is defined and supported there.

while i could request that this value be changed in the OS, that would 
likely cause problems with pre-existing compiled code.  i'm guessing
that most OS vendors would not be eager to update this value, which is
probably why it's been the same small value for such a long time.

----------

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

From report at bugs.python.org  Fri Jun  4 00:35:38 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 03 Jun 2010 22:35:38 +0000
Subject: [issue8890] Module logging has dangerous examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275604538.96.0.0575340356178.issue8890@psf.upfronthosting.co.za>


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

Documenation fix checked into trunk (r81680).

----------
assignee: docs at python -> vinay.sajip
nosy: +vinay.sajip
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Jun  4 00:39:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 22:39:36 +0000
Subject: [issue8890] Module logging has dangerous examples
In-Reply-To: <1275604538.96.0.0575340356178.issue8890@psf.upfronthosting.co.za>
Message-ID: <4C082F23.1030001@netwok.org>


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

Thanks Vinay. You miss a closing paren in your commit.

----------

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

From report at bugs.python.org  Fri Jun  4 00:39:46 2010
From: report at bugs.python.org (Mark Nottingham)
Date: Thu, 03 Jun 2010 22:39:46 +0000
Subject: [issue8885] markerbase declaration errors aren't recoverable
In-Reply-To: <1275563651.6.0.351540013915.issue8885@psf.upfronthosting.co.za>
Message-ID: <1275604786.68.0.901872745929.issue8885@psf.upfronthosting.co.za>


Mark Nottingham <mnot at mnot.net> added the comment:

Just to be clear -- if error() returns, it will cause an infinite loop.

----------

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

From report at bugs.python.org  Fri Jun  4 00:58:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 03 Jun 2010 22:58:08 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275605888.22.0.454304516486.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am having second thoughts about dst indicator.  I wrote:
"""
2. Do we want to add a dst indicator and altname attributes? I would say: no. I would rather treat DST as a different fixed offset timezone.
"""

and Brett responded: 
"""
2. Keep the class dead-simple. The primary motivator is to support UTC, maybe the %z directive for strptime. Otherwise everything else should be left out of the stdlib and let third-parties manage it as they will be the ones that need to manage the bazillion timezone instances they need. We don't need to dictate an interface to them.
"""

Now note, that with fixed offset timezone class, it is possible to produce aware local times as follows:

from datetime import datetime, timezone, timedelta
import time
EPOCH = datetime(1970, 1, 1)
def localtime(utctime=None):
    if utctime is None:
        tm = time.localtime()
    else:
        seconds = (utctime - EPOCH).total_seconds()
        tm = time.localtime(seconds)

    tz = (timezone(timedelta(seconds=-time.altzone), time.tzname[1])
          if tm.tm_isdst else
          timezone(timedelta(seconds=-time.timezone), time.tzname[0]))
    return datetime(*tm[:6], tzinfo=tz)

(see also attached localtime.py)

The problem with the above implementation is that t.timetuple().tm_isdst will always be 0 if t is produced by localtime().

I don't think adding fixed dst offset is much of complication.  We already need to override the tzinfo.dst method and if we only allow timedeltas as offset and dst arguments to constructor, the constructor code will be extremely simple.

----------
Added file: http://bugs.python.org/file17541/localtime.py

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

From report at bugs.python.org  Fri Jun  4 01:37:31 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 03 Jun 2010 23:37:31 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275608251.45.0.0645550660867.issue5094@psf.upfronthosting.co.za>


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

So you want a third argument that lets you flag if the timezone is DST or not? I still don't think that will be necessary. If people want to add that they can very easily subclass the timezone class and add support for it. This class should be focused on providing a UTC instance and anything needed for a %z directive in strptime, nothing more. Anything fancier can be handled by libraries like pytz as they need it. Once again, keep the APi as simple as possible and add features as needed. I know how tempting it it is to design upfront, but just trust me, Alexander, we will all get burned for it later.

----------

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

From report at bugs.python.org  Fri Jun  4 01:50:44 2010
From: report at bugs.python.org (Christophe Kalt)
Date: Thu, 03 Jun 2010 23:50:44 +0000
Subject: [issue8893] file.{read,readlines} behaviour on Solaris
In-Reply-To: <1275609044.71.0.537925857344.issue8893@psf.upfronthosting.co.za>
Message-ID: <1275609044.71.0.537925857344.issue8893@psf.upfronthosting.co.za>


New submission from Christophe Kalt <python at ote.taranis.org>:

The following snippet of code is a concise way to exhibit the problem:

import os

wr = open('/tmp/test', 'w')
wr.write('oink\noink\n')
rd = open('/tmp/test', 'r')
rdlns = open('/tmp/test', 'r')
# first, read til EOF is reached (which is right away)
assert len(rd.read()) == 0
assert len(rdlns.readlines()) == 0
# add data to the file
wr.flush()
# try to read again
print 'read     : ', rd.read().split() # fails
print 'readlines: ', rdlns.readlines() # fails
print 'readline : ', rdlns.readline().strip() # succeeds
# cleanup
wr.close()
rd.close()
rdlns.close()
os.remove('/tmp/test')


On Linux, here is the output:
$ python2.6 src/readlines.py
read     :  ['oink', 'oink']
readlines:  ['oink\n', 'oink\n']
readline :  

On Solaris, here is the output:
$ python src/readlines.py
read     :  []
readlines:  []
readline :  oink

The problems comes from the fact that once EOF is reached, nothing more will be read from the file on subsequent reads, as noted in the manual page (http://docs.sun.com/app/docs/doc/816-5168/getchar-3c?a=view):

"If the stream is at end-of-file, the end-of-file indicator for the stream is set and these functions return EOF. For standard-conforming (see standards(5)) applications, if the end-of-file indicator for the stream is set, these functions return EOF whether or not the stream is at end-of-file."

The attached diff fixes the problem.

----------
assignee: theller
components: ctypes
files: fileobject.diff
keywords: patch
messages: 106999
nosy: kalt, theller
priority: normal
severity: normal
status: open
title: file.{read,readlines} behaviour on Solaris
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17542/fileobject.diff

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

From report at bugs.python.org  Fri Jun  4 03:01:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jun 2010 01:01:37 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1275613297.84.0.484885808985.issue7584@psf.upfronthosting.co.za>


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

I just took a look at RFC 3339, and I see what you mean, Anatoly, about the meaning of -00:00.  But reading further:

   "While the Internet does have a tradition of accepting reality when creating specifications, this should not be done at the expense of interoperability.  Since interpretation of an unqualified local time zone will fail in approximately 23/24 of the globe, the interoperability problems of unqualified local time are deemed unacceptable for the Internet."

It seems to me that we should not try to produce an RFC 3339 compliant date string from a naive datetime.  It will be practical to accept that restriction once issue 5094 is resolved.  Given this, I'd be OK with Z being the default.

----------
dependencies: +datetime lacks concrete tzinfo impl. for UTC

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

From report at bugs.python.org  Fri Jun  4 03:54:55 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Fri, 04 Jun 2010 01:54:55 +0000
Subject: [issue8810] TZ offset description is unclear in docs
In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>
Message-ID: <1275616495.58.0.114875625102.issue8810@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Committed to 2.7 in 81681 and 3.x in 81682.

----------
keywords: +needs review -patch
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed
type:  -> feature request

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

From report at bugs.python.org  Fri Jun  4 05:31:22 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 03:31:22 +0000
Subject: [issue8810] TZ offset description is unclear in docs
In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>
Message-ID: <1275622282.74.0.878800728613.issue8810@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> In this case, the docs.python.org link you point to seems
> to be correct, saying that it returns a timedelta.

This issue is specifically about ReST documentation, not the docstring. I explained in the opening comment that 'It is later explained that in fact "the value returned must be a timedelta object specifying a whole number of minutes", but many users won't read past the first sentence.'  Ironically, you not noticing that reaffirms my proposition that "many users won't read past the first sentence." :-)

Also, the documentation for tzinfo.dst is similarly unclear with ReST text slightly better than docstring.

Finally, please use rNNNNN form for revisions in commit comments.  These are converted to hyperlinks by the tracker.  For example, your commit comment would become:

  Committed to 2.7 in r81681 and 3.x in r81682.

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

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

From report at bugs.python.org  Fri Jun  4 05:31:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 03:31:45 +0000
Subject: [issue8810] TZ offset description is unclear in docs
In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>
Message-ID: <1275622305.62.0.023753540326.issue8810@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage: committed/rejected -> needs patch

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

From report at bugs.python.org  Fri Jun  4 05:32:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 03:32:15 +0000
Subject: [issue8810] TZ offset description is unclear in docs
In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>
Message-ID: <1275622335.05.0.716402670565.issue8810@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
resolution: accepted -> 

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

From report at bugs.python.org  Fri Jun  4 06:02:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 04:02:29 +0000
Subject: [issue8810] TZ offset description is unclear in docs
In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>
Message-ID: <1275624149.41.0.782796304632.issue8810@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Sean,

It looks like you committed your first patch rather than your second.  Is that what you intended?

Also in msg106734, you agree to change "West" to "west", but committed "West."  Note that "west" is correct.  In English, the West means the western part of the world while western direction is the west.

Pedantically, the UTC is not a location, so you cannot say "to the west of UTC".  Instead, you should say "to the west of the Greenwich Meridian."

Note how RFC 3339 defines the offset:

"""
   Numeric offsets are calculated as "local time minus UTC".  So the
   equivalent time in UTC can be determined by subtracting the offset
   from the local time.
"""

I think this is preferable because there are locations such as Spain to the west of Greenwich which use UTC+1.

----------

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

From report at bugs.python.org  Fri Jun  4 06:14:11 2010
From: report at bugs.python.org (Forest Bond)
Date: Fri, 04 Jun 2010 04:14:11 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1275624851.5.0.88380330636.issue3244@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

Hi,

I believe the attached implementation is reasonable.  I'm not sure if it should be called "email.mime.formdata", "rfc2388", etc.

I'd be happy to attach a proper patch with tests given some quick feedback.

Thanks,
Forest

----------
nosy: +forest_atq
Added file: http://bugs.python.org/file17543/rfc2388.py

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

From report at bugs.python.org  Fri Jun  4 06:18:06 2010
From: report at bugs.python.org (Forest Bond)
Date: Fri, 04 Jun 2010 04:18:06 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1275625086.58.0.765132892411.issue3244@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

Oh, hm, looks like I left a hard-coded name="files" in attach_file.  I'll fix that in the patch after I've received any other feedback.

----------

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

From report at bugs.python.org  Fri Jun  4 06:42:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 04:42:49 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275626569.74.0.459968436013.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> So you want a third argument that lets you flag if the timezone is DST or not?

The third argument is not a flag, it is a timedelta just like the offset.  I am attaching a python prototype for clarity. (See datetimeex.py.)

Conceptually, a 3-argument timezone is very simple: tzinfo defines three abstract methods: utcoffset(..), tzname(..), and dts(..).  The proposed concrete implementation lets allows the user to provide constant values to be returned from each of these methods.

----------
Added file: http://bugs.python.org/file17544/datetimeex.py

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

From report at bugs.python.org  Fri Jun  4 07:49:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 05:49:17 +0000
Subject: [issue8893] file.{read,readlines} behaviour on Solaris
In-Reply-To: <1275609044.71.0.537925857344.issue8893@psf.upfronthosting.co.za>
Message-ID: <1275630557.0.0.466163398097.issue8893@psf.upfronthosting.co.za>


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

Thanks for your report. This is not related to ctypes, adjusting component and nosy (per Misc/maintainers.rst); also adding keyword. Can you reproduce it with 3.1 and Subversion checkouts for trunk and py3k? Also, what?s the exact version of your OS?

----------
assignee: theller -> 
components: +IO -ctypes
keywords: +needs review
nosy: +benjamin.peterson, merwok, pitrou -theller

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

From report at bugs.python.org  Fri Jun  4 07:59:57 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Jun 2010 05:59:57 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275631197.4.0.125950401515.issue5094@psf.upfronthosting.co.za>


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

I'm still leary of supporting any form of DST. A proper DST implementation would need to have some conditional code to account for the datetime object passed into dst, and yet the version you have prototyped doesn't handle it. So a proper timezone supporting DST would still need to subclass any concrete class.

I still say keep it as simple as possible and let users subclass as needed to add DST support. Subclassing __init__ and dst() is not difficult if you want to add proper DST support, especially if dst() is set to return timdelta(0) and utcoffset() always returns CONSTANT + self.dst().

And just to mention it, the instance attributes you had in your example, Alexander, were not "private". For any final code, make sure you make them private else you are asking for trouble from people starting to rely on those attributes.

----------

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

From report at bugs.python.org  Fri Jun  4 09:10:28 2010
From: report at bugs.python.org (jurjen Bos)
Date: Fri, 04 Jun 2010 07:10:28 +0000
Subject: [issue8894] urllib2 authentication manager retries forever if
	password is wrong
In-Reply-To: <1275635428.44.0.0623896045557.issue8894@psf.upfronthosting.co.za>
Message-ID: <1275635428.44.0.0623896045557.issue8894@psf.upfronthosting.co.za>


New submission from jurjen Bos <j.bos-interpay at xs4all.nl>:

If you use an authentication manager from urllib2, it will submit user code and password if authentication fails.
However, if the password is wrong, the authentication manager will happily try again, again with the same password.
A simple way to circumvent this is attached: it modifies the password manager's behaviour to submit each password only once.
One problem I see is in cases where a program needs to log in multiple times in the same site: I propose an extra call to the password manager to reset the "visited" flag.

More details and sample code are in the file.

----------
components: Library (Lib)
files: circumvent.py
messages: 107009
nosy: Jurjen
priority: normal
severity: normal
status: open
title: urllib2 authentication manager retries forever if password is wrong
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17545/circumvent.py

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

From report at bugs.python.org  Fri Jun  4 09:19:55 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 04 Jun 2010 07:19:55 +0000
Subject: [issue8894] urllib2 authentication manager retries forever if
	password is wrong
In-Reply-To: <1275635428.44.0.0623896045557.issue8894@psf.upfronthosting.co.za>
Message-ID: <1275635995.95.0.151491129818.issue8894@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

There was a fix made in issue8797, which adopts a retry approach before failing for wrong password. This is present for Basic Auth and Digest Auth, so the problem wont be faced. Jurjen, do you have any comments before I mark this as Invalid. I see you have adopted a different approach for the patch, but the result would be same (no infinite retries)

----------
assignee:  -> orsenthil
nosy: +orsenthil

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

From report at bugs.python.org  Fri Jun  4 09:29:56 2010
From: report at bugs.python.org (jurjen Bos)
Date: Fri, 04 Jun 2010 07:29:56 +0000
Subject: [issue8894] urllib2 authentication manager retries forever if
	password is wrong
In-Reply-To: <1275635428.44.0.0623896045557.issue8894@psf.upfronthosting.co.za>
Message-ID: <1275636596.59.0.4066832074.issue8894@psf.upfronthosting.co.za>


jurjen Bos <j.bos-interpay at xs4all.nl> added the comment:

Yep you're right. In that thread they are talking about the exact same problem as I was having. Obviously, I didn't find that one when I was looking for the problem in the database before I posted this.
I do have my doubts about the 5 retries they propose though, I am not sure that the web site I use will not block the account if someone does 5 attempts.
- Jurjen

----------

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

From report at bugs.python.org  Fri Jun  4 09:33:44 2010
From: report at bugs.python.org (Henri Salo)
Date: Fri, 04 Jun 2010 07:33:44 +0000
Subject: [issue8890] Module logging has dangerous examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275636824.25.0.706057119852.issue8890@psf.upfronthosting.co.za>


Henri Salo <henri at nerv.fi> added the comment:

Please note that there is other similar examples as well. Even on the same page.

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

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

From report at bugs.python.org  Fri Jun  4 09:36:50 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 04 Jun 2010 07:36:50 +0000
Subject: [issue8894] urllib2 authentication manager retries forever if
	password is wrong
In-Reply-To: <1275636596.59.0.4066832074.issue8894@psf.upfronthosting.co.za>
Message-ID: <20100604073642.GB12378@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Okay, so there is another negative vote 5 retries in the basic auth.
But yeah, this bug can be marked duplicate.

----------

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

From report at bugs.python.org  Fri Jun  4 09:38:19 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 04 Jun 2010 07:38:19 +0000
Subject: [issue8894] urllib2 authentication manager retries forever if
	password is wrong
In-Reply-To: <1275635428.44.0.0623896045557.issue8894@psf.upfronthosting.co.za>
Message-ID: <1275637099.36.0.78490702481.issue8894@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Duplicate of issue8797

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

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

From report at bugs.python.org  Fri Jun  4 09:50:24 2010
From: report at bugs.python.org (jurjen Bos)
Date: Fri, 04 Jun 2010 07:50:24 +0000
Subject: [issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum
	recursion depth exceeded in cmp
In-Reply-To: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za>
Message-ID: <1275637824.46.0.963980054874.issue8797@psf.upfronthosting.co.za>


jurjen Bos <j.bos-interpay at xs4all.nl> added the comment:

I would like to point out that this is not going to work if someone visits more than 5 sites with the same authentication manager. This would have to be documentated, at least.
We could fix this by putting the retry counter in the HTTPPasswordMgr; it is not hard to put in an extra field in the password database with the retry counter. See also my remarks in issue8894

----------
nosy: +Jurjen

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

From report at bugs.python.org  Fri Jun  4 10:04:33 2010
From: report at bugs.python.org (Henri Salo)
Date: Fri, 04 Jun 2010 08:04:33 +0000
Subject: [issue8890] Module logging has dangerous examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275638673.08.0.351919550327.issue8890@psf.upfronthosting.co.za>


Henri Salo <henri at nerv.fi> added the comment:

We should review all of these:

install/index.rst:   python setup.py build --build-base=/tmp/pybuild/foo-1.0
install/index.rst:   python setup.py install --install-base=/tmp
install/index.rst:would install pure modules to :file:`{/tmp/python/lib}` in the first case, and
install/index.rst:to :file:`{/tmp/lib}` in the second case.  (For the second case, you probably
install/index.rst:want to supply an installation base of :file:`/tmp/python`.)
library/pipes.rst:   >>> f=t.open('/tmp/1', 'w')
library/pipes.rst:   >>> open('/tmp/1').read()
library/mailcap.rst:   >>> mailcap.findmatch(d, 'video/mpeg', filename='/tmp/tmp1223')
library/mailcap.rst:   ('xmpeg /tmp/tmp1223', {'view': 'xmpeg %s'})
library/logging.rst:   LOG_FILENAME = '/tmp/logging_rotatingfile_example.out'
library/logging.rst:   /tmp/logging_rotatingfile_example.out
library/logging.rst:   /tmp/logging_rotatingfile_example.out.1
library/logging.rst:   /tmp/logging_rotatingfile_example.out.2
library/logging.rst:   /tmp/logging_rotatingfile_example.out.3
library/logging.rst:   /tmp/logging_rotatingfile_example.out.4
library/logging.rst:   /tmp/logging_rotatingfile_example.out.5
library/logging.rst:The most current file is always :file:`/tmp/logging_rotatingfile_example.out`,
library/logging.rst:                       filename='/tmp/myapp.log',
library/logging.rst:which results in output (written to ``/tmp/myapp.log``) which should look
library/atexit.rst:       _count = int(open("/tmp/counter").read())
library/atexit.rst:       open("/tmp/counter", "w").write("%d" % _count)
library/imghdr.rst:   >>> imghdr.what('/tmp/bass.gif')
library/tempfile.rst:         '/var/folders/5q/5qTPn6xq2RaWqk+1Ytw3-U+++TI/-Tmp-/tmpG7V1Y0'
library/tempfile.rst:      * On all other platforms, the directories :file:`/tmp`, :file:`/var/tmp`, and
library/tempfile.rst:        :file:`/usr/tmp`, in that order.
library/posixfile.rst:   file = posixfile.open('/tmp/test', 'w')
library/cgi.rst:   cgitb.enable(display=0, logdir="/tmp")
library/optparse.rst:   prog -v --report /tmp/report.txt foo bar
library/optparse.rst:takes one argument, ``"/tmp/report.txt"`` is an option argument.  ``"foo"`` and
library/rexec.rst:   :file:`/tmp` or uploading it to the :file:`/incoming` directory of your public
library/rexec.rst::file:`/tmp` to be written, we can subclass the :class:`RExec` class::
library/rexec.rst:               # check filename : must begin with /tmp/
library/rexec.rst:               if file[:5]!='/tmp/':
library/rexec.rst:                   raise IOError("can't write outside /tmp")
library/rexec.rst:called :file:`/tmp/foo/../bar`.  To fix this, the :meth:`r_open` method would
library/rexec.rst:have to simplify the filename to :file:`/tmp/bar`, which would require splitting
library/compiler.rst::file:`/tmp/doublelib.py`.  ::
library/compiler.rst:   >>> mod = compiler.parseFile("/tmp/doublelib.py")
library/zipimport.rst:subdirectory.  For example, the path :file:`/tmp/example.zip/lib/` would only
library/zipimport.rst:   $ unzip -l /tmp/example.zip
library/zipimport.rst:   Archive:  /tmp/example.zip
library/zipimport.rst:   >>> sys.path.insert(0, '/tmp/example.zip')  # Add .zip file to front of path
library/zipimport.rst:   '/tmp/example.zip/jwzthreading.py'
library/trace.rst:   # make a report, placing output in /tmp
library/trace.rst:   r.write_results(show_missing=True, coverdir="/tmp")
library/nntplib.rst:   >>> f = open('/tmp/article')
library/bsddb.rst:   >>> db = bsddb.btopen('/tmp/spam.db', 'c')
library/sqlite3.rst::file:`/tmp/example` file::
library/sqlite3.rst:   conn = sqlite3.connect('/tmp/example')
tutorial/inputoutput.rst:   >>> f = open('/tmp/workfile', 'w')
tutorial/inputoutput.rst:   <open file '/tmp/workfile', mode 'w' at 80a0960>
tutorial/inputoutput.rst:   >>> f = open('/tmp/workfile', 'r+')
tutorial/inputoutput.rst:    >>> with open('/tmp/workfile', 'r') as f:
whatsnew/2.3.rst:   amk at nyman:~/src/python$ unzip -l /tmp/example.zip
whatsnew/2.3.rst:   Archive:  /tmp/example.zip
whatsnew/2.3.rst:   >>> sys.path.insert(0, '/tmp/example.zip')  # Add .zip file to front of path
whatsnew/2.3.rst:   '/tmp/example.zip/jwzthreading.py'
whatsnew/2.3.rst:subdirectory; for example, the path :file:`/tmp/example.zip/lib/` would only
whatsnew/2.3.rst:     >>> os.stat("/tmp").st_mtime
whatsnew/2.3.rst:     >>> os.stat("/tmp").st_mtime
whatsnew/2.0.rst:   output = UTF8_streamwriter( open( '/tmp/output', 'wb') )
whatsnew/2.0.rst:   input = UTF8_streamreader( open( '/tmp/output', 'rb') )
whatsnew/2.6.rst:      shutil.copytree('Doc/library', '/tmp/library',
whatsnew/2.6.rst:    # to the /tmp directory.
whatsnew/2.6.rst:    z.extract('Python/sysmodule.c', '/tmp')
whatsnew/2.6.rst:    plistlib.writePlist(data_struct, '/tmp/customizations.plist')
whatsnew/2.6.rst:    new_struct = plistlib.readPlist('/tmp/customizations.plist')
whatsnew/2.7.rst:    -> ./python.exe argparse-example.py -v -o /tmp/output -C 4 file1 file2
whatsnew/2.7.rst:    {'output': '/tmp/output',
whatsnew/2.4.rst:   sts = subprocess.call(['dpkg', '-i', '/tmp/new-package.deb'])
whatsnew/2.4.rst:   sts = subprocess.call('dpkg -i /tmp/new-package.deb', shell=True)
whatsnew/2.5.rst:     dest = mailbox.mbox('/tmp/mbox')
whatsnew/2.5.rst::file:`/tmp/example` file::
whatsnew/2.5.rst:   conn = sqlite3.connect('/tmp/example')

I can't change the status of resolution.

----------

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

From report at bugs.python.org  Fri Jun  4 11:05:58 2010
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Fri, 04 Jun 2010 09:05:58 +0000
Subject: [issue8895] newline arg/attribute in the module io
In-Reply-To: <1275642358.27.0.48977523408.issue8895@psf.upfronthosting.co.za>
Message-ID: <1275642358.27.0.48977523408.issue8895@psf.upfronthosting.co.za>


New submission from Jean-Michel Fauth <wxjmfauth at gmail.com>:

I was confused about the newline argument/attribute
in the misc. classes of the io module until I realize
there is a spelling issue between the docs and the
real implementation. (Py 2.6.5, Py2.7b2). Py 3.x not
tested.

>>> sys.version
2.7b2 (r27b2:81019, May  9 2010, 11:33:14) [MSC v.1500 32 bit (Intel)]
>>> sio = io.StringIO(u'abc')
>>> sio.encoding, type(sio.encoding)
(None, <type 'NoneType'>)
>>> sio.errors, type(sio.errors)
(None, <type 'NoneType'>)
>>> sio.newline, type(sio.newline)
Traceback (most recent call last):
  File "<psi last command>", line 1, in <module>
AttributeError: '_io.StringIO' object has no attribute 'newline'
>>> sio.newlines, type(sio.newlines)
(None, <type 'NoneType'>)
>>> 


>>> tio = io.TextIOWrapper(io.BytesIO())
>>> tio.buffer, type(tio.buffer)
(<_io.BytesIO object at 0x02E6E600>, <type '_io.BytesIO'>)
>>> tio.encoding, type(tio.encoding)
('cp1252', <type 'str'>)
>>> tio.errors, type(tio.errors)
('strict', <type 'str'>)
>>> tio.line_buffering, type(tio.line_buffering)
(False, <type 'bool'>)
>>> tio.newline, type(tio.newline)
Traceback (most recent call last):
  File "<psi last command>", line 1, in <module>
AttributeError: '_io.TextIOWrapper' object has no attribute 'newline'
>>> tio.newlines, type(tio.newlines)
(None, <type 'NoneType'>)

>>> sys.version
2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)]
>>> import io
>>> tio = io.TextIOWrapper(io.BytesIO())
>>> tio.encoding, type(tio.encoding)
('cp1252', <type 'str'>)
>>> tio.line_buffering, type(tio.line_buffering)
(False, <type 'bool'>)
>>> tio.errors, type(tio.errors)
(u'strict', <type 'unicode'>)
>>> tio.newline, type(tio.newline)
Traceback (most recent call last):
  File "<psi last command>", line 1, in <module>
AttributeError: 'TextIOWrapper' object has no attribute 'newline'
>>> tio.newlines, type(tio.newlines)
(None, <type 'NoneType'>)
>>> [e for e in dir(tio) if 'new' in e]
['__new__', 'newlines']
>>>

----------
components: IO
messages: 107017
nosy: jmfauth
priority: normal
severity: normal
status: open
title: newline arg/attribute in the module io
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun  4 11:14:53 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 04 Jun 2010 09:14:53 +0000
Subject: [issue4487] Add utf8 alias for email charsets
In-Reply-To: <1275582683.23.0.384513249134.issue4487@psf.upfronthosting.co.za>
Message-ID: <4C08C408.8090100@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

R. David Murray wrote:
> 
> R. David Murray <rdmurray at bitdance.com> added the comment:
> 
> For various reasons the email module has a table of character sets.  What might be most effective would be for the email module to look a character set name up in the codecs module and find out the cannonical name of the character set, and then look that up in its table (ie: remove the aliases table from email completely, and instead depend on codecs to resolve the cannonical name).  Unfortunately the codecs module does not recognize all of the aliases used by email, nor is there necessarily any guarantee that the two modules will agree on the proper cannonical name.

I think that the encodings package should be the only source of
valid aliases and encoding names - after all, you wouldn't be
able to process email content using names or aliases not
appearing in the encodings package tables.

If there are aliases missing, then we can add them there.

If the email packages needs different canonical names, it can apply
its own map on the canonical names returned by the encodings package.

----------
nosy: +lemburg

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

From report at bugs.python.org  Fri Jun  4 11:39:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Jun 2010 09:39:23 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1275644363.46.0.250797534151.issue3244@psf.upfronthosting.co.za>


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

You should write your patch against Python 3.x (py3k).

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

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

From report at bugs.python.org  Fri Jun  4 11:47:41 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 04 Jun 2010 09:47:41 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <1275603061.19.0.376327576376.issue8891@psf.upfronthosting.co.za>
Message-ID: <AANLkTikdcRQRRvleHuSAh2LxnLYcWTAaxi19qe-UylCA@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Fri, Jun 4, 2010 at 1:11 AM, ?ric Araujo <report at bugs.python.org> wrote:
>
> Sorry for writing when tired. Clearer first sentence: If it does not change the code to match the docs or to fix a regression from an older version, it?s a feature.

This is the biggest problem with rigidness Python process. In this
specific case the patch doesn't make Python any more unstable and
according to policy it won't be integrated into Python 2.7 unless
release manager chooses otherwise. But! release manager is
overwhelmed, so it is VERY unlikely that he will include this patch,
because it is a distraction, and there are always more important stuff
to judge. In addition RM can be incompetent in this particular part of
Python dist and just couldn't take the risk of making random
decisions.

To resolve this bottleneck and help release managers make decisions,
community members should be able to vote on patches. Then release
managers could be able to make releases that satisfy more Python
users. In addition the part of this decision for particular component
of Python dist could be delegated to component maintainers preserving
RM's right to veto any opinion.

----------

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

From report at bugs.python.org  Fri Jun  4 12:02:40 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 04 Jun 2010 10:02:40 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <1275599618.14.0.926604611145.issue8891@psf.upfronthosting.co.za>
Message-ID: <1275645760.12.0.591727857022.issue8891@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> community members should be able to vote on patches

*or* the core dev responsible for the development of the incriminated package, which is me for distutils. This is an improvement, not a feature, and this won't make it to 2.7.

While distutils is now frozen, I agree that we can add it in 3.2

----------
priority: normal -> low
versions:  -Python 2.7

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

From report at bugs.python.org  Fri Jun  4 12:12:53 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 04 Jun 2010 10:12:53 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <1275599618.14.0.926604611145.issue8891@psf.upfronthosting.co.za>
Message-ID: <1275646373.25.0.86225977141.issue8891@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

by the way, I am not sure what you call a binary sirting of zip files (since two equivalent zip files can have different metadata) but if you mean comparing a unzip -l output, you could use zipinfo instead, to sort the output.

Overall, you need to compare the size and CRC of each file. I don't know if zipinfo does this.

Maybe this could be a feature in the zipfile module in python. a same_archive() function.

----------

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

From report at bugs.python.org  Fri Jun  4 13:21:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 11:21:36 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <1275599618.14.0.926604611145.issue8891@psf.upfronthosting.co.za>
Message-ID: <1275650496.15.0.430046665271.issue8891@psf.upfronthosting.co.za>


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

?This is an improvement, not a feature?
I used the two terms with the same meaning :)

Do we add this to distutils in 3.2 and distutils2 too?

----------

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

From report at bugs.python.org  Fri Jun  4 13:23:21 2010
From: report at bugs.python.org (Forest Bond)
Date: Fri, 04 Jun 2010 11:23:21 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1275650601.64.0.850823585877.issue3244@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

I haven't yet touched Python 3.0, and may not have time to dig in at the moment.  It wouldn't be suitable to provide a patch against 2.7?

----------

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

From report at bugs.python.org  Fri Jun  4 13:26:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Jun 2010 11:26:38 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1275650601.64.0.850823585877.issue3244@psf.upfronthosting.co.za>
Message-ID: <1275650793.3140.0.camel@localhost.localdomain>


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

> I haven't yet touched Python 3.0, and may not have time to dig in at
> the moment.  It wouldn't be suitable to provide a patch against 2.7?

2.7 is almost in release candidate phase, which means it's much too late
for new features now.

----------

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

From report at bugs.python.org  Fri Jun  4 13:26:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 11:26:47 +0000
Subject: [issue8895] newline vs. newlines in io module
In-Reply-To: <1275642358.27.0.48977523408.issue8895@psf.upfronthosting.co.za>
Message-ID: <1275650807.34.0.596598824542.issue8895@psf.upfronthosting.co.za>


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

Thanks for the report. Could you check the docs for 3.1 and 3.x trunk (py3k) too?

----------
assignee:  -> docs at python
components: +Documentation -IO
nosy: +docs at python, merwok
stage:  -> needs patch
title: newline arg/attribute in the module io -> newline vs. newlines in io module

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

From report at bugs.python.org  Fri Jun  4 13:28:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Jun 2010 11:28:44 +0000
Subject: [issue8893] file.{read,readlines} behaviour on Solaris
In-Reply-To: <1275609044.71.0.537925857344.issue8893@psf.upfronthosting.co.za>
Message-ID: <1275650924.81.0.975185829434.issue8893@psf.upfronthosting.co.za>


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


----------
nosy: +tim_one
stage:  -> patch review
versions: +Python 2.7

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

From report at bugs.python.org  Fri Jun  4 13:33:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Jun 2010 11:33:34 +0000
Subject: [issue8893] file.{read,readlines} behaviour on Solaris
In-Reply-To: <1275609044.71.0.537925857344.issue8893@psf.upfronthosting.co.za>
Message-ID: <1275651214.38.0.622346704652.issue8893@psf.upfronthosting.co.za>


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

The patch looks harmless to me, although I'm not sure we're guaranteeing any of the behaviour you are expecting.
?ric, the buffering layer in 3.x is not libc-based, and therefore shouldn't exhibit this particular issue.

----------

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

From report at bugs.python.org  Fri Jun  4 13:49:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jun 2010 11:49:43 +0000
Subject: [issue8895] newline vs. newlines in io module
In-Reply-To: <1275642358.27.0.48977523408.issue8895@psf.upfronthosting.co.za>
Message-ID: <1275652183.03.0.628521298561.issue8895@psf.upfronthosting.co.za>


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

This is as documented:

   http://docs.python.org/dev/3.0/library/io.html#io.TextIOBase.newlines

The keyword argument is named 'newline', the attribute is named 'newlines'.  The attribute does not record what was passed to the newline argument, rather it records what newlines have been actually encountered.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage: needs patch -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Fri Jun  4 13:50:27 2010
From: report at bugs.python.org (Forest Bond)
Date: Fri, 04 Jun 2010 11:50:27 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1275652227.89.0.962310899762.issue3244@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

Okay, I'll submit against py3k.

----------

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

From report at bugs.python.org  Fri Jun  4 13:50:56 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 04 Jun 2010 11:50:56 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <1275645760.12.0.591727857022.issue8891@psf.upfronthosting.co.za>
Message-ID: <AANLkTilcpnvYvBP32MVDnF7TQNhQgUHOPEImHrquiuwS@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

> Tarek Ziad? <ziade.tarek at gmail.com> added the comment:
>
>> community members should be able to vote on patches
>
> *or* the core dev responsible for the development of the incriminated package, which is me for distutils.

This is said in the last part of the quoted msg107020:
"""In addition the part of this decision for particular component
of Python dist could be delegated to component maintainers preserving
RM's right to veto any opinion."""

> While distutils is now frozen, I agree that we can add it in 3.2

It would be nice if Python process could allow me to maintain my own
patched version of Python stdlibs so that I can use it instead of main
stdlib and quickly switch between them. It would be nice to be able to
share such patches and see in which versions (or forks) they were
integrated. I wonder if PSF license allows that?

> by the way, I am not sure what you call a binary sirting of zip files

I am not sure where did you see me mention that "binary sirting" too. =)

> (since two equivalent zip files can have different metadata) but if you mean comparing a unzip -l output, you could use zipinfo instead, to sort the output.

I use well-defined development toolchain for working with binary files
that can detect insignificant change in some kind of binary data like
timestamps in .zip archive, but comparing moving blocks is a disaster.
I need to analyze exact binary copies for troubleshooting issue8871
closely related to issue8870 to exclude any chance that binary .exe
generated by distutils on non-MS filesystem differs from the one
generated on MS FS. Even if it seems such a minor issue, believe me
that you do not want to meet any other minor issues when investigating
12 points checklist for some distutils bug that could be actually a
well-known MS problem, when the problem you need to solve is
misbehaving SCons installer that needs to install a couple of files in
somehow "seems to be protected" windows directories in Python
installation.

> Overall, you need to compare the size and CRC of each file. I don't know if zipinfo does this.
>
> Maybe this could be a feature in the zipfile module in python. a same_archive() function.

No. The archives should be generated consistently, but it is
impossible to create perfectly matching bdist_wininst archive anyway,
because timestamps will differ.

> FTR, this function has been moved to shutil, still with the zip shadowing and without the sorting.

Tarek, are you going to deal with shadowing?

----------

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

From report at bugs.python.org  Fri Jun  4 13:52:05 2010
From: report at bugs.python.org (Forest Bond)
Date: Fri, 04 Jun 2010 11:52:05 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1275652325.25.0.135011090944.issue3244@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

Should the module be called rfc2388 or should it go into email.mime as formdata?  It seems odd to put something HTML/HTTP related into email.mime, but maybe that would be fine.  In any case, httplib docs should probably point to this module with an example, right?

----------

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

From report at bugs.python.org  Fri Jun  4 13:53:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 11:53:40 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1275652420.82.0.879644590153.issue3243@psf.upfronthosting.co.za>


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


----------
nosy: +merwok

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

From report at bugs.python.org  Fri Jun  4 13:55:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 11:55:00 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1275652500.1.0.102569830428.issue3244@psf.upfronthosting.co.za>


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

I think it belongs in the http package.

----------
nosy: +merwok

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

From report at bugs.python.org  Fri Jun  4 13:55:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jun 2010 11:55:14 +0000
Subject: [issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum
	recursion depth exceeded in cmp
In-Reply-To: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za>
Message-ID: <1275652514.5.0.141076936244.issue8797@psf.upfronthosting.co.za>


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

+1 for putting retry control on the password manager.  Probably the default should be set to 1.  If I understand correctly, it is the password manager that would be prompting the user for a new password, if someone chose to implement such a password manager.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Fri Jun  4 13:56:35 2010
From: report at bugs.python.org (Forest Bond)
Date: Fri, 04 Jun 2010 11:56:35 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1275652595.83.0.0132810159139.issue3244@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

As http.formdata?

----------

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

From report at bugs.python.org  Fri Jun  4 13:59:39 2010
From: report at bugs.python.org (Christophe Kalt)
Date: Fri, 04 Jun 2010 11:59:39 +0000
Subject: [issue8893] file.{read,readlines} behaviour on Solaris
In-Reply-To: <1275609044.71.0.537925857344.issue8893@psf.upfronthosting.co.za>
Message-ID: <1275652779.33.0.0817627604427.issue8893@psf.upfronthosting.co.za>


Christophe Kalt <python at ote.taranis.org> added the comment:

This is on Solaris 10, but I also see it on Solaris 8 w/ Python 2.4.
Just tried Python 3.6.1, and it doesn't seem to have that problem.
Python 2.7b2 has the problem.

----------

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

From report at bugs.python.org  Fri Jun  4 14:03:47 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 04 Jun 2010 12:03:47 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <1275599618.14.0.926604611145.issue8891@psf.upfronthosting.co.za>
Message-ID: <1275653027.67.0.572038296072.issue8891@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

"""
I use well-defined development toolchain for working with binary files
that can detect insignificant change in some kind of binary data like
timestamps in .zip archive, but comparing moving blocks is a disaster.
"""

Please explain us how you compare the content of two zip archives.

----------

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

From report at bugs.python.org  Fri Jun  4 14:06:08 2010
From: report at bugs.python.org (Christophe Kalt)
Date: Fri, 04 Jun 2010 12:06:08 +0000
Subject: [issue8893] file.{read,readlines} behaviour on Solaris
In-Reply-To: <1275609044.71.0.537925857344.issue8893@psf.upfronthosting.co.za>
Message-ID: <1275653168.58.0.268502499911.issue8893@psf.upfronthosting.co.za>


Christophe Kalt <python at ote.taranis.org> added the comment:

Antoine:

I'm not sure what the expected behaviour should be either, this is certainly for others more familiar with Python than I to decide.  Although I am certainly annoyed that the current behaviour differs between Solaris and Linux.  Haven't had time to check other platforms to see how things should be.

Also, the behaviour seems inconsistent between the various file methods on Solaris which seems wrong.  Finally, from looking into fileobject.c, clearerr() is used in most places and the omissions (corrected by my patch) do seem unintentional to me, e.g. bugs.

Hope this helps.

----------

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

From report at bugs.python.org  Fri Jun  4 14:07:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 12:07:04 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1275653224.5.0.164080652653.issue3244@psf.upfronthosting.co.za>


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

Seems good to me, as long as the module docstring clearly stats whether it?s useful for the client side, the server side or both.

BTW, isn?t there overlap with cgi.FieldStorage?

----------

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

From report at bugs.python.org  Fri Jun  4 14:10:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 12:10:08 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <1275599618.14.0.926604611145.issue8891@psf.upfronthosting.co.za>
Message-ID: <1275653408.71.0.0616315418507.issue8891@psf.upfronthosting.co.za>


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

> It would be nice if Python process could allow me to maintain my own
> patched version of Python stdlibs so that I can use it instead of main
> stdlib and quickly switch between them.
It?s free software, you have the right to copy, edit and release it.
As for the technical aspect of easy switching, editing sys.path seems the way to go, or use PYTHONPATH to give your custom stdlib modules to have precedence over the real stdlib. I?ll stop being off-topic now. :)

Tarek, seen my question about distutils2?

----------

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

From report at bugs.python.org  Fri Jun  4 14:10:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 12:10:11 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <1275599618.14.0.926604611145.issue8891@psf.upfronthosting.co.za>
Message-ID: <1275653411.81.0.91892850191.issue8891@psf.upfronthosting.co.za>


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

> It would be nice if Python process could allow me to maintain my own
> patched version of Python stdlibs so that I can use it instead of main
> stdlib and quickly switch between them.
It?s free software, you have the right to copy, edit and release it.
As for the technical aspect of easy switching, editing sys.path seems the way to go, or use PYTHONPATH to give your custom stdlib modules to have precedence over the real stdlib. I?ll stop being off-topic now. :)

Tarek, seen my question about distutils2?

----------

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

From report at bugs.python.org  Fri Jun  4 14:11:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 12:11:03 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <1275599618.14.0.926604611145.issue8891@psf.upfronthosting.co.za>
Message-ID: <1275653463.65.0.164705937946.issue8891@psf.upfronthosting.co.za>


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


----------

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

From report at bugs.python.org  Fri Jun  4 14:40:49 2010
From: report at bugs.python.org (Forest Bond)
Date: Fri, 04 Jun 2010 12:40:49 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1275655249.22.0.560240745058.issue3244@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

Hi,

Patch attached.  Let me know what needs fixing.

I had to fix a bug in email.encoders for my tests to pass.  I have not run the full test suite at this point (need to build py3k to do that, maybe I'll have time later today, but if someone else has time, feel free).

Thanks,
Forest

----------
keywords: +patch
Added file: http://bugs.python.org/file17546/http_formdata.patch

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

From report at bugs.python.org  Fri Jun  4 14:48:50 2010
From: report at bugs.python.org (Forest Bond)
Date: Fri, 04 Jun 2010 12:48:50 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1275655730.31.0.140285032202.issue3244@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

?ric,

Sorry, I just read your message.

I'll post a new patch with a module docstring.

I believe cgi.FieldStorage is only useful for parsing (i.e. on the server side).  MIMEMultipartFormData is for generating multipart/form-data messages (i.e. on the client side).

Thanks,
Forest

----------

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

From report at bugs.python.org  Fri Jun  4 14:51:09 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 04 Jun 2010 12:51:09 +0000
Subject: [issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum
	recursion depth exceeded in cmp
In-Reply-To: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za>
Message-ID: <1275655869.6.0.611272326425.issue8797@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Agree to single retry for Basic Auth. We are just dealing with BasicAuthentication here, so that's why we did not have in the HTTPPasswdManager. But, let me consider that viewpoint too.

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

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

From report at bugs.python.org  Fri Jun  4 14:53:52 2010
From: report at bugs.python.org (Forest Bond)
Date: Fri, 04 Jun 2010 12:53:52 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1275656032.53.0.903448547928.issue3244@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

Here's a new patch.

----------
Added file: http://bugs.python.org/file17547/http_formdata.patch

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

From report at bugs.python.org  Fri Jun  4 14:56:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 12:56:08 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1275656168.81.0.931264566128.issue3244@psf.upfronthosting.co.za>


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

Would you please open another issue for the email fix? Bonus points if you test it on trunk too, since release candidate happens in some days :)

Do you people think we could unify client and server-side code in the new module (with an alias from cgi for b/w compat), to prevent endless questions?

Minor remark: I think we don?t have to follow the email naming scheme here. A simpler name like FormData could be just fine.

----------

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

From report at bugs.python.org  Fri Jun  4 15:11:06 2010
From: report at bugs.python.org (Forest Bond)
Date: Fri, 04 Jun 2010 13:11:06 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1275657066.99.0.435674758347.issue3244@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

Hm, there is one issue.  The example in the docstring wouldn't work.

You have to get the headers *after* the body, because the boundary isn't generated until the body has been.  So this would work:

  body = msg.get_body()
  headers = dict(msg)

But this won't:

  headers = dict(msg)
  body = msg.get_body()

I'm not sure what the best way to deal with this is.  Maybe instead of get_body we should have get_request_data which returns both headers and body.  That would provide simpler semantics.

Thoughts?

Thanks,
Forest

----------

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

From report at bugs.python.org  Fri Jun  4 15:23:51 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 04 Jun 2010 13:23:51 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <1275653027.67.0.572038296072.issue8891@psf.upfronthosting.co.za>
Message-ID: <AANLkTiknt-aKUjBb6Ml6VS9VqYkju0BOKujMQybUlqKc@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

> """
> I use well-defined development toolchain for working with binary files
> that can detect insignificant change in some kind of binary data like
> timestamps in .zip archive, but comparing moving blocks is a disaster.
> """
>
> Please explain us how you compare the content of two zip archives.

Here is the open source approach. I use soviet "swiss army knife" Far
Manager tool from http://www.farmanager.com/ that some years ago
became open sourced under revised BSD license. It can not compare
files itself, but allows you to switch forth and back between two
dumps of files in hex view with Ctrl-Tab / Ctrl-Shift-Tab shortcuts.
The comparison is done with standard windows command line tool "fc".
It is better to explain by example - I will list the key you need to
type and explanation below - keyboard shortcuts are in square
barckets. Right panel is C:\Downloads\python-wget\dist, left panel is
M:\, the cursor is placed on file wget-0.6.win32.force.exe that is
present in left and right panels and is the subject for comparison

1. fc /b [Ctrl-Enter] [Ctrl-]][Ctrl-Enter]
  this will give you the command line `fc /b wget-0.6.win32.force.exe
M:\wget-0.6.win32.force.exe`

2. [Ctrl-Home]edit:<
  this will give you the command line `edit:<fc /b
wget-0.6.win32.force.exe M:\wget-0.6.win32.force.exe`

3. [Enter]
  this will execute the output and open embedded editor with the
results. You will see hex offsets of differences

4. [Ctrl-Tab]
  your are back to file panels, but editor stays in a background -
notice the [0+1] marker in top left corner - it says that 0 viewers
and 1editor window are available.

5. F3
  you've opened current wget-0.6.win32.force.exe in embedded viewer

6. F4
  you've opened hex view for this file

7. [Ctrl-Shift-Tab]
  you're back at the fc output, copy the hex offset into clipboard
with [Ctrl-Ins]

8. [Ctrl-Tab]
  you're again at the hex view of the subject file

9. [Alt-F8][Shift-Ins][Enter]
  you're at the offset where difference start

10. [Ctrl-Tab]
  you're back at file panels

11. [Tab]
  switch to passive panel, repeat 5,6 and 9 for file from passive panel

12.
  now you can switch back and forth between differences in files with
[Ctrl-Tab]/[Ctrl-Shift-Tab]. You may want to switch to text view with
F4 for convenience.

I make all 12 steps in less than 20 seconds without using any plugins or macros.

----------

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

From report at bugs.python.org  Fri Jun  4 15:25:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 13:25:56 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <AANLkTiknt-aKUjBb6Ml6VS9VqYkju0BOKujMQybUlqKc@mail.gmail.com>
Message-ID: <4C08FEDE.4030702@netwok.org>


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

I think Takek asked more for a description of the diff algo (e.g.
?compare the CRC?, ?compare all files?, etc.), not the UI of one tool.

----------

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

From report at bugs.python.org  Fri Jun  4 15:28:09 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 04 Jun 2010 13:28:09 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <1275653408.71.0.0616315418507.issue8891@psf.upfronthosting.co.za>
Message-ID: <AANLkTim1Oba6kLpJdmpXGb03ZB8KAdG8d_V1WpFqRLHm@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Fri, Jun 4, 2010 at 3:10 PM, ?ric Araujo <report at bugs.python.org> wrote:
>
>> It would be nice if Python process could allow me to maintain my own
>> patched version of Python stdlibs so that I can use it instead of main
>> stdlib and quickly switch between them.
> It?s free software, you have the right to copy, edit and release it.

Sound good, but in reality I still have to get back the rest of the quote:
"""I wonder if PSF license allows that?"""

> As for the technical aspect of easy switching, editing sys.path seems the way to go, or use PYTHONPATH to give your custom stdlib modules to have precedence over the real stdlib.

Good starting point. The sync with stdlib and patch management is a
bigger issue though.

> I?ll stop being off-topic now. :)

Yep. In Google Wave we could split it earlier and clean up this one. =)

----------

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

From report at bugs.python.org  Fri Jun  4 15:40:00 2010
From: report at bugs.python.org (Forest Bond)
Date: Fri, 04 Jun 2010 13:40:00 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1275658800.61.0.550355693647.issue3244@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

New patch:

* Renames class to FormData.
* Replaces method get_body with get_request_data to simplify semantics.
* Drops changes to email.encoders.  I'll create a new ticket to deal with that bug.  Note that tests here fail without that fix.

----------
Added file: http://bugs.python.org/file17548/http_formdata.patch

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

From report at bugs.python.org  Fri Jun  4 15:44:44 2010
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Fri, 04 Jun 2010 13:44:44 +0000
Subject: [issue8895] newline vs. newlines in io module
In-Reply-To: <1275652183.03.0.628521298561.issue8895@psf.upfronthosting.co.za>
Message-ID: <AANLkTikEexfbK9Itb9sGWfm6cFG2nlckBrnf2EWAmibT@mail.gmail.com>


Jean-Michel Fauth <wxjmfauth at gmail.com> added the comment:

2010/6/4 R. David Murray <report at bugs.python.org>

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> This is as documented:
>
>   http://docs.python.org/dev/3.0/library/io.html#io.TextIOBase.newlines
>
> The keyword argument is named 'newline', the attribute is named 'newlines'.
>  The attribute does not record what was passed to the newline argument,
> rather it records what newlines have been actually encountered.
>

Ok, I see. I read, reread the doc prior posting, and, in my mind, it is not
obvious to understand this subtle difference from the doc.
Sorry for the noise.
Regards.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8895>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">2010/6/4 R. David Murray <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
R. David Murray &lt;<a href="mailto:rdmurray at bitdance.com">rdmurray at bitdance.com</a>&gt; added the comment:<br>
<br>
This is as documented:<br>
<br>
 ?? <a href="http://docs.python.org/dev/3.0/library/io.html#io.TextIOBase.newlines" target="_blank">http://docs.python.org/dev/3.0/library/io.html#io.TextIOBase.newlines</a><br>
<br>
The keyword argument is named &#39;newline&#39;, the attribute is named &#39;newlines&#39;. ??The attribute does not record what was passed to the newline argument, rather it records what newlines have been actually encountered.<br>
</blockquote></div><br>Ok, I see. I read, reread the doc prior posting, and, in my mind, it is not obvious to understand this subtle difference from the doc.<br>Sorry for the noise.<br>Regards.<br><br>

From report at bugs.python.org  Fri Jun  4 15:45:14 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 04 Jun 2010 13:45:14 +0000
Subject: [issue8890] Module logging has dangerous examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275659114.21.0.816534772477.issue8890@psf.upfronthosting.co.za>


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

Other logging cases contained /tmp/ has now been removed, the missing parenthesis added and the result checked in to trunk (r81684). 

I'll keep the issue open for the cases which remain in the other documentation. but remove myself from the assigned-to and change the resolution to "accepted".

----------
assignee: vinay.sajip -> 
resolution: fixed -> accepted

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

From report at bugs.python.org  Fri Jun  4 15:47:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 13:47:27 +0000
Subject: [issue8890] Module logging has dangerous examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275659247.19.0.912264654272.issue8890@psf.upfronthosting.co.za>


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

Thanks for the listing Henri. Not all of these examples have to be changed; I?ll review them in some days if you want.

----------

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

From report at bugs.python.org  Fri Jun  4 15:48:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 13:48:44 +0000
Subject: [issue8895] newline vs. newlines in io module
In-Reply-To: <1275642358.27.0.48977523408.issue8895@psf.upfronthosting.co.za>
Message-ID: <1275659324.62.0.0666245445913.issue8895@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file17549/unnamed

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

From report at bugs.python.org  Fri Jun  4 15:49:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 13:49:11 +0000
Subject: [issue8895] newline vs. newlines in io module
In-Reply-To: <1275642358.27.0.48977523408.issue8895@psf.upfronthosting.co.za>
Message-ID: <1275659351.45.0.959470544624.issue8895@psf.upfronthosting.co.za>


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

Could you think of a way to improve the docs on that point?

----------

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

From report at bugs.python.org  Fri Jun  4 16:07:18 2010
From: report at bugs.python.org (Forest Bond)
Date: Fri, 04 Jun 2010 14:07:18 +0000
Subject: [issue8896] email.encoders.encode_base64 sets payload to bytes,
	should set to str
In-Reply-To: <1275660438.53.0.968124979089.issue8896@psf.upfronthosting.co.za>
Message-ID: <1275660438.53.0.968124979089.issue8896@psf.upfronthosting.co.za>


New submission from Forest Bond <forest at alittletooquiet.net>:

Ran into this while tackling issue3244.  Encoded payload members should not be bytes.  In the case of base64, we should have an ascii string.

----------
components: Library (Lib)
files: python-email-encoders-base64-str.patch
keywords: patch
messages: 107055
nosy: forest_atq
priority: normal
severity: normal
status: open
title: email.encoders.encode_base64 sets payload to bytes, should set to str
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17550/python-email-encoders-base64-str.patch

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

From report at bugs.python.org  Fri Jun  4 16:08:01 2010
From: report at bugs.python.org (Forest Bond)
Date: Fri, 04 Jun 2010 14:08:01 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1275660481.26.0.235035120494.issue3244@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

See issue8896 for email.encoders fix.

----------

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

From report at bugs.python.org  Fri Jun  4 16:12:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 14:12:08 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1275660728.37.0.0325124709448.issue7475@psf.upfronthosting.co.za>


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

Related: bytes vs. str for base64 encoding in email, #8896

----------

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

From report at bugs.python.org  Fri Jun  4 16:13:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 14:13:24 +0000
Subject: [issue8896] email.encoders.encode_base64 sets payload to bytes,
	should set to str
In-Reply-To: <1275660438.53.0.968124979089.issue8896@psf.upfronthosting.co.za>
Message-ID: <1275660804.79.0.728335450236.issue8896@psf.upfronthosting.co.za>


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


----------
nosy: +l0nwlf, r.david.murray
versions:  -Python 3.3

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

From report at bugs.python.org  Fri Jun  4 16:15:23 2010
From: report at bugs.python.org (Forest Bond)
Date: Fri, 04 Jun 2010 14:15:23 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1275660923.5.0.192345277873.issue3244@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

I don't think Python trunk has the encoders issue, as that is related to the base64 moving to the bytes type.

----------

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

From report at bugs.python.org  Fri Jun  4 16:17:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 14:17:23 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1275592754.62.0.279269665035.issue5094@psf.upfronthosting.co.za>
Message-ID: <AANLkTilACf45HLrxSVIbZT8_vw65-awCwUXvyLYPW__x@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Jun 3, 2010 at 3:19 PM, Mark Dickinson <report at bugs.python.org> wrote:
..
> Aren't there valid timezones that are offset by more than 12 hours from UTC?

Indeed, Christmas Island uses UTC+14. (http://en.wikipedia.org/wiki/Kiritimati).

The most western timezone seems to be UTC-12 used on two uninhabited
islands. <http://en.wikipedia.org/wiki/Time_zone#Time_zone_as_offsets_from_UTC>

The tzinfo specification requires [-24, 24] hours range:

"""
.. the value returned must be a timedelta object specifying a whole
number of minutes in the range -1439 to 1439 inclusive (1440 = 24*60;
the magnitude of the offset must be less than one day).
""" -- http://docs.python.org/dev/py3k/library/datetime.html#datetime.tzinfo.utcoffset

I am torn between two options with a slight preference for the first:

1. Don't do any checking in the constructor and allow any timedelta
used as an offset.  This is the simplest to implement and most future
proof.  For example, it may be desirable to extend [-24, 24] to at
least [-99, 99] to allow round-tripping of compliant RFC 3339
timestamps.  (Note that I am not suggesting that real life more than a
day offsets are possible, but once a standard allows impossible
values, people tend to abuse them as special markers in their data.)

2. Require [-24, 24] hours range.  This is the letter of the current
tzinfo.utcoffset() definition.

Opinions?

What do you think

----------

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

From report at bugs.python.org  Fri Jun  4 16:20:01 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 14:20:01 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275661201.18.0.0240422662727.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Merging in issue7584 nosy list.

----------
nosy: +durban, l0nwlf, r.david.murray, techtonik

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

From report at bugs.python.org  Fri Jun  4 16:42:02 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 04 Jun 2010 14:42:02 +0000
Subject: [issue6312] httplib fails with HEAD requests to pages with
	"transfer-encoding: chunked"
In-Reply-To: <1245419610.47.0.800823464354.issue6312@psf.upfronthosting.co.za>
Message-ID: <1275662522.02.0.148268398098.issue6312@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


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

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

From report at bugs.python.org  Fri Jun  4 16:56:01 2010
From: report at bugs.python.org (Henri Salo)
Date: Fri, 04 Jun 2010 14:56:01 +0000
Subject: [issue8890] Module logging has dangerous examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275663361.68.0.865498164227.issue8890@psf.upfronthosting.co.za>


Henri Salo <henri at nerv.fi> added the comment:

Please review the changes for the quality of the documentation. There probably is still more places to change. References can be made to: <http://docs.python.org/library/tempfile.html#tempfile.mkstemp>

----------

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

From report at bugs.python.org  Fri Jun  4 16:56:21 2010
From: report at bugs.python.org (Henri Salo)
Date: Fri, 04 Jun 2010 14:56:21 +0000
Subject: [issue8890] Modules have dangerous examples in documentation
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275663381.49.0.526282961478.issue8890@psf.upfronthosting.co.za>


Changes by Henri Salo <henri at nerv.fi>:


----------
title: Module logging has dangerous examples -> Modules have dangerous examples in documentation

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

From report at bugs.python.org  Fri Jun  4 16:57:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jun 2010 14:57:41 +0000
Subject: [issue8896] email.encoders.encode_base64 sets payload to bytes,
	should set to str
In-Reply-To: <1275660438.53.0.968124979089.issue8896@psf.upfronthosting.co.za>
Message-ID: <1275663461.73.0.901365555241.issue8896@psf.upfronthosting.co.za>


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

This is a duplicate of issue 4768.  Could you attach your patch to that issue, please?

----------
assignee:  -> r.david.murray
superseder:  -> email.generator.Generator object bytes/str crash - b64encode() bug?

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

From report at bugs.python.org  Fri Jun  4 17:01:49 2010
From: report at bugs.python.org (Forest Bond)
Date: Fri, 04 Jun 2010 15:01:49 +0000
Subject: [issue4768] email.generator.Generator object bytes/str crash -
	b64encode() bug?
In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>
Message-ID: <1275663709.07.0.639307131108.issue4768@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

Attaching patch from reported duplicate issue8896.

----------
nosy: +forest_atq
Added file: http://bugs.python.org/file17551/python-email-encoders-base64-str.patch

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

From report at bugs.python.org  Fri Jun  4 17:02:19 2010
From: report at bugs.python.org (Forest Bond)
Date: Fri, 04 Jun 2010 15:02:19 +0000
Subject: [issue8896] email.encoders.encode_base64 sets payload to bytes,
	should set to str
In-Reply-To: <1275660438.53.0.968124979089.issue8896@psf.upfronthosting.co.za>
Message-ID: <1275663739.47.0.562076111723.issue8896@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

Duplicate.  See issue4768.

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

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

From report at bugs.python.org  Fri Jun  4 17:03:24 2010
From: report at bugs.python.org (Forest Bond)
Date: Fri, 04 Jun 2010 15:03:24 +0000
Subject: [issue4768] email.generator.Generator object bytes/str crash -
	b64encode() bug?
In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>
Message-ID: <1275663804.93.0.168745712639.issue4768@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

Note that my patch is roughly the same as the original posted by haypo.

----------

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

From report at bugs.python.org  Fri Jun  4 17:07:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 15:07:29 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1275664049.28.0.385189432088.issue7584@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> It seems to me that we should not try to produce an RFC 3339 compliant
> date string from a naive datetime.  It will be practical to accept
> that restriction once issue 5094 is resolved.

Does this mean that t.rfcformat() should fail if t is naive?

According to my reading of RFC 3339, it is not correct to produce 'Z' timestamps when local offset is not known.  My understanding is that compliant producers must either know their local timezone and specify correct offset in the suffix or produce UTC timestamps with '-00:00'.  Consumers receiving a '...Z' timestamp should be able to rely on that to conclude that the producer is in the UTC+0 timezone.  Raising an exception when local offset is not known is OK, but I think generating '-00:00' would be more useful.

Note that overall I am -1 on this proposal.  A naive application can probably get away with datetime.isoformat.  A strictly compliant RFC 3339 implementation is beyond the scope of datetime module and belongs to a separate module which should probably support parsing of RFC 3339 timestamps as well.

Rather than adding more xxxformat() methods, I would rather see datetime getting a custom __format__ that would be flexible enough to make writing standard formats easy.

----------

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

From report at bugs.python.org  Fri Jun  4 17:10:13 2010
From: report at bugs.python.org (Tal Einat)
Date: Fri, 04 Jun 2010 15:10:13 +0000
Subject: [issue4785] json.JSONDecoder() strict argument undocumented and
	potentially confusing
In-Reply-To: <1230658934.34.0.991784557371.issue4785@psf.upfronthosting.co.za>
Message-ID: <1275664213.31.0.634488336688.issue4785@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

This goes down into _json.scanstring. Looking at the C code for scanstring_unicode, the strict parameter allow control characters inside strings: "if strict is zero then literal control characters are allowed". From the code itself (current py3k head, r81032), it seems this means any character <= 0x1f. See scanstring_unicode in http://svn.python.org/view/python/branches/py3k/Modules/_json.c?revision=81032&view=markup for details.

Documentation should be updated accordingly.

----------
nosy: +taleinat

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

From report at bugs.python.org  Fri Jun  4 17:13:49 2010
From: report at bugs.python.org (Tal Einat)
Date: Fri, 04 Jun 2010 15:13:49 +0000
Subject: [issue4785] json.JSONDecoder() strict argument undocumented and
	potentially confusing
In-Reply-To: <1230658934.34.0.991784557371.issue4785@psf.upfronthosting.co.za>
Message-ID: <1275664429.0.0.0124071376188.issue4785@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

This goes down into _json.scanstring. Looking at the C code for scanstring_unicode, strict=False allows control characters inside strings: "if strict is zero then literal control characters are allowed". From the code itself (current py3k head, r81032), it seems this means any character <= 0x1f. See scanstring_unicode in http://svn.python.org/view/python/branches/py3k/Modules/_json.c?revision=81032&view=markup for details.

Documentation should be updated accordingly.

----------

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

From report at bugs.python.org  Fri Jun  4 17:38:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jun 2010 15:38:07 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1275665887.97.0.0511971540401.issue7584@psf.upfronthosting.co.za>


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

I see I didn't think it through far enough.

Given this, it seems that the Atom standard is saying, "if you don't know your actual UTC offset, you can't generate a valid ATOM timestamp".  Which sorta makes sense, though you'd think they'd want to accept a -00:00 timestamp since then at least you know when the article was generated/modified, even if you don't know the local time of the poster.  And maybe they do, since as someone pointed out -00:00 is a numeric offest...

I agree that generalizing the production of custom formats sounds like a better way forward long term.  I'm not clear on why you think RFC3339 deserves its own module.

----------

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

From report at bugs.python.org  Fri Jun  4 17:42:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jun 2010 15:42:10 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1275666130.25.0.951948314069.issue8828@psf.upfronthosting.co.za>


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

Victor: you could always name it best_effort_at_atomic_rename :)

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Fri Jun  4 17:45:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jun 2010 15:45:45 +0000
Subject: [issue4487] Add utf8 alias for email charsets
In-Reply-To: <1228223832.43.0.0399583143577.issue4487@psf.upfronthosting.co.za>
Message-ID: <1275666345.3.0.823749406924.issue4487@psf.upfronthosting.co.za>


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

Mark, any objection to my putting this patch in now, and then we'll fix the aliases implementation in 3.2?

----------
versions: +Python 3.1, Python 3.2 -Python 2.5

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

From report at bugs.python.org  Fri Jun  4 18:05:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 16:05:47 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275667547.33.0.874032866075.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> I'm still leary of supporting any form of DST. A proper DST
> implementation would need to have some conditional code to
> account for the datetime object passed into dst, and yet the
> version you have prototyped doesn't handle it.

No, any tzinfo implementation where utcoffset(dt) depends on dt is broken because once utcoffset starts to vary with time you can no longer determine a point in time from the local time alone. (In theory, a continuously increasing or decreasing in time utcoffset is an exception to this rule, but there is no practical use for those.)

This limitation is admitted in datetime.tzinfo documentation:

"""
Note that there are unavoidable subtleties twice per year in a tzinfo subclass accounting for both standard and daylight time, at the DST transition points. ... Applications that can?t bear such ambiguities should avoid using hybrid tzinfo subclasses; there are no ambiguities when using UTC, or any other fixed-offset tzinfo subclass (such as a class representing only EST (fixed offset -5 hours), or only EDT (fixed offset -4 hours)).
"""

(See three paragraphs above http://docs.python.org/dev/py3k/library/datetime.html#strftime-and-strptime-behavior)

In pytz, <http://pytz.sourceforge.net/#tzinfo-api>, tzinfo API is extended to add an is_dst flag to utcoffset(), tzname(), and dst() methods, but since datetime objects do not carry this flag, it is impossible for datetime module to pass this flag to timezone within datetime.datetime methods and datetime module does not know about this flag to begin with.

To add insult to injury, the extended API still does not solve all the problems: <http://pytz.sourceforge.net/#problems-with-localtime>.

> So a proper timezone supporting DST would still need to subclass
> any concrete class.

No, as I explained above, it is not possible to implement a "proper timezone."  I believe most of the frustration with the current tzinfo API stems from the fact that it is not implementable.   The correct interface to a timezone database should provide a mapping from (universal time, geographical location) to civil time there and then.  A common name for the timezone in use and information about DST being in effect is useful for interoperability but not strictly required.

This is what I implemented in my localtime() prototype in localtime.py (loosing DST information) and datetimeex.py (interoperable with POSIX timetupe based interfaces and pytz extended API).

Note that on systems supporting extended tm structure (with tm_zone and tm_gmtoff fields), it is possible to implement localtime() which will take advantage of the full historical timezone information available on the system.

----------

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

From report at bugs.python.org  Fri Jun  4 18:12:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 16:12:23 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275667943.99.0.767667793423.issue5094@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +tim_one

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

From report at bugs.python.org  Fri Jun  4 18:17:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jun 2010 16:17:21 +0000
Subject: [issue4768] email.generator.Generator object bytes/str crash -
	b64encode() bug?
In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>
Message-ID: <1275668241.5.0.859157725922.issue4768@psf.upfronthosting.co.za>


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

Yes, but yours was better formatted, so I used it :)  Thanks for the patch.  Applied in r81685 to py3k, and r81686.

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

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

From report at bugs.python.org  Fri Jun  4 18:22:50 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 04 Jun 2010 16:22:50 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za>
Message-ID: <1275668570.45.0.975004000598.issue8271@psf.upfronthosting.co.za>


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

I added a test for the 'ignore' error handler. I will commit the patch before the RC unless someone has something against it.

To summarize, the patch updates PyUnicode_DecodeUTF8 from RFC 2279 to RFC 3629, so:
1) Invalid sequences are now handled as described in http://www.unicode.org/versions/Unicode5.2.0/ch03.pdf (pages 94-95);
2) 5- and 6-bits-long sequences are now invalid (no changes in behavior, I just removed the "deafult:" of the switch/case and marked them with '0' in the first table);
3) According to RFC 3629, codepoints in the surrogate range (U+D800-U+DFFF) should be considered invalid, but this would not be backward compatible, so I added code and tests but left them commented away;
4) I changed the error message "unexpected code byte" to "invalid start byte" and "invalid data" to "invalid continuation byte";
5) I added an extensive set of tests in test_unicode;
6) I fixed test_codeccallbacks because it was failing after this change.

----------
Added file: http://bugs.python.org/file17552/issue8271v5.diff

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

From report at bugs.python.org  Fri Jun  4 18:45:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jun 2010 16:45:32 +0000
Subject: [issue4768] email.generator.Generator object bytes/str crash -
	b64encode() bug?
In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>
Message-ID: <1275669932.28.0.552062906393.issue4768@psf.upfronthosting.co.za>


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

@garazi111: if you have an example where quopri fails, please open a new issue for it.  I suspect you are right that there is a problem there.

----------

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

From report at bugs.python.org  Fri Jun  4 18:46:09 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 04 Jun 2010 16:46:09 +0000
Subject: [issue6312] httplib fails with HEAD requests to pages with
	"transfer-encoding: chunked"
In-Reply-To: <1245419610.47.0.800823464354.issue6312@psf.upfronthosting.co.za>
Message-ID: <1275669969.59.0.707161335121.issue6312@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r81687, r81688, r81689 and r81690.

Yes, I see that before the original change was made any chuncked encoding went through _read_chunked which close the resp before returning. So, here for HEAD, the resp is closed thus fixing the problem mentioned by djc.

----------
priority: release blocker -> 
resolution: accepted -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Jun  4 19:06:48 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 04 Jun 2010 17:06:48 +0000
Subject: [issue6312] httplib fails with HEAD requests to pages with
	"transfer-encoding: chunked"
In-Reply-To: <1245419610.47.0.800823464354.issue6312@psf.upfronthosting.co.za>
Message-ID: <1275671208.29.0.64656910285.issue6312@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Might be useful to have a test for this?

----------

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

From report at bugs.python.org  Fri Jun  4 19:23:11 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 04 Jun 2010 17:23:11 +0000
Subject: [issue8864] multiprocessing: undefined struct/union member:
	msg_control
In-Reply-To: <1275342146.08.0.266544809639.issue8864@psf.upfronthosting.co.za>
Message-ID: <1275672191.2.0.516211865605.issue8864@psf.upfronthosting.co.za>


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

Fixed in r81692, r81694.

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

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

From report at bugs.python.org  Fri Jun  4 19:26:29 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 04 Jun 2010 17:26:29 +0000
Subject: [issue5467] tools\msi\merge.py is sensitive to lack of config.py
In-Reply-To: <1236694315.39.0.154575641767.issue5467@psf.upfronthosting.co.za>
Message-ID: <1275672389.89.0.585504949901.issue5467@psf.upfronthosting.co.za>


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

The patch is now out of date; merge.py got merged into msi.py.

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

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

From report at bugs.python.org  Fri Jun  4 19:33:11 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 04 Jun 2010 17:33:11 +0000
Subject: [issue6312] httplib fails with HEAD requests to pages with
	"transfer-encoding: chunked"
In-Reply-To: <1245419610.47.0.800823464354.issue6312@psf.upfronthosting.co.za>
Message-ID: <1275672791.76.0.607239420648.issue6312@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I saw the earlier tests was closing it explicitly. Removed that and added a test which verifies the closed resp obj. Thanks.

----------

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

From report at bugs.python.org  Fri Jun  4 19:34:55 2010
From: report at bugs.python.org (Thomas Jollans)
Date: Fri, 04 Jun 2010 17:34:55 +0000
Subject: [issue8897] sunau bytes / str TypeError in Py3k
In-Reply-To: <1275672895.91.0.97400241219.issue8897@psf.upfronthosting.co.za>
Message-ID: <1275672895.91.0.97400241219.issue8897@psf.upfronthosting.co.za>


New submission from Thomas Jollans <thomas at jollans.com>:

The sunau module, essentially, "doesn't work". This looks like a problem with the bytes/unicode transition of "str" in Python 3.x vs Python 2:

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 sunau
>>> aufile = sunau.open('test.au', 'w')
>>> aufile.setsampwidth(2)
>>> aufile.setframerate(44100)
>>> aufile.setnchannels(1)
>>> aufile.writeframes(b'aabbccdd')
Exception wave.Error: Error('# channels not specified',) in <bound method Wave_write.__del__ of <wave.Wave_write object at 0x1fa8ed0>> ignored
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.1/sunau.py", line 393, in writeframes
    self.writeframesraw(data)
  File "/usr/lib/python3.1/sunau.py", line 383, in writeframesraw
    self._ensure_header_written()
  File "/usr/lib/python3.1/sunau.py", line 418, in _ensure_header_written
    self._write_header()
  File "/usr/lib/python3.1/sunau.py", line 452, in _write_header
    self._file.write(self._info)
TypeError: must be bytes or buffer, not str
>>> 

The wave and aifc modules work as expected when used like this, as does the above code in Python 2.6. Au_read.readframes correctly returns a bytes.

I haven't tested this on a development version of Python.

----------
components: Library (Lib)
messages: 107081
nosy: tjollans
priority: normal
severity: normal
status: open
title: sunau bytes / str TypeError in Py3k
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri Jun  4 19:36:47 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 04 Jun 2010 17:36:47 +0000
Subject: [issue4487] Add utf8 alias for email charsets
In-Reply-To: <1275666345.3.0.823749406924.issue4487@psf.upfronthosting.co.za>
Message-ID: <4C0939AC.7090206@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

R. David Murray wrote:
> 
> R. David Murray <rdmurray at bitdance.com> added the comment:
> 
> Mark, any objection to my putting this patch in now, and then we'll fix the aliases implementation in 3.2?

No. Please open a new issue targeting Python 3.2 for this.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________
2010-07-19: EuroPython 2010, Birmingham, UK                44 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------

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

From report at bugs.python.org  Fri Jun  4 19:45:54 2010
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Fri, 04 Jun 2010 17:45:54 +0000
Subject: [issue8895] newline vs. newlines in io module
In-Reply-To: <1275659351.45.0.959470544624.issue8895@psf.upfronthosting.co.za>
Message-ID: <AANLkTimsgmkbzdOEfpJ0DDDk_G8IKxYmLERZXDBZAf6V@mail.gmail.com>


Jean-Michel Fauth <wxjmfauth at gmail.com> added the comment:

2010/6/4 ??ric Araujo <report at bugs.python.org>

>
> ??ric Araujo <merwok at netwok.org> added the comment:
>
> Could you think of a way to improve the docs on that point?
>
> ----------
>
> Quick and dirty answer.

I have ~10 years experience with Python and it seems
to me the io module is technically excellent.

However, I have found it is not so obvious to
understand the usage of all these arguments,
errors, encoding, line_buffering, ... in the
class constructors and methods like io.open().

The doc describes what these arguments are,
their states, but not too much how to use
them.

As an exemple, I read some time ago on the c.l.p
mailing list, somebody complaining about the "encoding"
argument of the class TextIOWrapper. He defined an
"encoding='utf-8'" in the ctor and did not
understand why his "text" was not automagically
encoded. Answer: the encoding arg is only a kind
of information and does not do anything.

BTW, it was only when I read that post, I understand
a little bit more.

Regards.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8895>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">2010/6/4 ??ric Araujo <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
??ric Araujo &lt;<a href="mailto:merwok at netwok.org">merwok at netwok.org</a>&gt; added the comment:<br>
<br>
Could you think of a way to improve the docs on that point?<br>
<br>
----------<br>
<div><div></div><div class="h5"><br></div></div></blockquote></div>Quick and dirty answer.<br><br>I have ~10 years experience with Python and it seems<br>to me the io module is technically excellent.<br><br>However, I have found it is not so obvious to<br>
understand the usage of all these arguments,<br>errors, encoding, line_buffering, ... in the <br>class constructors and methods like io.open().<br><br>The doc describes what these arguments are,<br>their states, but not too much how to use<br>
them.<br><br>As an exemple, I read some time ago on the c.l.p<br>mailing list, somebody complaining about the &quot;encoding&quot;<br>argument of the class TextIOWrapper. He defined an <br>&quot;encoding=&#39;utf-8&#39;&quot; in the ctor and did not<br>
understand why his &quot;text&quot; was not automagically<br>encoded. Answer: the encoding arg is only a kind<br>of information and does not do anything.<br><br>BTW, it was only when I read that post, I understand<br>a little bit more.<br>
<br>Regards.<br><br>

From report at bugs.python.org  Fri Jun  4 20:15:22 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 04 Jun 2010 18:15:22 +0000
Subject: [issue5464] msgfmt.py does not work with plural form
In-Reply-To: <1236635230.35.0.0644981096799.issue5464@psf.upfronthosting.co.za>
Message-ID: <1275675322.35.0.955443852967.issue5464@psf.upfronthosting.co.za>


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

This is now fixed in r81697 and r81698.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.2 -Python 2.6

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

From report at bugs.python.org  Fri Jun  4 20:33:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jun 2010 18:33:37 +0000
Subject: [issue8895] newline vs. newlines in io module
In-Reply-To: <1275642358.27.0.48977523408.issue8895@psf.upfronthosting.co.za>
Message-ID: <1275676417.55.0.138666859023.issue8895@psf.upfronthosting.co.za>


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

This is off topic for this issue, but what you just reported makes no sense to me.  TextIOWrapper calls the encoder corresponding to the specified encoding in its write method.

That said, it is true that the IO docs are currently a class reference and not a user reference, and this should be fixed.  There may even already be an open issue for this.

----------

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

From report at bugs.python.org  Fri Jun  4 20:34:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 18:34:03 +0000
Subject: [issue1647654] No obvious and correct way to get the time zone offset
Message-ID: <1275676443.64.0.915516764949.issue1647654@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Issue #1667546 is more ambitious than this.  I propose a very simple patch which makes tm_zone and tm_gmtoff available on systems with HAVE_STRUCT_TM_TM_ZONE defined (Linux and BSD variants). The additional fields are only allowed as attributes so len(time.localtime()) is still the same.  This choice allows to get access to extra fields without breaking code that relies on the size of timetuple.

The patch needs documentation updates which I will add if the idea is well received.

----------
keywords: +patch
nosy: +mark.dickinson
stage:  -> patch review
versions: +Python 3.2 -Python 2.7, Python 3.1
Added file: http://bugs.python.org/file17554/issue1647654.diff

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

From report at bugs.python.org  Fri Jun  4 20:40:58 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 18:40:58 +0000
Subject: [issue1647654] No obvious and correct way to get the time zone offset
Message-ID: <1275676858.65.0.0831378563251.issue1647654@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17555/issue1647654a.diff

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

From report at bugs.python.org  Fri Jun  4 20:54:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jun 2010 18:54:18 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Currently the email module maintains a set of "charset" aliases that it maps to codec names before looking up the codec in the codecs module.  Ideally it should instead be able to just look up any 'charset' name, and if it is a valid alias for a codec, the codec module would return the codec with the canonical name.  It is possible (I haven't checked yet) that the email module needs a different canonical  'charset' name for certain codecs, but if so it can do that mapping after getting the canonical codec name from codecs.

To implement this we need to make two simple changes:

1) add any aliases the email module recognizes but the codecs module doesn't to the codecs module.

2) rewrite email.charset so that it does not have an ALIASES table (but may have a smaller 'canonical charset map' table instead).

----------
assignee: r.david.murray
components: Library (Lib)
keywords: easy
messages: 107087
nosy: l0nwlf, lemburg, r.david.murray
priority: normal
severity: normal
stage: unit test needed
status: open
title: The email package should defer to the codecs module for all aliases
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Fri Jun  4 21:26:43 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 04 Jun 2010 19:26:43 +0000
Subject: [issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4
In-Reply-To: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za>
Message-ID: <1275679603.53.0.80672089082.issue6926@psf.upfronthosting.co.za>


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

Following the python-dev consensus, I have now added a warning to the 2.7 installer that this will be the last release supporting Windows 2000.

I still think that we should not bump the SDK version above 500 for 2.7. Changing the SDK level does *not just* enable new API functions and constants, it may also change the layout of structures, causing applications to break on earlier systems (see the desaster with SystemParametersInfo, #1601). Bumping the version for 3.2 is fine.

----------
versions:  -Python 2.7

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

From report at bugs.python.org  Fri Jun  4 21:47:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 19:47:17 +0000
Subject: [issue8899] Add docstrings to time.struct_time
In-Reply-To: <1275680837.43.0.377357755743.issue8899@psf.upfronthosting.co.za>
Message-ID: <1275680837.43.0.377357755743.issue8899@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

The time.struct_time class is missing class and field docstrings: 

>>> time.struct_time.__doc__ is None
True
>>> time.struct_time.tm_year.__doc__ is None
True

This is significant because it is not obvious that field values are different from those of C language struct tm fields with the same names. (While module level docstring describes the timetuple, it does not list the names of the struct_time fields or mentions struct_time.)

With the attached patch,

>>> from time import *
>>> localtime()
time.struct_time(tm_year=2010, tm_mon=6, tm_mday=4, tm_hour=15, tm_min=27, tm_sec=15, tm_wday=4, tm_yday=155, tm_isdst=1)
>>> help(_)
Help on struct_time object:

time.struct_time = class struct_time(__builtin__.object)
 |  The time value as returned by gmtime(), localtime(), and strptime(), and accepted
 |  by asctime(), mktime() and strftime(), may be considered as a sequence of 9 integers.
 |  Note that several fields' values are not the same as those defined by the C language
 |  standard for struct tm.  For example, the value of tm_year is the actual year, not
 |  year - 1900.   See individual fields' descriptions for details.
...
 |  ----------------------------------------------------------------------
 |  Data descriptors defined here:
 |  
 |  tm_hour
 |      hours, range [0 - 23]
 |  
 |  tm_isdst
 |      1 if summer time is in effect, 0 if not, and -1 if cannot be determined
 |  
 |  tm_mday
 |      day of month, range [1 - 31]
 |  
 |  tm_min
 |      minutes, range [0 - 59]
 |  
 |  tm_mon
 |      month of year, range [1 - 12]
 |  
 |  tm_sec
 |      seconds, range [0 - 61])
 |  
 |  tm_wday
 |      day of week, range [0,6], Monday is 0
 |  
 |  tm_yday
 |      day of year, range [1,366]
 |  
 |  tm_year
 |      year, for example, 1993
 |  
 |  ----------------------------------------------------------------------

----------
assignee: belopolsky
components: Documentation
files: struct_time_doc.diff
keywords: easy, patch
messages: 107089
nosy: belopolsky, docs at python, mark.dickinson
priority: normal
severity: normal
stage: commit review
status: open
title: Add docstrings to time.struct_time
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17556/struct_time_doc.diff

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

From report at bugs.python.org  Fri Jun  4 21:53:51 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 04 Jun 2010 19:53:51 +0000
Subject: [issue6470] Tkinter import fails when running Python.exe from a
	network share
In-Reply-To: <1247430164.29.0.0724763544583.issue6470@psf.upfronthosting.co.za>
Message-ID: <1275681231.08.0.201106905139.issue6470@psf.upfronthosting.co.za>


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

Thanks for the patch. Committed as r81701, r81702, r81703 and r81704.

----------
resolution:  -> accepted
status: open -> closed

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

From report at bugs.python.org  Fri Jun  4 21:54:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jun 2010 19:54:32 +0000
Subject: [issue4487] Add utf8 alias for email charsets
In-Reply-To: <1228223832.43.0.0399583143577.issue4487@psf.upfronthosting.co.za>
Message-ID: <1275681272.84.0.981014537025.issue4487@psf.upfronthosting.co.za>


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

Patch committed to trunk in r81705.  Leaving issue open pending porting to the other branches, but I've also opened issue 8898 to further change things so that codecs becomes the sole authority for aliases in 3.2.

----------
resolution:  -> fixed
stage: patch review -> commit review

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

From report at bugs.python.org  Fri Jun  4 22:09:20 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Jun 2010 20:09:20 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275682160.9.0.0914585409976.issue5094@psf.upfronthosting.co.za>


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

For the allowable range, follow the datetime docs as someone might be relying on that specification already.

As for the ongoing DST debate, it seems we either need to say that since we cannot properly support all possible datetimes properly we should simply not even try, fixed offset or not, or we provide a class that gives the proper UTC offset, but in no way adjusts itself as people might expect or want. I'm arguing for the former, Alexander wants the latter.

I still stand by my argument that it is not needed for the two use cases that we concretely have in the stdlib for a timezone class: a UTC instance and %z directive in strptime. Unless there is some way for the %z directive to specify that it is actually DST, I still think the functionality of the class should be kept to a functional minimum for our needs and let people needing more support, including fixed offset DST, decide how they want to handle it. I can still see a naive user thinking that DST is the same around the world and being taken by surprise when thing don't adjust accordingly by the timezone when he does ``timezone("PDT", 7, dst=True)``. Plus giving people any semblance of a DST-supporting timezone class is just going to lead for more calls of the stdlib to include concrete timezone instances that do manage DST.

Unless other people step forward to debate this we probably are not going to reach consensus without going to python-dev to see what others think.

----------

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

From report at bugs.python.org  Fri Jun  4 22:13:40 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Fri, 04 Jun 2010 20:13:40 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1275682420.18.0.835843222268.issue8898@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

from email.charset.ALIASES most of them failed to be recognize by codecs module.


>>> for i in email.charset.ALIASES.keys():
...     try:
...         codecs.lookup(i)
...     except LookupError:
...         print("Not recognized by codecs : alias {} mapped to {}".format(i, email.charset.ALIASES[i]))
...     
... 
Not recognized by codecs : alias latin-8 mapped to iso-8859-14
Not recognized by codecs : alias latin-9 mapped to iso-8859-15
Not recognized by codecs : alias latin-2 mapped to iso-8859-2
Not recognized by codecs : alias latin-3 mapped to iso-8859-3
<codecs.CodecInfo object for encoding iso8859-1 at 0x10160af58>
Not recognized by codecs : alias latin-6 mapped to iso-8859-10
Not recognized by codecs : alias latin-7 mapped to iso-8859-13
Not recognized by codecs : alias latin-4 mapped to iso-8859-4
Not recognized by codecs : alias latin-5 mapped to iso-8859-9
<codecs.CodecInfo object for encoding euc_jp at 0x1016260b8>
Not recognized by codecs : alias latin-10 mapped to iso-8859-16
<codecs.CodecInfo object for encoding ascii at 0x101626120>
Not recognized by codecs : alias latin_10 mapped to iso-8859-16
<codecs.CodecInfo object for encoding iso8859-1 at 0x10160aae0>
Not recognized by codecs : alias latin_2 mapped to iso-8859-2
Not recognized by codecs : alias latin_3 mapped to iso-8859-3
Not recognized by codecs : alias latin_4 mapped to iso-8859-4
Not recognized by codecs : alias latin_5 mapped to iso-8859-9
Not recognized by codecs : alias latin_6 mapped to iso-8859-10
Not recognized by codecs : alias latin_7 mapped to iso-8859-13
Not recognized by codecs : alias latin_8 mapped to iso-8859-14
Not recognized by codecs : alias latin_9 mapped to iso-8859-15
<codecs.CodecInfo object for encoding cp949 at 0x101626390>
<codecs.CodecInfo object for encoding euc_kr at 0x101626530>


So basically apart from latin-1 all the latin* failed to be recognized by codecs.

----------

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

From report at bugs.python.org  Fri Jun  4 22:14:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 20:14:13 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1275682453.32.0.303188053523.issue8860@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The timedelta(seconds=0.6112295) example is handled correctly because 0.6112295 sec is not half way between two nearest microseconds:

>>> abs(0.6112295 - 0.6112290) == abs(0.6112295 - 0.6112300)
False

The fact that it displays as if it is does not make timedelta rounding wrong.  I am still not sure that it is possible to accumulate rounding error by adding seven doubles, each < 1 to affect the rounded result.

While proving that the rounding is always correct or finding a counter-example is an interesting puzzle, I think it has little practical value.

I will add unit tests and get this patch ready for for commit review, but setting the priority to "low".

----------
components: +Extension Modules
priority: normal -> low
versions: +Python 3.2

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

From report at bugs.python.org  Fri Jun  4 22:18:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 20:18:30 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1275682710.3.0.547426193026.issue8860@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The half-way check should be done with decimal arihmetics, but the result is the same:

>>> x = Decimal(0.6112295)
>>> abs(x - Decimal('0.6112290')) == abs(x - Decimal('0.6112300'))
False

----------

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

From report at bugs.python.org  Fri Jun  4 22:21:49 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Jun 2010 20:21:49 +0000
Subject: [issue8899] Add docstrings to time.struct_time
In-Reply-To: <1275680837.43.0.377357755743.issue8899@psf.upfronthosting.co.za>
Message-ID: <1275682909.91.0.0503379518119.issue8899@psf.upfronthosting.co.za>


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

Patch review: 
* Quite a few lines are pretty long.  Please stay below 80 chars/line.
* There are trailing spaces in two member docs.
* The range notation is inconsistent.  [first, last] or [first, last+1) is what we generally use.
* "if cannot be determined" does not sound grammatical, maybe just "unknown" is better.
* Between "strftime()" and "may be considered" the sentence should be split.

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

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

From report at bugs.python.org  Fri Jun  4 22:22:01 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 04 Jun 2010 20:22:01 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1275682921.87.0.0486946944464.issue8860@psf.upfronthosting.co.za>


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

> The timedelta(seconds=0.6112295) example is handled correctly

No, it's not!  It's being rounded *up* where it should be being rounded *down*.

> because 0.6112295 sec is not half way between two nearest microseconds

Exactly.  The actual value stored by the C double is a little closer to 0.611229 than to 0.611230.

----------

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

From report at bugs.python.org  Fri Jun  4 22:43:39 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 04 Jun 2010 20:43:39 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1275682420.18.0.835843222268.issue8898@psf.upfronthosting.co.za>
Message-ID: <4C096577.2080500@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Shashwat Anand wrote:
> 
> Shashwat Anand <anand.shashwat at gmail.com> added the comment:
> 
> from email.charset.ALIASES most of them failed to be recognize by codecs module.
> 
> 
>>>> for i in email.charset.ALIASES.keys():
> ...     try:
> ...         codecs.lookup(i)
> ...     except LookupError:
> ...         print("Not recognized by codecs : alias {} mapped to {}".format(i, email.charset.ALIASES[i]))
> ...     
> ... 
> Not recognized by codecs : alias latin-8 mapped to iso-8859-14
> Not recognized by codecs : alias latin-9 mapped to iso-8859-15
> Not recognized by codecs : alias latin-2 mapped to iso-8859-2
> Not recognized by codecs : alias latin-3 mapped to iso-8859-3
> <codecs.CodecInfo object for encoding iso8859-1 at 0x10160af58>
> Not recognized by codecs : alias latin-6 mapped to iso-8859-10
> Not recognized by codecs : alias latin-7 mapped to iso-8859-13
> Not recognized by codecs : alias latin-4 mapped to iso-8859-4
> Not recognized by codecs : alias latin-5 mapped to iso-8859-9
> <codecs.CodecInfo object for encoding euc_jp at 0x1016260b8>
> Not recognized by codecs : alias latin-10 mapped to iso-8859-16
> <codecs.CodecInfo object for encoding ascii at 0x101626120>
> Not recognized by codecs : alias latin_10 mapped to iso-8859-16
> <codecs.CodecInfo object for encoding iso8859-1 at 0x10160aae0>
> Not recognized by codecs : alias latin_2 mapped to iso-8859-2
> Not recognized by codecs : alias latin_3 mapped to iso-8859-3
> Not recognized by codecs : alias latin_4 mapped to iso-8859-4
> Not recognized by codecs : alias latin_5 mapped to iso-8859-9
> Not recognized by codecs : alias latin_6 mapped to iso-8859-10
> Not recognized by codecs : alias latin_7 mapped to iso-8859-13
> Not recognized by codecs : alias latin_8 mapped to iso-8859-14
> Not recognized by codecs : alias latin_9 mapped to iso-8859-15
> <codecs.CodecInfo object for encoding cp949 at 0x101626390>
> <codecs.CodecInfo object for encoding euc_kr at 0x101626530>
> 
> 
> So basically apart from latin-1 all the latin* failed to be recognized by codecs.

We need to add aliases for those codecs. The current aliases
list only supports the format "latinN" for N in 1-10.

----------
title: The email package should defer to the codecs module for all aliases -> The email package should defer to the codecs module for	all aliases

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

From report at bugs.python.org  Fri Jun  4 22:46:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 20:46:32 +0000
Subject: [issue8899] Add docstrings to time.struct_time
In-Reply-To: <1275680837.43.0.377357755743.issue8899@psf.upfronthosting.co.za>
Message-ID: <1275684392.15.0.2895195253.issue8899@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Please see fixes in issue8899.diff.

* Quite a few lines are pretty long.  Please stay below 80 chars/line.

Fixed.

* There are trailing spaces in two member docs.

Fixed.

* The range notation is inconsistent.  [first, last] or [first, last+1) is what we generally use.

Fixed in docstrings and time.rst.

* "if cannot be determined" does not sound grammatical, maybe just "unknown" is better.

Fixed.  POSIX spec uses "if the information is not available", but I like 

* Between "strftime()" and "may be considered" the sentence should be split.

Fixed in docstrings and time.rst.

----------
Added file: http://bugs.python.org/file17557/issue8899.diff

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

From report at bugs.python.org  Fri Jun  4 22:53:04 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Fri, 04 Jun 2010 20:53:04 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1275684784.08.0.39836176133.issue8898@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

>We need to add aliases for those codecs. The current aliases
>list only supports the format "latinN" for N in 1-10.

latinN means latin1 to latin10 ? 
But latin_1 is a recognized alias.

>>> codecs.lookup('latin_1')
<codecs.CodecInfo object for encoding iso8859-1 at 0x10160aae0>

----------

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

From report at bugs.python.org  Fri Jun  4 23:09:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Jun 2010 21:09:11 +0000
Subject: [issue8899] Add docstrings to time.struct_time
In-Reply-To: <1275680837.43.0.377357755743.issue8899@psf.upfronthosting.co.za>
Message-ID: <1275685751.29.0.0815406834185.issue8899@psf.upfronthosting.co.za>


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

The first change in time.rst is not needed; there the sentence is not a direct description of struct_time.  The rest is good to commit.

----------

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

From report at bugs.python.org  Fri Jun  4 23:14:19 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 04 Jun 2010 21:14:19 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1275684784.08.0.39836176133.issue8898@psf.upfronthosting.co.za>
Message-ID: <4C096CA7.3040508@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Shashwat Anand wrote:
> 
> Shashwat Anand <anand.shashwat at gmail.com> added the comment:
> 
>> We need to add aliases for those codecs. The current aliases
>> list only supports the format "latinN" for N in 1-10.
> 
> latinN means latin1 to latin10 ? 

Yes. We should add aliases for the format "latin_N" as well.

> But latin_1 is a recognized alias.
> 
>>>> codecs.lookup('latin_1')
> <codecs.CodecInfo object for encoding iso8859-1 at 0x10160aae0>

Yes, since that's the native name of the dedicated Python codec
for ISO-8859-1.

----------

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

From report at bugs.python.org  Fri Jun  4 23:22:22 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jun 2010 21:22:22 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1275686542.46.0.763477032981.issue8847@psf.upfronthosting.co.za>


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

Running the exact same binary on winxp with an amd athlon processor,
I *did* get a crash after about 5 seconds. "python.exe has encountered a problem and needs to close.  We are sorry for the inconvenience."
Trying again with IDLE instead of the command window, I get the same message (for pythonw instead of python) and the shell restarts when I close the message.

Even though foo()+[1] correctly raises a TypeError, the reverse [1] + foo() very bizarrely produces a length 1 tuple whose bizarre member is supposedly an instance of a empty list [] with length 1

from collections import namedtuple
foo = namedtuple('foo', '')
a = [1] + foo()
b=a[0]
print (type(a), len(a), type(b), len(type(b)), type(type(b)))

# <class 'tuple'> 1 [] 1 <class 'list'>

([2]+foo() produces same output)

Other than the above, any attempt to do anything with b or type(b) that I tried crashes. I presume that this is due to attribute lookups on the invalid type(b) (or something like that), which type(b) must bypass. In particular, the OP's crash is due to trying to print the tuple which tries to print its member which looks for type(b).__str__ which crashes.

To anyone: investigating crashers like this is a lot easier with IDLE and an edit window than with the interactive command window.

----------
nosy: +tjreedy
resolution: works for me -> 

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

From report at bugs.python.org  Fri Jun  4 23:22:36 2010
From: report at bugs.python.org (AdamN)
Date: Fri, 04 Jun 2010 21:22:36 +0000
Subject: [issue1712522] urllib.quote throws exception on Unicode URL
Message-ID: <1275686556.26.0.200603701406.issue1712522@psf.upfronthosting.co.za>


AdamN <adam at varud.com> added the comment:

Nudge.  Somebody with the authority needs to increment the stage to "patch review".

----------
nosy: +adamnelson

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

From report at bugs.python.org  Fri Jun  4 23:30:42 2010
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 04 Jun 2010 21:30:42 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1275687042.29.0.492918641477.issue8847@psf.upfronthosting.co.za>


Changes by Jack Diederich <jackdied at gmail.com>:


----------
nosy: +jackdied

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

From report at bugs.python.org  Fri Jun  4 23:31:05 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 04 Jun 2010 21:31:05 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1275687065.89.0.123635676067.issue8847@psf.upfronthosting.co.za>


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


----------
priority: normal -> high

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

From report at bugs.python.org  Fri Jun  4 23:58:53 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 04 Jun 2010 21:58:53 +0000
Subject: [issue1712522] urllib.quote throws exception on Unicode URL
Message-ID: <1275688733.71.0.718394122325.issue1712522@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jun  5 00:17:43 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 22:17:43 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1275682160.9.0.0914585409976.issue5094@psf.upfronthosting.co.za>
Message-ID: <AANLkTimoNxUY5mnmveq1y_P2SJjLdBjyTSOk4UxLhcPj@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Jun 4, 2010 at 4:09 PM, Brett Cannon <report at bugs.python.org> wrote:
..
> For the allowable range, follow the datetime docs as someone might be relying on that specification already.
>
Will do.  I think it is as simple simple s/12/24/ in two places of the
current patch, but I will check and make sure it is tested by
unittests.

> As for the ongoing DST debate, it seems we either need to say that since we cannot properly support all possible
> datetimes properly we should simply not even try, fixed offset or not, or we provide a class that gives the proper UTC
> offset, but in no way adjusts itself as people might expect or want. I'm arguing for the former, Alexander wants the latter.
>

I disagree with your premise that "we cannot properly support all
possible datetimes." If issue1647654 patch is applied, I can rewrite
datetimeex.py so that print(localtime()) is consistent with the system
date utility on Linux/MacOS/BSD for all times.  This however can be
achieved without DST offset in timezone object.

The only issue is what time.strftime("%Z", localtime().timetuple())
will print.  Recall that tm_isdst (the last entry in timetuple) is set
according to what dst() returns.  If dst() is None,  tm_isdst = -1, if
dst() is timedelta(0),  tm_isdst = 0 and if dst() is non-zero
timedelta, tm_isdst = 1.  In these three cases, %Z will be formated as
empty string, time.tzname[0] ('EST' in New York) and time.tzname[1]
('EDT' in New York) respectively.

I would really like to get localtime() in datetime library at the next
step. In the distant future, datetime.now() can be redefined to return
aware local time.  If this happens, we need to decide what
localtime().dst() should return.  With the current patch, it will
return timedelta(0) which is wrong 50% of the time.  A correct
alternative is to return None, but this will be rather odd for
timezone.utc.

It appears that in order to implement dst() correctly to the letter of
tzinfo specification there are really two choices:

1.  Have separate classes: UTC and FixedOffsetTimezone with different
dst().  UTC().dst(dt) -> timedelta(0) and
FixedOffsetTimezone(offset).dst(dt) -> None.

2. Have a single class with dst(dt) returning fixed stored value.

I think #2 clearly wins on simplicity.

> I still stand by my argument that it is not needed for the two use cases that we concretely have in the stdlib for a
> timezone class: a UTC instance and %z directive in strptime.

I agree.  The third member is needed to support aware local time,
which is the third use case.

> ..
> I can still see a naive user thinking that DST is the same around the world and being taken
> by surprise when thing don't adjust accordingly by the timezone when he does ``timezone("PDT", 7, dst=True)``.

The actual syntax would be PDT = timezone(timedelta(hours=7), "PDT",
dst=timedelta(hours=1)) (or -1 - I have to check).  Is the surprise
you have in mind that PDT.utcoffset(dt) is the same for dt in June and
January? I agree this is not ideal and I would much rather not allow
timezone.utcoffset() to take an argument, but this is not possible
within the tzinfo design.  Best we can do is to make the argument to
utcoffset() optional and naive users will not even know that they can
pass time value to the timezone methods.

I think this is still less evil than to have an aware datetime t with
t.tzname() -> 'PDT' and time.strftime('%Z', t.timetuple()) -> 'PST'.

> Plus giving people any semblance of a DST-supporting timezone class is just going to lead for more calls of the
> stdlib to include concrete timezone instances that do manage DST.
>

Again, managing DST is to use different timezone instances for
different real times.  It is not hard to do that.  Implementing
time-dependent utcoffset(dt) in a concrete tzinfo subclass is
impossible unambiguously.  In the long term we should be looking to
deprecate the time argument to tzinfo methods.

> Unless other people step forward to debate this we probably are not going to reach consensus
> without going to python-dev to see what others think.

Given the history of such discussions, I think we should reach
consensus here first.  I don't mind starting with a two-component
timezone class and dst() returning None for all instances including
timezone.utc.  I still believe the cost of supporting DST is really
small and adding it now is easier than in the future.

----------

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

From report at bugs.python.org  Sat Jun  5 00:26:24 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 22:26:24 +0000
Subject: [issue8899] Add docstrings to time.struct_time
In-Reply-To: <1275680837.43.0.377357755743.issue8899@psf.upfronthosting.co.za>
Message-ID: <1275690384.11.0.666025399025.issue8899@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
resolution:  -> accepted

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

From report at bugs.python.org  Sat Jun  5 00:39:41 2010
From: report at bugs.python.org (Christophe Kalt)
Date: Fri, 04 Jun 2010 22:39:41 +0000
Subject: [issue8893] file.{read,readlines} behaviour on Solaris
In-Reply-To: <1275609044.71.0.537925857344.issue8893@psf.upfronthosting.co.za>
Message-ID: <1275691181.22.0.0473119166504.issue8893@psf.upfronthosting.co.za>


Christophe Kalt <kalt at taranis.org> added the comment:

FreeBSD is yet another beast:

$ uname -rs
FreeBSD 8.0-STABLE
$ python -V
Python 2.5.5
$ python readlines.py
read     :  []
readlines:  []
readline :

----------

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

From report at bugs.python.org  Sat Jun  5 00:40:00 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Jun 2010 22:40:00 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <AANLkTimoNxUY5mnmveq1y_P2SJjLdBjyTSOk4UxLhcPj@mail.gmail.com>
Message-ID: <AANLkTikZNxZdcmvDuPqICaImdtkArN8ajelJ3UG8eJ0v@mail.gmail.com>


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

On Fri, Jun 4, 2010 at 15:17, Alexander Belopolsky
<report at bugs.python.org> wrote:
>
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
>
> On Fri, Jun 4, 2010 at 4:09 PM, Brett Cannon <report at bugs.python.org> wrote:
> ..
>> For the allowable range, follow the datetime docs as someone might be relying on that specification already.
>>
> Will do. ?I think it is as simple simple s/12/24/ in two places of the
> current patch, but I will check and make sure it is tested by
> unittests.

Great!

>
>> As for the ongoing DST debate, it seems we either need to say that since we cannot properly support all possible
>> datetimes properly we should simply not even try, fixed offset or not, or we provide a class that gives the proper UTC
>> offset, but in no way adjusts itself as people might expect or want. I'm arguing for the former, Alexander wants the latter.
>>
>
> I disagree with your premise that "we cannot properly support all
> possible datetimes." If issue1647654 patch is applied, I can rewrite
> datetimeex.py so that print(localtime()) is consistent with the system
> date utility on Linux/MacOS/BSD for all times. ?This however can be
> achieved without DST offset in timezone object.

Well, I think the time module needs to be slowly phased out in
preference for datetime and we stop monkey-patching the time tuple
over and over again. The datetime module provides a much nicer
interface and TOOWTDI, but that's a long term goal.

>
> The only issue is what time.strftime("%Z", localtime().timetuple())
> will print. ?Recall that tm_isdst (the last entry in timetuple) is set
> according to what dst() returns. ?If dst() is None, ?tm_isdst = -1, if
> dst() is timedelta(0), ?tm_isdst = 0 and if dst() is non-zero
> timedelta, tm_isdst = 1. ?In these three cases, %Z will be formated as
> empty string, time.tzname[0] ('EST' in New York) and time.tzname[1]
> ('EDT' in New York) respectively.
>
> I would really like to get localtime() in datetime library at the next
> step. In the distant future, datetime.now() can be redefined to return
> aware local time. ?If this happens, we need to decide what
> localtime().dst() should return. ?With the current patch, it will
> return timedelta(0) which is wrong 50% of the time. ?A correct
> alternative is to return None, but this will be rather odd for
> timezone.utc.

True.

>
> It appears that in order to implement dst() correctly to the letter of
> tzinfo specification there are really two choices:
>
> 1. ?Have separate classes: UTC and FixedOffsetTimezone with different
> dst(). ?UTC().dst(dt) -> timedelta(0) and
> FixedOffsetTimezone(offset).dst(dt) -> None.
>
> 2. Have a single class with dst(dt) returning fixed stored value.
>
> I think #2 clearly wins on simplicity.

Or #3: We have a UTC class as originally proposed way back when. We
can even make all the methods staticmethods so that I get my desire to
not require instantiating an instance while you do get your
pseudo-singleton you originally wanted.

>
>> I still stand by my argument that it is not needed for the two use cases that we concretely have in the stdlib for a
>> timezone class: a UTC instance and %z directive in strptime.
>
> I agree. ?The third member is needed to support aware local time,
> which is the third use case.

Sure, but we are not even there yet to consider that use case are we?

>
>> ..
>> I can still see a naive user thinking that DST is the same around the world and being taken
>> by surprise when thing don't adjust accordingly by the timezone when he does ``timezone("PDT", 7, dst=True)``.
>
> The actual syntax would be PDT = timezone(timedelta(hours=7), "PDT",
> dst=timedelta(hours=1)) (or -1 - I have to check).

Yes, I was typing from the cuff.

> ?Is the surprise
> you have in mind that PDT.utcoffset(dt) is the same for dt in June and
> January?

Exactly.

> I agree this is not ideal and I would much rather not allow
> timezone.utcoffset() to take an argument, but this is not possible
> within the tzinfo design. ?Best we can do is to make the argument to
> utcoffset() optional and naive users will not even know that they can
> pass time value to the timezone methods.

This is all starting to feel like the entire tzinfo ABC needs to be
re-thought and either expanded upon or replaced.

>
> I think this is still less evil than to have an aware datetime t with
> t.tzname() -> 'PDT' and time.strftime('%Z', t.timetuple()) -> 'PST'.
>
>> Plus giving people any semblance of a DST-supporting timezone class is just going to lead for more calls of the
>> stdlib to include concrete timezone instances that do manage DST.
>>
>
> Again, managing DST is to use different timezone instances for
> different real times. ?It is not hard to do that. ?Implementing
> time-dependent utcoffset(dt) in a concrete tzinfo subclass is
> impossible unambiguously. ?In the long term we should be looking to
> deprecate the time argument to tzinfo methods.

This is why I hate datetime stuff. =)

>
>> Unless other people step forward to debate this we probably are not going to reach consensus
>> without going to python-dev to see what others think.
>
> Given the history of such discussions, I think we should reach
> consensus here first. ?I don't mind starting with a two-component
> timezone class and dst() returning None for all instances including
> timezone.utc. ?I still believe the cost of supporting DST is really
> small and adding it now is easier than in the future.

So how about this: we implement a UTC class now which contains only
staticmethods to get you your singleton and me not having to
instantiate the class. Then you take your time in possibly expanding
the tzinfo class or coming up with a new ABC which replaces tzinfo
that fixes all of these crazy problems. I have been arguing from a
code maintainability and naive user POV, you from an experienced
datetime POV. Lets solve my POV now and just start the ball rolling in
solving your POV properly long-term instead of trying to shoe-horn
known issues into pre-existing stuff. People complain about datetime
enough, so let's take the time to fix it. The UTC class can be a
stop-gap until datetime gets fixed (which could be in 3.2 if stuff
happened really rapidly and the UTC solution can be ripped out; it's
just code).

----------

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

From report at bugs.python.org  Sat Jun  5 00:51:31 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jun 2010 22:51:31 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1275691891.34.0.159102110547.issue8847@psf.upfronthosting.co.za>


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

More experiments

from collections import namedtuple
foo = namedtuple('foo', '')
a = [] + foo()
print (a, type(a), len(a))
# () <class 'tuple'> 0

ie, a standard empty tuple, whereas
a = [1,1] + foo()
crashes immediately. So the behavior of list()+namedtuple depends on the length of the list.

There are also some funny interactions. Adding
try:
    a = foo()+[]
except TypeError:
    print("correct TypeError")

after the 'foo = ' line in my original 5 line example causes the final print to crash, whereas adding the same 4 lines to the 4 line example at the beginning of this message does not obviously change anything.

David, since you omitted all details, I wonder if you tested in batch mode, as I did, and hence never tried to print the malformed object, or used different OS or hardware.

----------

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

From report at bugs.python.org  Sat Jun  5 01:11:29 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jun 2010 23:11:29 +0000
Subject: [issue8885] markerbase declaration errors aren't recoverable
In-Reply-To: <1275563651.6.0.351540013915.issue8885@psf.upfronthosting.co.za>
Message-ID: <1275693089.47.0.359763264519.issue8885@psf.upfronthosting.co.za>


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

Neither markerbase nor markupbase are in the list of 2.6 stdlib modules at
http://docs.python.org/modindex.html
even with all packages [+] listings expanded to [-].
So I have to guess this is a third party module. If so, please close and report to *its* authors, not here.

----------
nosy: +tjreedy
resolution:  -> invalid
status: open -> pending

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

From report at bugs.python.org  Sat Jun  5 01:16:22 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jun 2010 23:16:22 +0000
Subject: [issue8890] Modules have dangerous examples in documentation
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275693382.92.0.586800244335.issue8890@psf.upfronthosting.co.za>


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

Henri, the owasp link you gave in your opening post now gives Bad Title error msg.

----------
nosy: +tjreedy

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

From report at bugs.python.org  Sat Jun  5 01:35:10 2010
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 04 Jun 2010 23:35:10 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1275694510.34.0.133890958993.issue8847@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

I can't reproduce on 3k trunk with Ubuntu 10.04, gcc 4.4.3

namedtuples are just a subclass of tuple with only two dunder methods defined (a plain __new__ with empty __slots__).  Can you provoke the same behavior with plain tuples, or a subclass of tuple that looks like one of these?

class Crasher(tuple): pass

class Crasher(tuple):
  __slots__ = ()

class Crasher(tuple):
  def __new__(cls,): return tuple.__new__(cls,)
  __slots__ = ()

----------

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

From report at bugs.python.org  Sat Jun  5 01:53:53 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jun 2010 23:53:53 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1275695633.46.0.533443196978.issue8847@psf.upfronthosting.co.za>


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

Substituting
foo = tuple()
TypeError: can only concatenate list (not "tuple") to list

class Crasher(tuple): pass
foo = Crasher()
a = [1] + foo
b=a[0]
print (type(a), len(a), type(b), len(type(b)), type(type(b)))

<class 'tuple'> 1 [] 1 <class 'list'>

as before, so namedtuple is not, in particular, the culprit.
Other two Crasher versions do the same. I also get a delayed pythonw error message after the print that does not cause the shell to restart. This may partly be an IDLE artifact.

----------

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

From report at bugs.python.org  Sat Jun  5 01:58:18 2010
From: report at bugs.python.org (Michael Huster)
Date: Fri, 04 Jun 2010 23:58:18 +0000
Subject: [issue8900] IDLE crashes if Preference set to At Startup -> Open Edit
	Window
In-Reply-To: <1275695898.02.0.763223364629.issue8900@psf.upfronthosting.co.za>
Message-ID: <1275695898.02.0.763223364629.issue8900@psf.upfronthosting.co.za>


New submission from Michael Huster <mhuster55 at gmail.com>:

This only seems to be a problem under Windows.
>From a Portable Python discussion:
I am using Portable Python 1.1, python 3.0.1.
I am trying to set up a .bat file file to easily start IDLE. But IDLE
is throwing an error and failing some of the time.
It only happens if IDLE is set up to start in the edit mode. (Which I
prefer.) And then it only throws the error the first time a file is
opened. It doesn't seem to matter what kind of file is opened. The
other symptom is that a new line is inserted at the top of the file
that is opened.

The error is (I'm typing it by hand):
Exception in Tkinter callback
Traceback (most recent call last):
 File "E:\py30\App\lib\tkinter\__init__.py", line 1399, in __call__
   return self.func(*args)
 File "E:\py30\App\lib\idlelib\MultiCall.py", line 174, in handler
doafterhandler.pop()()
 File "E:\py30\App\lib\idlelib\MultiCall.py", line 221, in <lambda>
doit = lambda: self.bindedfuncs[triplet[2]][triplet[0]].remove(func)
ValueError: list.remove(x): x not in list

I can work around this with a batch file that uses python.exe, not
pythonw.exe, but it leaves an annoying command shell window open.

I also tested IDLE under a normal python installation and the same thing happens, so, sorry, it is not a PP thing. There must be a bug in IDLE under py 3.0. I'll file this with python.org.

----------
components: IDLE
messages: 107113
nosy: mhuster
priority: normal
severity: normal
status: open
title: IDLE crashes if Preference set to At Startup -> Open Edit Window
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Sat Jun  5 02:18:16 2010
From: report at bugs.python.org (Mark Nottingham)
Date: Sat, 05 Jun 2010 00:18:16 +0000
Subject: [issue8885] markerbase declaration errors aren't recoverable
In-Reply-To: <1275563651.6.0.351540013915.issue8885@psf.upfronthosting.co.za>
Message-ID: <1275697096.76.0.147561647192.issue8885@psf.upfronthosting.co.za>


Mark Nottingham <mnot at mnot.net> added the comment:

http://svn.python.org/view/python/trunk/Lib/markupbase.py?view=log

----------
status: pending -> open

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

From report at bugs.python.org  Sat Jun  5 02:37:17 2010
From: report at bugs.python.org (Jack Diederich)
Date: Sat, 05 Jun 2010 00:37:17 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1275698237.82.0.120411988942.issue8847@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

Two more probes:

1) does it also have the same strange/crashy behavior when you subclass list and concat that to a tuple?

2) does dropping the optimization level down to -O help?  This has "compiler quirk" written all over it.  The C-code for list and tuple concat are almost identical, and both start with a type check.

----------

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

From report at bugs.python.org  Sat Jun  5 02:39:35 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Jun 2010 00:39:35 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1275698375.37.0.270594662155.issue8847@psf.upfronthosting.co.za>


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

"can't reproduce" does not inform as to what *did* happen with which code.

More experiments:
foo = str()
TypeError: can only concatenate list (not "str") to list

class s(str): pass
foo = s()
TypeError: Can't convert 'list' object to str implicitly

Why is it trying to do that? Of course, the interpreter can (implicitly) convert list to tuple, which must be what happens in OP example.

The subclasses of tuple and str do not gain an __radd__ method. If we add one

class s(str):
    def __radd__(s,o): print('in radd, type(o)')
foo = s()
a = [1] + foo
# prints "in radd <class 'list'>"

no implicit conversion is done.

Reversing tuple and list

class Crasher(list): pass
a = () + Crasher() # or Crasher([1])
print(a, type(a), len(a))
#[] <class 'list'> 0 # or [1] <class 'list'> 1

whereas
a = (1,) + Crasher()
crashes, so not completely symmetrical

----------

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

From report at bugs.python.org  Sat Jun  5 02:47:28 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Jun 2010 00:47:28 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1275698848.28.0.0756073111317.issue8847@psf.upfronthosting.co.za>


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

1) answered before you asked (yes, similar)
2) (same thought) I am using PSF windows installer, however that was prepared. Martin?

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

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

From report at bugs.python.org  Sat Jun  5 02:53:01 2010
From: report at bugs.python.org (Edward Pilatowicz)
Date: Sat, 05 Jun 2010 00:53:01 +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: <1275699181.28.0.114740635491.issue8882@psf.upfronthosting.co.za>


Edward Pilatowicz <edward.pilatowicz at oracle.com> added the comment:

some additional data.

AIX 6.1:
    defined sun_path = 1023
    max sun_path = 1023

i'll also point out the existence of the SUN_LEN() macro, which is
defined on all the previously mentioned operating systems, and which
calculates the size of a sockaddr_un structure using strlen() of
sun_path, not sizeof().

that said, as a counter argument, UNIX Network Programming by Richard
Stevens explicitly mentions that the use of sizeof() is ok.

still, personally, i think it's pretty risky for an OS to change this
definition.  (it seems that AIX is the only OS i've seen that has done
so.)  i say this because use of the sockaddr_un structure is so
prevalent.  it's commonly embedded into other structures and passed
around via APIs that (unlike bind(), connect(), etc) don't take a size
parameter which specifies the size of the structure.

----------

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

From report at bugs.python.org  Sat Jun  5 03:31:57 2010
From: report at bugs.python.org (Jack Diederich)
Date: Sat, 05 Jun 2010 01:31:57 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1275701517.16.0.648116430065.issue8847@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

if the id() of the left operand is identical to the id() of the first element in the result it would strongly support compiler skulldugerry.

class Crasher(tuple): pass
foo = Crasher()
x = [1]
a = x + foo
b=a[0]

if id(b) == id(x):
  raise Exception("It's the C compiler what did it!")

The only way I can think of this coming about is the right_op getting new'd and then .extend'ing(left_op).  That extend() must be going batsh*t and inserting the left_op instead of it's contained items.  The C-code for extend is more fiddly than the code for concatenation so there is more room for the compiler to generate bad code.

----------

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

From report at bugs.python.org  Sat Jun  5 04:13:04 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Jun 2010 02:13:04 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1275703984.47.0.416857194985.issue8847@psf.upfronthosting.co.za>


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

Good try, but for one run, the ids of foo, x, a, and b are
>>> 
15719440 15717880 15273104 12266976

----------

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

From report at bugs.python.org  Sat Jun  5 04:39:25 2010
From: report at bugs.python.org (flashk)
Date: Sat, 05 Jun 2010 02:39:25 +0000
Subject: [issue8901] Windows registry path not ignored with -E option
In-Reply-To: <1275705565.03.0.753930892849.issue8901@psf.upfronthosting.co.za>
Message-ID: <1275705565.03.0.753930892849.issue8901@psf.upfronthosting.co.za>


New submission from flashk <flashk at gmail.com>:

Hi,

I noticed that Python still uses the Windows registry to initialize sys.path, when the -E option is used.

>From my understanding, this option is mostly used by programs that are running an embedded version of python, and don't want it to be affected by global installations. Ignoring the registry, along with environment variables, seems to be the correct behavior in this case.

I asked about this on the python-dev list (http://mail.python.org/pipermail/python-dev/2010-June/100492.html) and was told to submit a patch for this if I wanted it fixed before the 2.7 release.

I've included a patch for 2.7 and 3.2

----------
components: Interpreter Core
files: IgnoreWindowsRegistry_27.patch
keywords: patch
messages: 107121
nosy: flashk
priority: normal
severity: normal
status: open
title: Windows registry path not ignored with -E option
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17558/IgnoreWindowsRegistry_27.patch

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

From report at bugs.python.org  Sat Jun  5 04:39:46 2010
From: report at bugs.python.org (flashk)
Date: Sat, 05 Jun 2010 02:39:46 +0000
Subject: [issue8901] Windows registry path not ignored with -E option
In-Reply-To: <1275705565.03.0.753930892849.issue8901@psf.upfronthosting.co.za>
Message-ID: <1275705586.02.0.892586601031.issue8901@psf.upfronthosting.co.za>


Changes by flashk <flashk at gmail.com>:


Added file: http://bugs.python.org/file17559/IgnoreWindowsRegistry_32.patch

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

From report at bugs.python.org  Sat Jun  5 08:36:29 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 06:36:29 +0000
Subject: [issue8902] add datetime.time.now() for consistency
In-Reply-To: <1275719789.45.0.168425659941.issue8902@psf.upfronthosting.co.za>
Message-ID: <1275719789.45.0.168425659941.issue8902@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

There is:
datetime.date.today()
datetime.datetime.today()
datetime.datetime.now([tz])

But no:
datetime.time.now([tz])

----------
components: Library (Lib)
messages: 107122
nosy: techtonik
priority: normal
severity: normal
status: open
title: add datetime.time.now() for consistency
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jun  5 08:48:27 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 06:48:27 +0000
Subject: [issue8903] datetime functions
In-Reply-To: <1275720507.31.0.185559003971.issue8903@psf.upfronthosting.co.za>
Message-ID: <1275720507.31.0.185559003971.issue8903@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Current OOP API of datetime is ugly:

from datetime import datetime
print datetime.today().isoformat()

The proposal is to add today() and now() as module functions:

from datetime import today, now
print today()
# datetime.date(2010, 6, 5)
print now()
# datetime.datetime(2010, 6, 5, 9, 48, 4, 868000)

----------
components: Library (Lib)
messages: 107123
nosy: techtonik
priority: normal
severity: normal
status: open
title: datetime functions
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jun  5 09:33:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 05 Jun 2010 07:33:32 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1275723212.69.0.507018170459.issue8847@psf.upfronthosting.co.za>


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

The binaries get compiled with the PGInstrument/PGUpdate configurations.

----------

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

From report at bugs.python.org  Sat Jun  5 10:44:46 2010
From: report at bugs.python.org (Jan Kratochvil)
Date: Sat, 05 Jun 2010 08:44:46 +0000
Subject: [issue4434] Embedding into a shared library fails
In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za>
Message-ID: <1275727486.57.0.401283484737.issue4434@psf.upfronthosting.co.za>


Changes by Jan Kratochvil <jan.kratochvil at redhat.com>:


----------
nosy: +jankratochvil

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

From report at bugs.python.org  Sat Jun  5 11:18:25 2010
From: report at bugs.python.org (Tal Einat)
Date: Sat, 05 Jun 2010 09:18:25 +0000
Subject: [issue4785] json.JSONDecoder() strict argument undocumented and
	potentially confusing
In-Reply-To: <1230658934.34.0.991784557371.issue4785@psf.upfronthosting.co.za>
Message-ID: <1275729505.23.0.574189488018.issue4785@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

Documentation patch attached against py3k branch.

Changes are:

* Added to documentation of JSONDecoder:

If *strict* is ``False`` (``True`` is the default), then control characters will be allowed inside strings.  Control characters in this context are those with character codes in the 0-31 range, including ``'\t'`` (tab), ``'\n'``, ``'\r'`` and ``'\0'``.

* Added clarification in documentation of json.load and json.dump that unless the cls kwarg is specified, the JSONEncoder/JSONDecoder class will be used.

* Mirrored these additions in the relevant doc-strings (JSONDecoder.__init__, json.load, json.loads, json.dump, json.dumps).

* Copied description of the object_pairs_hook kwargs from the documentation to the relevant doc-strings, which otherwise fully mirrored the documentation. (json.load, json.loads, JSONDecoder.__init__)

----------
keywords: +patch
versions: +Python 3.2 -Python 2.6, Python 3.0
Added file: http://bugs.python.org/file17560/json_docs_py3k.diff

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

From report at bugs.python.org  Sat Jun  5 11:19:45 2010
From: report at bugs.python.org (Tal Einat)
Date: Sat, 05 Jun 2010 09:19:45 +0000
Subject: [issue4785] json.JSONDecoder() strict argument undocumented and
	potentially confusing
In-Reply-To: <1230658934.34.0.991784557371.issue4785@psf.upfronthosting.co.za>
Message-ID: <1275729585.24.0.924457885731.issue4785@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

Similar patch against trunk; same changes as for the py3k branch.

----------
Added file: http://bugs.python.org/file17561/json_docs_trunk.diff

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

From report at bugs.python.org  Sat Jun  5 11:20:11 2010
From: report at bugs.python.org (Tal Einat)
Date: Sat, 05 Jun 2010 09:20:11 +0000
Subject: [issue4785] json.JSONDecoder() strict argument undocumented and
	potentially confusing
In-Reply-To: <1230658934.34.0.991784557371.issue4785@psf.upfronthosting.co.za>
Message-ID: <1275729611.55.0.397660829656.issue4785@psf.upfronthosting.co.za>


Changes by Tal Einat <taleinat at users.sourceforge.net>:


----------
versions: +Python 2.7

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

From report at bugs.python.org  Sat Jun  5 12:30:48 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 10:30:48 +0000
Subject: [issue8904] quick example how to fix docs
In-Reply-To: <1275733848.36.0.713191812865.issue8904@psf.upfronthosting.co.za>
Message-ID: <1275733848.36.0.713191812865.issue8904@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

It would be helpful to have examples how to patch docs in some place like 
http://docs.python.org/bugs.html

For example, in CHM version of 2.6.5 manual open() anchor points to reference/datamodel.html#index-844 and to tutorial/inputoutput.html#index-1080 but not to library/functions.html#open

----------
assignee: docs at python
components: Documentation
messages: 107127
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: quick example how to fix docs

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

From report at bugs.python.org  Sat Jun  5 12:36:44 2010
From: report at bugs.python.org (Tal Einat)
Date: Sat, 05 Jun 2010 10:36:44 +0000
Subject: [issue8900] IDLE crashes if Preference set to At Startup -> Open Edit
	Window
In-Reply-To: <1275695898.02.0.763223364629.issue8900@psf.upfronthosting.co.za>
Message-ID: <1275734204.27.0.06389348413.issue8900@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

I can consistently reproduce this with Python 3.0.1 by setting IDLE to start in editing mode and using Ctrl+o to open the Open dialog. Doesn't happen when using the menu item in the File menu.

This leads me to believe it has something to do with keypress event processing. Also, the event for which the unbind call is failing is <Control-KeyPress-slash>.

Continuing to investigate.

----------
nosy: +taleinat

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

From report at bugs.python.org  Sat Jun  5 13:25:17 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 05 Jun 2010 11:25:17 +0000
Subject: [issue8351] Suppress large diffs in
	unitttest.TestCase.assertSequenceEqual()
In-Reply-To: <1270769804.42.0.714910786313.issue8351@psf.upfronthosting.co.za>
Message-ID: <1275737117.75.0.385563838674.issue8351@psf.upfronthosting.co.za>


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

Slightly modified version committed revision 81728. (It truncates large diffs rather than omitting them and allows max_diff to be None - meaning no maximum.) Needs some extended tests and needs documenting.

----------

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

From report at bugs.python.org  Sat Jun  5 13:45:41 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 11:45:41 +0000
Subject: [issue8905] difflib: support input generators
In-Reply-To: <1275738341.19.0.989231664853.issue8905@psf.upfronthosting.co.za>
Message-ID: <1275738341.19.0.989231664853.issue8905@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

difflib operates on the lists, but it should be possible to use arbitrary generators. This will require internal limit on buffer size that has a side advantage of limiting difflib to available memory.

----------
components: Library (Lib)
messages: 107130
nosy: techtonik
priority: normal
severity: normal
status: open
title: difflib: support input generators
type: resource usage
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jun  5 14:11:56 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 05 Jun 2010 12:11:56 +0000
Subject: [issue8351] Suppress large diffs in
	unitttest.TestCase.assertSequenceEqual()
In-Reply-To: <1270769804.42.0.714910786313.issue8351@psf.upfronthosting.co.za>
Message-ID: <1275739916.03.0.444901732919.issue8351@psf.upfronthosting.co.za>


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

Modified again in revision 81739. No longer uses a new argument, but a class attribute instead. All assert methods that generate failure messages with difflib truncate messages.

----------

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

From report at bugs.python.org  Sat Jun  5 14:30:06 2010
From: report at bugs.python.org (Floris Bruynooghe)
Date: Sat, 05 Jun 2010 12:30:06 +0000
Subject: [issue8906] Document TestCase attributes in class docstring
In-Reply-To: <1275741006.84.0.66027792452.issue8906@psf.upfronthosting.co.za>
Message-ID: <1275741006.84.0.66027792452.issue8906@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:

The unittest.TestCase class has some public attributes: failureException, longMessage and maxDiff.  They each have a description in a comment, but I think it would be good if that description got moved into the class docstring so that it would be found using help().

----------
components: Library (Lib)
messages: 107132
nosy: ezio.melotti, flub
priority: normal
severity: normal
status: open
title: Document TestCase attributes in class docstring
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Jun  5 14:39:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Jun 2010 12:39:56 +0000
Subject: [issue8627] Unchecked PyErr_WarnPy3k return value in
	Objects/typeobject.c
In-Reply-To: <1273069856.93.0.435136167669.issue8627@psf.upfronthosting.co.za>
Message-ID: <1275741596.1.0.764245347319.issue8627@psf.upfronthosting.co.za>


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

Removed the __cmp__ warning in r81736, and added a PyErr_Clear() for the __eq__ warning in r81740.  I'll leave this open in case anyone wants to figure out how to propagate the warning exception properly.

----------

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

From report at bugs.python.org  Sat Jun  5 14:40:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Jun 2010 12:40:56 +0000
Subject: [issue8627] Unchecked PyErr_WarnPy3k return value in
	Objects/typeobject.c
In-Reply-To: <1273069856.93.0.435136167669.issue8627@psf.upfronthosting.co.za>
Message-ID: <1275741656.9.0.042375231367.issue8627@psf.upfronthosting.co.za>


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

Not sure why I added 3.1 and 3.2 to the versions.

----------
versions:  -Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Jun  5 15:40:44 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 05 Jun 2010 13:40:44 +0000
Subject: [issue8351] Suppress large diffs in
	unitttest.TestCase.assertSequenceEqual()
In-Reply-To: <1270769804.42.0.714910786313.issue8351@psf.upfronthosting.co.za>
Message-ID: <1275745244.83.0.0829128951235.issue8351@psf.upfronthosting.co.za>


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

Modified again in revision 81752. Assertion methods now inform you when omitting an excessively long diff.

----------

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

From report at bugs.python.org  Sat Jun  5 16:00:57 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 05 Jun 2010 14:00:57 +0000
Subject: [issue8351] Suppress large diffs in
	unitttest.TestCase.assertSequenceEqual()
In-Reply-To: <1270769804.42.0.714910786313.issue8351@psf.upfronthosting.co.za>
Message-ID: <1275746457.27.0.530276094641.issue8351@psf.upfronthosting.co.za>


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

Still some tests and documentation needed. Leaving issue open until it is done. (Also needs backporting to unittest2...)

----------

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

From report at bugs.python.org  Sat Jun  5 16:06:13 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 05 Jun 2010 14:06:13 +0000
Subject: [issue8351] Suppress large diffs in
	unitttest.TestCase.assertSequenceEqual()
In-Reply-To: <1270769804.42.0.714910786313.issue8351@psf.upfronthosting.co.za>
Message-ID: <1275746773.8.0.62506180792.issue8351@psf.upfronthosting.co.za>


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

Note that we also have a bit of a performance issue in prettyprint / difflib when the diffs are very big. It can spend a minute or more constructing the diff - only to throw it away because it is too big...

----------

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

From report at bugs.python.org  Sat Jun  5 17:13:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 05 Jun 2010 15:13:30 +0000
Subject: [issue8899] Add docstrings to time.struct_time
In-Reply-To: <1275680837.43.0.377357755743.issue8899@psf.upfronthosting.co.za>
Message-ID: <1275750810.75.0.240447112795.issue8899@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r81756 (trunk) and r81757 (py3k).

----------
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Jun  5 17:19:26 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 15:19:26 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1275751166.65.0.962653814179.issue7584@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

> According to my reading of RFC 3339, it is not correct to produce 'Z'
> timestamps when local offset is not known.

It is not said that 'Z' SHOULD NOT be produced if local offset is unknown. Even if offset is unknown, UTC still can be the preferred reference point for the specified time.

>From the user point of view the assumption about "know or unknown offset" is beyond the judgement of low-level datetime library. For example, if I read timestamp of a local file, I assume that local offset is unknown and UTC is not preferred, but still do not have other choice than to write zero. It won't help me to find actual offset. For a network file I assume that preferred offset is actually UTC and although I do not have any means to check the offset I can write zero without any hesitation.

Solving philosophical -00:00 +00:00 problems require a deep knowledge of RFC3339. I doubt that pleasing 1% who need this kind of fine-grained semantic control with special API deserves suffering of other 99%. In the end there is nothing hard in replacing 'Z' with a flavor of your choice.

Of course, if smb. want to force developers to overload their brain for the sake of providing the most accurate semantic timestamps (that nobody uses anyway) - then the -00:00/+00:00 stuff is a way to go. But my opinion is that datetime API in Python is already complicated enough to negatively affect this language karma.

----------

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

From report at bugs.python.org  Sat Jun  5 17:35:51 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 15:35:51 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1275752151.85.0.668549487512.issue7584@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

s/datetime/date\/time/ in the last sentence, as the complication comes  from:
-- start offtopic --
1. the vast amount of various date and time modules/functions
2. the little amount of what they can do

I still hardly believe that there is no way to get current TZ offset given that every OS provides such information.
-- end offtopic --

----------

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

From report at bugs.python.org  Sat Jun  5 17:39:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 05 Jun 2010 15:39:09 +0000
Subject: [issue8907] time module documentation differs in trunk and py3k
In-Reply-To: <1275752348.33.0.507552521147.issue8907@psf.upfronthosting.co.za>
Message-ID: <1275752348.33.0.507552521147.issue8907@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Doc/library/time.rst differs in trunk and py3k.  It appears that the trunk version is more up to date and can simply replace the py3k version, but I would like to have another pair of eyes to take a look before committing.

I also noticed that time.asctime signature is displayed as asctime([t]) and as asctime([tuple]) in docstring.  I think docstring variant is better.

----------
assignee: belopolsky
components: Documentation
files: time-doc.diff
keywords: patch
messages: 107141
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: time module documentation differs in trunk and py3k
versions: Python 3.2
Added file: http://bugs.python.org/file17562/time-doc.diff

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

From report at bugs.python.org  Sat Jun  5 17:40:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 05 Jun 2010 15:40:26 +0000
Subject: [issue8907] time module documentation differs in trunk and py3k
In-Reply-To: <1275752348.33.0.507552521147.issue8907@psf.upfronthosting.co.za>
Message-ID: <1275752426.46.0.127864636176.issue8907@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +docs at python

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

From report at bugs.python.org  Sat Jun  5 17:48:31 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 15:48:31 +0000
Subject: [issue7229] [PATCH] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1275752911.34.0.233075830294.issue7229@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

issue8907 seems related.

----------
nosy: +belopolsky, docs at python

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

From report at bugs.python.org  Sat Jun  5 17:52:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 05 Jun 2010 15:52:27 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1275753147.48.0.948944836619.issue7229@psf.upfronthosting.co.za>


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


----------
title: [PATCH] Manual entry for time.daylight can be misleading -> Manual entry for time.daylight can be misleading

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

From report at bugs.python.org  Sat Jun  5 17:58:03 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 15:58:03 +0000
Subject: [issue8151] [patch] convenience links for subprocess.call()
In-Reply-To: <1268692197.73.0.576136858806.issue8151@psf.upfronthosting.co.za>
Message-ID: <1275753483.32.0.176403402181.issue8151@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

easy, just waits to be ported

----------
nosy: +docs at python

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

From report at bugs.python.org  Sat Jun  5 18:00:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 05 Jun 2010 16:00:47 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1275752151.85.0.668549487512.issue7584@psf.upfronthosting.co.za>
Message-ID: <AANLkTilcup2g88NsY1adPJvcRnLyaVv7dA--LcnWBQTO@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Jun 5, 2010 at 11:35 AM, anatoly techtonik
<report at bugs.python.org> wrote:
..
> s/datetime/date\/time/ in the last sentence, as the complication comes ?from:
> -- start offtopic --
> 1. the vast amount of various date and time modules/functions

"Vast" is a bit of overstatement.  It is mostly the datetime and time
module with a little bit in a less used calendar module.   I believe a
stated goal is to gradually remove the need for time module in
date/time manipulation and possibly fold it into posix module.

Can you be more specific?  The biggest omission, IMO, is the lack of
time zone support, but this is being worked on.  See  issue5094.

> I still hardly believe that there is no way to get current TZ offset given that every OS provides such information.

See issue1647654.

----------

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

From report at bugs.python.org  Sat Jun  5 18:04:10 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 16:04:10 +0000
Subject: [issue8519] [patch] doc: termios and ioctl reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1275753850.87.0.931001763365.issue8519@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
nosy: +docs at python

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

From report at bugs.python.org  Sat Jun  5 18:10:23 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 16:10:23 +0000
Subject: [issue1635217] Add example of distutils setup() with "requires"
	argument
Message-ID: <1275754223.84.0.844192580409.issue1635217@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Neal, why a piece from issue1635217#msg31028 doesn't qualify as an example?

It seems that this issue may become obsolete with new packaging guide coming up.

----------
components: +Distutils, Distutils2
nosy: +docs at python
versions: +Python 2.7, Python 3.3 -Python 2.6

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

From report at bugs.python.org  Sat Jun  5 18:15:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 05 Jun 2010 16:15:02 +0000
Subject: [issue8151] [patch] convenience links for subprocess.call()
In-Reply-To: <1268692197.73.0.576136858806.issue8151@psf.upfronthosting.co.za>
Message-ID: <1275754502.34.0.890225290758.issue8151@psf.upfronthosting.co.za>


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

Already done AFAICS.

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

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

From report at bugs.python.org  Sat Jun  5 18:21:55 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 05 Jun 2010 16:21:55 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1275754915.94.0.0954200928714.issue8847@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I've just found that:

    [1] + foo()

crashes, but:

    [1].__add__(foo())

gives:

    Traceback (most recent call last):
      File "<pyshell#25>", line 1, in <module>
        [1].__add__(foo())
    TypeError: can only concatenate list (not "foo") to list

(IDLE on Windows XP)

----------
nosy: +mrabarnett

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

From report at bugs.python.org  Sat Jun  5 18:23:01 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 05 Jun 2010 16:23:01 +0000
Subject: [issue8446] buildbot: DeprecationWarning not raised for icglue
	(test_py3kwarn.TestStdlibRemovals)
In-Reply-To: <1271628757.81.0.455065561336.issue8446@psf.upfronthosting.co.za>
Message-ID: <1275754982.0.0.722769045744.issue8446@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/issue8446>
_______________________________________

From report at bugs.python.org  Sat Jun  5 18:32:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 05 Jun 2010 16:32:20 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1275755540.13.0.788880042553.issue7229@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It may be a bit off-topic for this issue, but I don't like that the python manual uses UTC as if it was a geographical location.  UTC is a time scale.  You cannot be to the east or to the west of UTC just as you cannot be to the north of the Gregorian calendar.

Even if we replace UTC with Prime or Greenwich Meridian, the manual would still be incorrect because some regions in the western hemisphere use positive offsets from UTC.  For example, Madrid is at 3? 42' West, but uses Central European Time which is UTC+1.

Since there are no plans to include any kind of geographical database in  the standard library, I think the manual should avoid use of geographical terms.

What I need to know from the manual is how to get local time from utc and daylight savings time from the standard time.

>From the top of my head, I know that localtime = utctime + utcoffset, but I am not sure whether dsttime = stdtime + dst or dsttime = stdtime - dst and the manual, reworded or not, does not immediately help me.

As for the original issue, do we really need time.daylight at all?  ISTM that in timezones without DST, time.altzone = time.timezone, so the software that unconditionally accounts for DST will still work correctly and software that wants to optimize for no DST case can simply chsck time.altzone == time.timezone.

$ TZ=UTC ./python.exe -c "import time; print(time.daylight, time.tzname, (time.timezone, time.altzone))"
0 ('UTC', 'UTC') (0, 0)

In other words, time.daylight is strictly redundant.

----------

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

From report at bugs.python.org  Sat Jun  5 18:45:01 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 16:45:01 +0000
Subject: [issue8908] friendly errors for UAC errors in windows installers
In-Reply-To: <1275756301.53.0.564921810654.issue8908@psf.upfronthosting.co.za>
Message-ID: <1275756301.53.0.564921810654.issue8908@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

The problem investigated in issue8870 detected that bdist_wininst installers fail in Vista and Windows 7 with enabled UAC (user access control) when run from local drives with non-MS file systems and from network drives.

The error message returned in this case is not explanative at all.
"Failed to start elevated process (ShellExecute returned 5)"

Further investigation revealed that if network samba share requires authentication, and authentication passes, then the installer won't fail. Unfortunately, I can not setup network access to unauthenticated Samba shares right now to test behavior, but I attach installer generated with --user-access-control=force in case somebody can help.

The error message needs to be improved to give users immediate hint what Windows UAC doesn't allow to run privileged executables from non-MS file systems and/or network drives.

----------
assignee: tarek
components: Distutils, Distutils2
files: wget-0.6.win32.force.exe
messages: 107149
nosy: tarek, techtonik
priority: normal
severity: normal
status: open
title: friendly errors for UAC errors in windows installers
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17563/wget-0.6.win32.force.exe

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

From report at bugs.python.org  Sat Jun  5 18:48:19 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 16:48:19 +0000
Subject: [issue8908] friendly errors for UAC errors in windows installers
In-Reply-To: <1275756301.53.0.564921810654.issue8908@psf.upfronthosting.co.za>
Message-ID: <1275756499.61.0.138775979138.issue8908@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

A proper user error message requires investigation of behavior on anonymous samba shares. Attaching patch to install.c with backlinks to relevant ticket descriptions.

----------
keywords: +patch
Added file: http://bugs.python.org/file17564/8908.windows.uac.research.comments.diff

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

From report at bugs.python.org  Sat Jun  5 18:48:57 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 16:48:57 +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: <1275756537.28.0.761548228701.issue8908@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
title: friendly errors for UAC errors in windows installers -> friendly errors for UAC misbehavior in windows installers

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

From report at bugs.python.org  Sat Jun  5 18:58:26 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 16:58:26 +0000
Subject: [issue8871] --user-access-control=auto has no effect
In-Reply-To: <1275420139.65.0.104008426141.issue8871@psf.upfronthosting.co.za>
Message-ID: <1275757106.95.0.622697413181.issue8871@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Can't repeat right now. Please close with issue8870 as a superseder if nothing happens in the next two weeks.

----------

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

From report at bugs.python.org  Sat Jun  5 19:16:29 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 17:16:29 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1275758189.78.0.107051768815.issue7582@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Adding Alexander as ISTM he may be interested to read the time discussion.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Sat Jun  5 19:24:03 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 17:24:03 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1275758643.04.0.779704816395.issue7229@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

It is too hard to track this issue without quotes from manual. Let's bring context into discussion:

http://docs.python.org/library/time.html#time.altzone
  UTC offset of the local DST timezone if one is defined. Only use this if daylight is nonzero.
http://docs.python.org/library/time.html#time.daylight
  Nonzero if a DST timezone is defined.
http://docs.python.org/library/time.html#time.timezone
  UTC offset of the local (non-DST) timezone


So, to answer a question "What is the current UTC offset?" you need to:
if time.daylight:
  if time.altzone: # using only if defined
     use time.altzone
  else:
     use time.timezone
else:
  use time.timezone


1. Is that really works like described above?
2. Should we at least group these timezone variables?


As for offtopic UTC vs GMT - I doubt there is a way to clearly express that the offset sign of the returned values is negated in comparison with real "UTC offsets" without resorting to some king of alternative east/west scale.

----------

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

From report at bugs.python.org  Sat Jun  5 19:28:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 05 Jun 2010 17:28:34 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1275758914.48.0.856487255805.issue7582@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The latest patch will produce wrong results if the file was last modified before timezone rules changed in your location.  See issue1647654.

----------
assignee:  -> belopolsky
dependencies: +No obvious and correct way to get the time zone offset

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

From report at bugs.python.org  Sat Jun  5 19:37:55 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 17:37:55 +0000
Subject: [issue1647654] No obvious and correct way to get the time zone offset
Message-ID: <1275759475.05.0.350965044638.issue1647654@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/issue1647654>
_______________________________________

From report at bugs.python.org  Sat Jun  5 19:43:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 05 Jun 2010 17:43:59 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1275758643.04.0.779704816395.issue7229@psf.upfronthosting.co.za>
Message-ID: <AANLkTinwNcQDui2LLr5rEPpiuIUCmnVP5T1nrxsMdDIC@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Jun 5, 2010 at 1:24 PM, anatoly techtonik
<report at bugs.python.org> wrote:
..
> As for offtopic UTC vs GMT - I doubt there is a way to clearly express that the offset sign of the
> returned values is negated in comparison with real "UTC offsets" without resorting to some
> king of alternative east/west scale.

Sure there is.  Here is how RFC 3339 handles this:

"""
   Numeric offsets are calculated as "local time minus UTC".  So the
   equivalent time in UTC can be determined by subtracting the offset
   from the local time.
"""

and here is a quote from MacOS man page for tzset:

"""
           offset       Indicates the value one must add to the local
time to arrive at Coor-
                        dinated Universal Time.
"""

No geographic reference needed.  (And the issue is not UTC vs. GMT:
both UTC and GMT are timescales, sometimes even considered the same.
The off-topic issue is UTC vs. Prime Meridian.)

----------

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

From report at bugs.python.org  Sat Jun  5 19:48:20 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 17:48:20 +0000
Subject: [issue1667546] Time zone-capable variant of time.localtime
Message-ID: <1275760100.67.0.686660490001.issue1667546@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Yet another timezone issue. =/ Seems like it is too complicated.

Should we try to organize a dedicated sprint during EuroPython?
Do we need some easy to read research on the problem?
Should PSF define bounty for that?

Should we try to approach this with some other entrypoint like high level user story? I can play the role of the dumb user. Please, add your replies to this Wave https://wave.google.com/wave/waveref/googlewave.com/w+FbjMbPbEA so that we can develop the story.

----------
nosy: +techtonik

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

From report at bugs.python.org  Sat Jun  5 20:09:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 05 Jun 2010 18:09:46 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1275758643.04.0.779704816395.issue7229@psf.upfronthosting.co.za>
Message-ID: <AANLkTik9KML7e-WizIazDKO7cSSyXgUa4hQ21MS7VmzU@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Jun 5, 2010 at 1:24 PM, anatoly techtonik
<report at bugs.python.org> wrote:
..
> So, to answer a question "What is the current UTC offset?" you need to:
> if time.daylight:
> ?if time.altzone: # using only if defined
> ? ? use time.altzone
> ?else:
> ? ? use time.timezone
> else:
> ?use time.timezone
>

No, if time.daylight is non-zero, you still need to check the current
value of tm_isdst from localtime().

Here is how bzr reportedly handles this:

def local_time_offset(t=None):
    """Return offset of local zone from GMT, either at present or at time t."""
    # python2.3 localtime() can't take None
    if t is None:
        t = time.time()

    if time.localtime(t).tm_isdst and time.daylight:
        return -time.altzone
    else:
        return -time.timezone

http://blogs.gnome.org/jamesh/2006/12/31/python-timetimezone-timealtzone-edge-case/

> 1. Is that really works like described above?

That works for current time, but subject to race condition twice a
year.  You should get time and dst indormation from the same
localtime() call.  For problems with  arbitrary time t, see the link
above.

> 2. Should we at least group these timezone variables?
>

The come from existing C library practice.  POSIX defines tzname[2],
timezone, and daylight.

http://www.opengroup.org/onlinepubs/009695399/basedefs/time.h.html

altzone is a popular non-standard addition which is strictly
redundant.  Since POSIX does not define anything about daylight
variable other than it has to be zero when DST is not in effect,
compliant implementations can define is so that altzone = timezone -
daylight.

These variables are already grouped in tzinfo API.  What is missing is
method to get concrete tzinfo implementation in stdlib.  See
issue5094.

----------

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

From report at bugs.python.org  Sat Jun  5 20:15:35 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 18:15:35 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1275682160.9.0.0914585409976.issue5094@psf.upfronthosting.co.za>
Message-ID: <AANLkTikn3-4PrHTu8kmQFwlpkPk6FApK-YoDrmT5AL3k@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Fri, Jun 4, 2010 at 11:09 PM, Brett Cannon <report at bugs.python.org> wrote:
> Unless other people step forward to debate this we probably are not going to reach consensus without going to python-dev to see what others think.

I would really like to see:
1. a good definition of the problem
2. summary of research
3. possible solutions

The amount of text generated in bugtracker is already overwhelming for
others to plug in. I remember that my thread about datetime TZ was
also hijacked into the debate that we can not ship 3rd party TZ DB
with Python, so I can't even reference it.

----------

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

From report at bugs.python.org  Sat Jun  5 20:52:10 2010
From: report at bugs.python.org (Paul Boddie)
Date: Sat, 05 Jun 2010 18:52:10 +0000
Subject: [issue1667546] Time zone-capable variant of time.localtime
Message-ID: <1275763930.4.0.836518859289.issue1667546@psf.upfronthosting.co.za>


Paul Boddie <paul at boddie.org.uk> added the comment:

Speaking for myself, I'm not sure whether I'm really the person to push this further, at least, although others may see it as a worthy sprinting topic. In principle, adding the extra fields is the right thing to do, merely because it exposes things from "struct tm" which were missing and which influence the other functions depending on it.

The only things remaining are to make sure that existing code doesn't change its behaviour with these new fields, and that the new fields work together with the time functions as expected. Thus, testing is the most important thing now, I think.

For the bigger picture, which shouldn't be discussed here, Python's way of handling times and dates probably needs improvement - this has been discussed already (a reference for anyone not involved is Anatoly's initial message in one recent discussion: http://mail.python.org/pipermail/python-dev/2010-February/097710.html) - and I think usage of pytz is a step in the right direction, although it does not eliminate the need to learn about time zones (UTC, CET...), time "regimes" (Europe/Oslo, America/New_York...), "floating" times, and zone transitions (and ambiguous times).

Extending Python library support is potentially a sprinting topic, but not really a topic for discussion around this patch.

----------

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

From report at bugs.python.org  Sat Jun  5 20:53:43 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 18:53:43 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <AANLkTilcup2g88NsY1adPJvcRnLyaVv7dA--LcnWBQTO@mail.gmail.com>
Message-ID: <AANLkTim38lvRrJtd0_NVJxNbFeYcTmITItgyABif6Ocy@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Sat, Jun 5, 2010 at 7:00 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
> On Sat, Jun 5, 2010 at 11:35 AM, anatoly techtonik
> <report at bugs.python.org> wrote:
> ..
>> s/datetime/date\/time/ in the last sentence, as the complication comes ?from:
>> -- start offtopic --
>> 1. the vast amount of various date and time modules/functions
>
> "Vast" is a bit of overstatement. ?It is mostly the datetime and time
> module with a little bit in a less used calendar module.

"Concise" Python datetime module API =)
(without any way to get current UTC offset from operating system)
-------------------
datetime.MINYEAR
datetime.MAXYEAR
class datetime.date
class datetime.time
class datetime.datetime
class datetime.timedelta
class datetime.tzinfo
timedelta.min
timedelta.max
timedelta.resolution
classmethod date.today()
classmethod date.fromtimestamp()
classmethod date.fromordinal()
date.min
date.max
date.resolution
date.year
date.month
date.day
date.replace()
date.timetuple()
date.toordinal()
date.weekday()
date.isoweekday()
date.isocalendar()
date.isoformat()
date.__str__()
date.ctime()
date.strftime(format)
classmethod datetime.today()
classmethod datetime.now()
classmethod datetime.utcnow()
classmethod datetime.fromtimestamp()
classmethod datetime.utcfromtimestamp()
classmethod datetime.fromordinal()
classmethod datetime.combine()
classmethod datetime.strptime()
datetime.min
datetime.max
datetime.resolution
datetime.year
datetime.month
datetime.day
datetime.hour
datetime.minute
datetime.second
datetime.microsecond
datetime.tzinfo
datetime.date()
datetime.time()
datetime.timetz()
datetime.replace()
datetime.astimezone()
datetime.utcoffset()
datetime.dst()
datetime.tzname()
datetime.timetuple()
datetime.utctimetuple()
datetime.toordinal()
datetime.weekday()
datetime.isoweekday()
datetime.isocalendar()
datetime.isoformat()
datetime.__str__()
datetime.ctime()
datetime.strftime()
time.min
time.max
time.resolution
time.hour
time.minute
time.second
time.microsecond
time.tzinfo
time.replace()
time.isoformat()
time.__str__()
time.strftime()
time.utcoffset()
time.dst()
time.tzname()
tzinfo.utcoffset()
tzinfo.dst()
tzinfo.tzname()
tzinfo.fromutc()

Raw doc with stripped markup is only 58161 bytes.
Perhaps the biggest problem that you need to read out the doc
thoroughly to understand that all UTC related stuff starts to work
only when somebody writes a tzinfo module. It is like "you are
developer, so its your headache when you get this data - we gave you
The API". =)

> Can you be more specific? ?The biggest omission, IMO, is the lack of
> time zone support, but this is being worked on. ?See ?issue5094.

Great, but it is Python 3.2 and I will be using 2.x Python for the
next two years at least.
It is not an only about omission - it is also about ineffective and
somehow bloated unpythonic C API that is not well suited for everyday
tasks.

>> I still hardly believe that there is no way to get current TZ offset given that every OS provides such information.
>
> See issue1647654.

Too long, and I've a little bit tired, and will be pretty busy next
week, but thanks for the pointers.

----------

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

From report at bugs.python.org  Sat Jun  5 21:42:07 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 19:42:07 +0000
Subject: [issue8870] --user-access-control=force produces invalid installer on
	Vista
In-Reply-To: <1275417481.6.0.247175279763.issue8870@psf.upfronthosting.co.za>
Message-ID: <1275766927.93.0.122107826339.issue8870@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Please add issue8908 as superseder.

----------

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

From report at bugs.python.org  Sat Jun  5 21:45:25 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 05 Jun 2010 19:45:25 +0000
Subject: [issue8302] SkipTest exception in setUpClass or setUpModule is marked
	as an error rather than a skip
In-Reply-To: <1270301652.92.0.301047962487.issue8302@psf.upfronthosting.co.za>
Message-ID: <1275767125.49.0.722439422207.issue8302@psf.upfronthosting.co.za>


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

Committed revision 81760. Needs tests and documentation.

----------

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

From report at bugs.python.org  Sat Jun  5 22:35:41 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 05 Jun 2010 20:35:41 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za>
Message-ID: <1275770141.45.0.1893915343.issue8271@psf.upfronthosting.co.za>


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

Fixed on trunk in r81758 and r81759.
I'm leaving the issue open until I port it on the other versions.

----------

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

From report at bugs.python.org  Sat Jun  5 23:41:21 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 21:41:21 +0000
Subject: [issue8909] mention bitmap size for bdist_wininst
Message-ID: <1275774081.13.0.449044323851.issue8909@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
assignee: tarek
components: Distutils, Documentation
files: mention.bdist.bitmap.size.diff
keywords: patch
nosy: tarek, techtonik
priority: normal
severity: normal
status: open
title: mention bitmap size for bdist_wininst
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file17565/mention.bdist.bitmap.size.diff

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

From report at bugs.python.org  Sat Jun  5 23:41:38 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 21:41:38 +0000
Subject: [issue8909] mention bitmap size for bdist_wininst
Message-ID: <1275774098.87.0.207135822372.issue8909@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
nosy: +docs at python

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

From report at bugs.python.org  Sun Jun  6 00:32:16 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 05 Jun 2010 22:32:16 +0000
Subject: [issue8302] SkipTest exception in setUpClass or setUpModule is marked
	as an error rather than a skip
In-Reply-To: <1270301652.92.0.301047962487.issue8302@psf.upfronthosting.co.za>
Message-ID: <1275777136.03.0.940652525619.issue8302@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jun  6 00:32:31 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 05 Jun 2010 22:32:31 +0000
Subject: [issue8351] Suppress large diffs in
	unitttest.TestCase.assertSequenceEqual()
In-Reply-To: <1270769804.42.0.714910786313.issue8351@psf.upfronthosting.co.za>
Message-ID: <1275777151.85.0.285361432868.issue8351@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jun  6 01:47:33 2010
From: report at bugs.python.org (Henri Salo)
Date: Sat, 05 Jun 2010 23:47:33 +0000
Subject: [issue8890] Modules have dangerous examples in documentation
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275781653.86.0.830705339789.issue8890@psf.upfronthosting.co.za>


Henri Salo <henri at nerv.fi> added the comment:

No it does not.

http://www.owasp.org/index.php/Insecure_Temporary_File

----------

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

From report at bugs.python.org  Sun Jun  6 02:04:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 00:04:32 +0000
Subject: [issue8903] datetime functions
In-Reply-To: <1275720507.31.0.185559003971.issue8903@psf.upfronthosting.co.za>
Message-ID: <1275782672.72.0.0213123294182.issue8903@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

How hard is it to add

now = datetime.now
todate = date.today

at the top of your module is you really like shorter names?

-1

----------
assignee:  -> belopolsky
nosy: +belopolsky
priority: normal -> low

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

From report at bugs.python.org  Sun Jun  6 02:11:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 00:11:40 +0000
Subject: [issue8902] add datetime.time.now() for consistency
In-Reply-To: <1275719789.45.0.168425659941.issue8902@psf.upfronthosting.co.za>
Message-ID: <1275783100.69.0.527677789639.issue8902@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Anatoly,

Didn't you just recently complain about the large number of functions in datetime module? (issue7584)

datetime.datetime.now().time() seems adequate to me.

What is your use case?

----------
assignee:  -> belopolsky
nosy: +belopolsky
priority: normal -> low

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

From report at bugs.python.org  Sun Jun  6 02:22:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 00:22:51 +0000
Subject: [issue1777412] Python's strftime dislikes years before 1900
Message-ID: <1275783771.33.0.451230622221.issue1777412@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I see this in py3k branch on MacOS X:

[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.date(1876, 2, 3).strftime('%Y-%m-%d')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: year=1876 is before 1900; the datetime strftime() methods require year >= 1900


I like the approach taken in the David's patch.  The datetime module should stop piggybacking on the time module.

----------
assignee:  -> belopolsky
nosy: +belopolsky
versions: +Python 3.2

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

From report at bugs.python.org  Sun Jun  6 02:29:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 00:29:20 +0000
Subject: [issue3173] external strftime for Python?
In-Reply-To: <1214189093.82.0.548435251403.issue3173@psf.upfronthosting.co.za>
Message-ID: <1275784160.7.0.813668946889.issue3173@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

What platforms have broken strftime and how badly is it broken there?

Is there a python version somewhere?  PyPy?

----------
assignee:  -> belopolsky
nosy: +belopolsky
type:  -> feature request

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

From report at bugs.python.org  Sun Jun  6 02:53:39 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 06 Jun 2010 00:53:39 +0000
Subject: [issue4015] Make installed scripts executable on windows
In-Reply-To: <1222949528.24.0.767744507339.issue4015@psf.upfronthosting.co.za>
Message-ID: <1275785619.47.0.0426246855804.issue4015@psf.upfronthosting.co.za>


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


----------
title: [patch] make installed scripts executable on windows -> Make installed scripts executable on windows

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

From report at bugs.python.org  Sun Jun  6 03:15:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 01:15:11 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1275786911.49.0.0539493509912.issue6280@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

With recent enhancements to datetime module, timegm has become a 1-liner:

EPOCH = 1970
_EPOCH_DATETIME = datetime.datetime(EPOCH, 1, 1)
_SECOND = datetime.timedelta(seconds=1)

def timegm(tuple):
    """Unrelated but handy function to calculate Unix timestamp from GMT."""
    return (datetime.datetime(*tuple[:6]) - _EPOCH_DATETIME) // _SECOND

I suggest committing modernized implementation to serve as a reference and encourage people to use datetime module and datetime objects instead of time module and time tuples.

----------
assignee:  -> belopolsky
nosy: +belopolsky, mark.dickinson -Alexander.Belopolsky
priority: normal -> low
stage: needs patch -> commit review
Added file: http://bugs.python.org/file17566/issue6280-calendar.diff

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

From report at bugs.python.org  Sun Jun  6 03:25:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 01:25:33 +0000
Subject: [issue1083] Confusing error message when dividing timedelta using /
In-Reply-To: <1188674374.08.0.925919990107.issue1083@psf.upfronthosting.co.za>
Message-ID: <1275787533.24.0.544036332738.issue1083@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Closing as duplicate of issue1289118.  Division of timedelta by integer is supported in py3k since r81625.

----------
nosy: +belopolsky -Alexander.Belopolsky
resolution:  -> duplicate
status: open -> closed
superseder:  -> timedelta multiply and divide by floating point

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

From report at bugs.python.org  Sun Jun  6 03:28:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 01:28:14 +0000
Subject: [issue7463] PyDateTime_IMPORT() causes compiler warnings
In-Reply-To: <1260352911.97.0.550126067946.issue7463@psf.upfronthosting.co.za>
Message-ID: <1275787694.87.0.778407503055.issue7463@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy: +belopolsky
stage:  -> needs patch

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

From report at bugs.python.org  Sun Jun  6 03:35:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 01:35:27 +0000
Subject: [issue7989] Transition time/datetime C modules to Python
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1275788127.21.0.430829926194.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

As far as I remember, the datetime module started as a pure python module and was reimplemented in C around year 2003 or so.  One of the important additions at that time was the C API to datetime functionality.  I am afraid that with the _timemodule.c/timemodule.py split there will be more an more functionality that is awkward to access from C API.

----------
assignee:  -> belopolsky
nosy: +belopolsky

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

From report at bugs.python.org  Sun Jun  6 03:39:21 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Jun 2010 01:39:21 +0000
Subject: [issue8482] test_gdb,
	gdb/libpython.py: Unable to read information on python frame
In-Reply-To: <1271844769.16.0.663071395235.issue8482@psf.upfronthosting.co.za>
Message-ID: <1275788361.15.0.751645567197.issue8482@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/issue8482>
_______________________________________

From report at bugs.python.org  Sun Jun  6 03:40:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 01:40:18 +0000
Subject: [issue1726687] Bug found in datetime for Epoch time = -1
Message-ID: <1275788418.75.0.73591667019.issue1726687@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy: +belopolsky -Alexander.Belopolsky

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

From report at bugs.python.org  Sun Jun  6 03:52:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 01:52:08 +0000
Subject: [issue7662] time.utcoffset()
In-Reply-To: <1263057341.16.0.947515103763.issue7662@psf.upfronthosting.co.za>
Message-ID: <1275789128.08.0.900783293101.issue7662@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I would prefer exposing tm_gmtoff in time.localtime() output. The advantage is that on platforms that support it is struct tm, it will return correct offset for times in the past, not only for the current time. See issue1647654.

On platforms without tm_gmtoff we can fill it with -tm_isdst?timezone:altzone.  The current situation on Linux is just backwards: we are trying to divine altzone by sampling tm_gmtoff and throw tm_gmtoff away.

See http://blogs.gnome.org/jamesh/2006/12/31/python-timetimezone-timealtzone-edge-case/.

----------
assignee:  -> belopolsky
nosy: +belopolsky

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

From report at bugs.python.org  Sun Jun  6 04:07:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 02:07:45 +0000
Subject: [issue5979] strptime() gives inconsistent exceptions
In-Reply-To: <1241896450.71.0.860512052019.issue5979@psf.upfronthosting.co.za>
Message-ID: <1275790065.46.0.980893508963.issue5979@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Looks like a bug to me:

>>> datetime.strptime("1", "%d")
datetime.datetime(1900, 1, 1, 0, 0)

>>> datetime.strptime('1', '%m')
datetime.datetime(1900, 1, 1, 0, 0)

both %m and %d accept single digits but they should not.

>>> datetime.strptime('123', '%m%d')
datetime.datetime(1900, 12, 3, 0, 0)

>>> import this
..
In the face of ambiguity, refuse the temptation to guess.

----------
assignee:  -> belopolsky
nosy: +belopolsky
stage:  -> unit test needed

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

From report at bugs.python.org  Sun Jun  6 04:08:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 02:08:18 +0000
Subject: [issue5979] strptime() gives inconsistent exceptions
In-Reply-To: <1241896450.71.0.860512052019.issue5979@psf.upfronthosting.co.za>
Message-ID: <1275790098.07.0.0926738030019.issue5979@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
versions: +Python 3.2 -Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jun  6 04:13:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 02:13:12 +0000
Subject: [issue1982] Feature: extend strftime to accept milliseconds
In-Reply-To: <1201805956.67.0.436839158391.issue1982@psf.upfronthosting.co.za>
Message-ID: <1275790392.09.0.460446215134.issue1982@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

With %f support in, isn't this issue out of date?

----------
assignee:  -> belopolsky
nosy: +belopolsky
stage:  -> unit test needed
versions: +Python 3.2 -Python 2.6

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

From report at bugs.python.org  Sun Jun  6 04:16:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 02:16:07 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1275790567.94.0.636382442702.issue2516@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file14759/unnamed

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

From report at bugs.python.org  Sun Jun  6 04:20:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 02:20:57 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1275790857.13.0.650515214511.issue2516@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

gungor: your messages look mangled.  It may be the case of email to trucker bug.  Can you briefly explain what you are trying to add to the discussion?

----------
assignee:  -> belopolsky

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

From report at bugs.python.org  Sun Jun  6 05:06:20 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 03:06:20 +0000
Subject: [issue8910] Write a text file explaining why Lib/test/data exists
In-Reply-To: <1275793580.19.0.611567237471.issue8910@psf.upfronthosting.co.za>
Message-ID: <1275793580.19.0.611567237471.issue8910@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The directory is empty by default as that's where some temporary files are put during testing. Should have a text file in there explaining this fact.

----------
components: Tests
keywords: easy
messages: 107176
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Write a text file explaining why Lib/test/data exists

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

From report at bugs.python.org  Sun Jun  6 05:23:26 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 03:23:26 +0000
Subject: [issue8911] regrtest.main should have a test skipping argument
In-Reply-To: <1275794606.83.0.993053669818.issue8911@psf.upfronthosting.co.za>
Message-ID: <1275794606.83.0.993053669818.issue8911@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

If you look at importlib.regrtest you will notice it has to muck with sys.argv in order to get certain tests skipped. It would be much better if regrtest.main had an argument you could specify instead which listed the tests to skip.

This might lead to breaking out the command line parsing into the __main__ block at the end of the file instead of having it all in regrtest.main.

----------
components: Tests
keywords: easy
messages: 107177
nosy: brett.cannon
priority: low
severity: normal
status: open
title: regrtest.main should have a test skipping argument
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun  6 05:24:39 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 03:24:39 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

This would be especially useful now that only spaces are used in .c/.h files and not tabs.

----------
messages: 107178
nosy: brett.cannon
priority: low
severity: normal
status: open
title: `make patchcheck` should check the whitespace of .c/.h files
type: feature request

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

From report at bugs.python.org  Sun Jun  6 05:26:20 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 03:26:20 +0000
Subject: [issue8913] Document that datetime.__format__ is datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Documenting that would help get people using datetime objects with string.format more.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 107179
nosy: brett.cannon, docs at python
priority: low
severity: normal
status: open
title: Document that datetime.__format__ is datetime.strftime
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun  6 05:32:54 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 03:32:54 +0000
Subject: [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Just like I did for Python 2.7.

Should use this issue to keep track of what I have already processed and what I had to skip because OS X doesn't have the right files.

----------
components: Extension Modules, Interpreter Core
messages: 107180
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Run clang's static analyzer
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun  6 05:35:09 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 03:35:09 +0000
Subject: [issue8915] Use locale.nl_langinfo in _strptime
In-Reply-To: <1275795309.62.0.41465361185.issue8915@psf.upfronthosting.co.za>
Message-ID: <1275795309.62.0.41465361185.issue8915@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

It might perform better to use locale.nl_langinfo to get the current locale's datetime information instead of reverse-engineering from strftime (need to benchmark to see if this is true). This would need to be conditional as the datetime info might not be exposed through nl_langinfo.

----------
components: Library (Lib)
messages: 107181
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Use locale.nl_langinfo in _strptime
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun  6 05:39:20 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 03:39:20 +0000
Subject: [issue8916] Move PEP 362 (function signature objects) into inspect
In-Reply-To: <1275795560.39.0.398177747359.issue8916@psf.upfronthosting.co.za>
Message-ID: <1275795560.39.0.398177747359.issue8916@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

To get function signature objects (PEP 362) moving forward I should get it into the inspect module. That way people can start using it more beyond those in PyPI (http://pypi.python.org/pypi/pep362).

Michael Foord has mentioned how IronPython could use function signature objects. This would be a first step in getting the objects standardized enough so that IronPython could eventually consider putting them on all of their objects.

----------
components: Library (Lib)
messages: 107182
nosy: brett.cannon, michael.foord
priority: low
severity: normal
status: open
title: Move PEP 362 (function signature objects) into inspect
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun  6 06:29:09 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 06 Jun 2010 04:29:09 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1275798549.16.0.451716913926.issue7370@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


Removed file: http://bugs.python.org/file16900/BaseHTTPServer.patch

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

From report at bugs.python.org  Sun Jun  6 06:31:18 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 06 Jun 2010 04:31:18 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1275798678.49.0.878162222239.issue7370@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Seems that earlier patch was incorrect. Rectifying and submitting the correct patch.

----------
Added file: http://bugs.python.org/file17567/BaseHTTPServer.patch

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

From report at bugs.python.org  Sun Jun  6 07:56:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 05:56:12 +0000
Subject: [issue8913] Document that datetime.__format__ is datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1275803772.87.0.206539659524.issue8913@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I wonder if this is subject to change.  I find it odd that

>>> "{:g}".format(1e3)
'1000'

but one has to use % in

>>> "{:%Y}".format(datetime.now())
'2010'

It is also different from PEP 3101 recommendation:
"""
    An example is the 'datetime' class,
    whose format specifiers might look something like the
    arguments to the strftime() function:

        "Today is: {0:a b d H:M:S Y}".format(datetime.now())
"""
The above, however, should probably be

"Today is: {0:a} {0:b} {0:d} {0:H}:{0:M}:{0:S} {0:Y}".format(datetime.now())

----------
nosy: +belopolsky

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

From report at bugs.python.org  Sun Jun  6 08:12:42 2010
From: report at bugs.python.org (Tal Einat)
Date: Sun, 06 Jun 2010 06:12:42 +0000
Subject: [issue8641] IDLE 3 doesn't highlights b"", but u""
In-Reply-To: <1273212994.94.0.428777321336.issue8641@psf.upfronthosting.co.za>
Message-ID: <1275804762.57.0.426792371467.issue8641@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

Attaching patch against current py3k branch.

I simply replaced the occurrences of [rRuU] in the relevant regexps to [rRbB].

----------
keywords: +patch
nosy: +taleinat
Added file: http://bugs.python.org/file17568/IDLE_py3k_string_highlighting.diff

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

From report at bugs.python.org  Sun Jun  6 08:25:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 06:25:21 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275805521.24.0.385073770988.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching the next version of my patch and changing priority to high because it appears that several issues depend on resolution of this one.

Here is the summary of changes since issue5094a.diff:

1. The constructor now accepts only whole number of minutes in [-23:59, 23:59] range.

2. Removed tz_aware option to utcnow().

3. Moved struct PyDateTime_TimeZone definition to .c file. This effectively makes the actual definition private so that it can be changed in the future if desired without breaking C API.

4. Removed checks that the argument passed to tzinfo methods is a timedelta.  The tzinfo spec requires that None is accepted.  Since the argument is ignored, it is wasteful to check its type.

5. Make dst() return None as recommended by tzinfo documentation when DST information is not provided.

Brett, is this close to a compromise that we can agree to or is it time to start writing a PEP? :-)

PS: The latest patch does not include doc changes.

----------
priority: low -> high
Added file: http://bugs.python.org/file17569/issue5094b.diff

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

From report at bugs.python.org  Sun Jun  6 08:25:34 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Jun 2010 06:25:34 +0000
Subject: [issue7166] IDLE (python 3.1.1) syntax coloring for b'bytestring' and
	u'unicode' string literal
In-Reply-To: <1255894468.82.0.699463762919.issue7166@psf.upfronthosting.co.za>
Message-ID: <1275805534.68.0.197758894874.issue7166@psf.upfronthosting.co.za>


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

Duplicate of #8641.

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

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

From report at bugs.python.org  Sun Jun  6 08:25:41 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Jun 2010 06:25:41 +0000
Subject: [issue8641] IDLE 3 doesn't highlights b"", but u""
In-Reply-To: <1273212994.94.0.428777321336.issue8641@psf.upfronthosting.co.za>
Message-ID: <1275805541.37.0.718916824208.issue8641@psf.upfronthosting.co.za>


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

See also #7166.

----------
nosy: +ezio.melotti, lieryan

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

From report at bugs.python.org  Sun Jun  6 08:54:47 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 06 Jun 2010 06:54:47 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275807287.52.0.356996922752.issue5094@psf.upfronthosting.co.za>


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

Isn't it possible, that in the issue5094b.diff patch, in the new_timezone_ex function, in this part:

self = (PyDateTime_TimeZone *)type->tp_alloc(type, 0);
if (self == NULL)
    return NULL;

should be a Py_DECREF(offset) call?

I mean like:

self = (PyDateTime_TimeZone *)type->tp_alloc(type, 0);
if (self == NULL) {
    Py_DECREF(offset);
    return NULL;
}

I think the refcount of offset has always been incremented, so in case of an error, it should be decremented (as in the other error handling parts of the function).

----------

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

From report at bugs.python.org  Sun Jun  6 09:02:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 07:02:59 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275807779.1.0.566530388399.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Good catch, Daniel!

Fixed in issue5094c.diff.

----------
Added file: http://bugs.python.org/file17570/issue5094c.diff

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

From report at bugs.python.org  Sun Jun  6 09:17:04 2010
From: report at bugs.python.org (Tal Einat)
Date: Sun, 06 Jun 2010 07:17:04 +0000
Subject: [issue7166] IDLE (python 3.1.1) syntax coloring for b'bytestring' and
	u'unicode' string literal
In-Reply-To: <1255894468.82.0.699463762919.issue7166@psf.upfronthosting.co.za>
Message-ID: <1275808624.54.0.0745713369408.issue7166@psf.upfronthosting.co.za>


Changes by Tal Einat <taleinat at users.sourceforge.net>:


----------
nosy: +taleinat

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

From report at bugs.python.org  Sun Jun  6 10:00:14 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 06 Jun 2010 08:00:14 +0000
Subject: [issue8916] Move PEP 362 (function signature objects) into inspect
In-Reply-To: <1275795560.39.0.398177747359.issue8916@psf.upfronthosting.co.za>
Message-ID: <1275811214.83.0.514819474427.issue8916@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/issue8916>
_______________________________________

From report at bugs.python.org  Sun Jun  6 10:19:05 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 06 Jun 2010 08:19:05 +0000
Subject: [issue8902] add datetime.time.now() for consistency
In-Reply-To: <1275719789.45.0.168425659941.issue8902@psf.upfronthosting.co.za>
Message-ID: <1275812345.07.0.241565129764.issue8902@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

> What is your use case?

>>> from datetime import now, today
>>> now()
datetime.time ...
>>> today()
datetime.date ...

----------

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

From report at bugs.python.org  Sun Jun  6 10:21:38 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 06 Jun 2010 08:21:38 +0000
Subject: [issue8902] add datetime.time.now() for consistency
In-Reply-To: <1275719789.45.0.168425659941.issue8902@psf.upfronthosting.co.za>
Message-ID: <1275812498.32.0.220768576294.issue8902@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

> Didn't you just recently complain about the large number of functions in datetime module?

About verbosity of datetime API to be exact, so it is a ratio of (API functions + required docs)/user code that makes required stuff done.

----------

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

From report at bugs.python.org  Sun Jun  6 11:03:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jun 2010 09:03:29 +0000
Subject: [issue8850] Remove "w" format of PyParse_ParseTuple()
In-Reply-To: <1275099860.74.0.46695580149.issue8850@psf.upfronthosting.co.za>
Message-ID: <1275815009.51.0.152442121583.issue8850@psf.upfronthosting.co.za>


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

Attached patch removes "w" format, cleanups the code for "w*" and "w#" formats, and update the documentation.

----------
keywords: +patch
Added file: http://bugs.python.org/file17571/remove_w_format.patch

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

From report at bugs.python.org  Sun Jun  6 16:47:43 2010
From: report at bugs.python.org (tanaga)
Date: Sun, 06 Jun 2010 14:47:43 +0000
Subject: [issue8917] Segmentation error happens in Embedding Python.
In-Reply-To: <1275835663.33.0.520214000656.issue8917@psf.upfronthosting.co.za>
Message-ID: <1275835663.33.0.520214000656.issue8917@psf.upfronthosting.co.za>


New submission from tanaga <muranaga9 at gmail.com>:

A segmentation error happens in Embedding Python.

condition
    When I called four times of Py_Main in one process.
    and When I used ctypes in the script.

A happening
    segmentation error(core dumped)



[user at localhost debug]$ 
[user at localhost debug]$ ls -l
total 24
-rwxrwxrwx 1 user user 333 May 30 03:17 build.sh
-rwxrwxrwx 1 user user 385 Jun  6 23:27 ctypes_segmfault.c
-rwxrwxrwx 1 user user  14 Jun  6 23:25 import_ctypes.py
[user at localhost debug]$ 
[user at localhost debug]$ 
[user at localhost debug]$ ./build.sh 
/usr/local/lib/libpython2.6.a(posixmodule.o): In function `posix_tmpnam':
/work/Python-2.6.5/./Modules/posixmodule.c:7207: warning: the use of `tmpnam_r' is dangerous, better use `mkstemp'
/usr/local/lib/libpython2.6.a(posixmodule.o): In function `posix_tempnam':
/work/Python-2.6.5/./Modules/posixmodule.c:7162: warning: the use of `tempnam' is dangerous, better use `mkstemp'
[user at localhost debug]$ 
[user at localhost debug]$ 
[user at localhost debug]$ ls -l             
total 4212
-rwxrwxrwx 1 user user     333 May 30 03:17 build.sh
-rwxrwxr-x 1 user user 4256056 Jun  6 23:30 ctypes_segmfault
-rwxrwxrwx 1 user user     385 Jun  6 23:27 ctypes_segmfault.c
-rw-rw-r-- 1 user user    4664 Jun  6 23:30 ctypes_segmfault.o
-rwxrwxrwx 1 user user      14 Jun  6 23:25 import_ctypes.py
[user at localhost debug]$ 
[user at localhost debug]$ 
[user at localhost debug]$ ./ctypes_segmfault
----- 0 -----
----- 1 -----
----- 2 -----
----- 3 -----
Segmentation fault (core dumped)
[user at localhost debug]$ 
[user at localhost debug]$ 
[user at localhost debug]$ ls -l
total 5960
-rwxrwxrwx 1 user user     333 May 30 03:17 build.sh
-rw------- 1 user user 1933312 Jun  6 23:31 core.2981
-rwxrwxr-x 1 user user 4256056 Jun  6 23:30 ctypes_segmfault
-rwxrwxrwx 1 user user     385 Jun  6 23:27 ctypes_segmfault.c
-rw-rw-r-- 1 user user    4664 Jun  6 23:30 ctypes_segmfault.o
-rwxrwxrwx 1 user user      14 Jun  6 23:25 import_ctypes.py
[user at localhost debug]$ 


so I watched core with gdb.


[user at localhost debug]$ gdb ctypes_segmfault core.2981 
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5_5.1)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/user/debug/ctypes_segmfault...done.

warning: core file may not match specified executable file.
Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libutil.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libutil.so.1
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/local/lib/python2.6/lib-dynload/_ctypes.so...done.
Loaded symbols for /usr/local/lib/python2.6/lib-dynload/_ctypes.so
Reading symbols from /usr/local/lib/python2.6/lib-dynload/_struct.so...done.
Loaded symbols for /usr/local/lib/python2.6/lib-dynload/_struct.so
Core was generated by `./ctypes_segmfault'.
Program terminated with signal 11, Segmentation fault.
#0  0x080a103a in type_dealloc (type=0x9f3180) at Objects/typeobject.c:2610
2610            _PyObject_GC_UNTRACK(type);
(gdb) bt
#0  0x080a103a in type_dealloc (type=0x9f3180) at Objects/typeobject.c:2610
#1  0x080888ef in dict_dealloc (mp=0xb7ef313c) at Objects/dictobject.c:911
#2  0x080888ef in dict_dealloc (mp=0xb7f4c02c) at Objects/dictobject.c:911
#3  0x080e7599 in _PyImport_Fini () at Python/import.c:240
#4  0x080f47cc in Py_Finalize () at Python/pythonrun.c:460
#5  0x08058183 in Py_Main (argc=1, argv=0xbfe5c6c8) at Modules/main.c:596
#6  0x080579d3 in main () at ./ctypes_segmfault.c:16
(gdb) quit
[user at localhost debug]$ 

fumm... I don't know about inside of Python Interpreter.



[user at localhost debug]$ cat ctypes_segmfault.c
#include <stdio.h>
#include <Python.h>

/* ulimit -c unlimited */

int main(void) {
  char *argpy[] = { "python", "import_ctypes.py" };
  
  printf("----- 0 -----\n");
  Py_Main(2, argpy);
  printf("----- 1 -----\n");
  Py_Main(2, argpy);
  printf("----- 2 -----\n");
  Py_Main(2, argpy);
  printf("----- 3 -----\n");
  Py_Main(2, argpy);
  printf("----- 4 -----\n");
  
  return 0;
}
[user at localhost debug]$ 
[user at localhost debug]$ cat build.sh 
#!/bin/sh

gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 \
    -Wall -Wstrict-prototypes -I/usr/local/include/python2.6/ \
    -DPy_BUILD_CORE -o ctypes_segmfault.o ./ctypes_segmfault.c

gcc -pthread  -Xlinker -export-dynamic -o ctypes_segmfault \
    ctypes_segmfault.o \
    -lpython2.6 -lpthread -ldl  -lutil   -lm
[user at localhost debug]$ 
[user at localhost debug]$ cat import_ctypes.py 
import ctypes
[user at localhost debug]$

----------
assignee: theller
components: Interpreter Core, ctypes
files: ctypes_segmfault.c
messages: 107194
nosy: tanaga, theller
priority: normal
severity: normal
status: open
title: Segmentation error happens in Embedding Python.
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file17572/ctypes_segmfault.c

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

From report at bugs.python.org  Sun Jun  6 17:32:04 2010
From: report at bugs.python.org (lesmana)
Date: Sun, 06 Jun 2010 15:32:04 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1275838324.6.0.142156936693.issue5845@psf.upfronthosting.co.za>


Changes by lesmana <lesmana at gmx.de>:


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

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

From report at bugs.python.org  Sun Jun  6 17:32:39 2010
From: report at bugs.python.org (lesmana)
Date: Sun, 06 Jun 2010 15:32:39 +0000
Subject: [issue7898] rlcompleter add "real tab" when text is empty feature
In-Reply-To: <1265789959.13.0.400404108309.issue7898@psf.upfronthosting.co.za>
Message-ID: <1275838359.27.0.734772635334.issue7898@psf.upfronthosting.co.za>


Changes by lesmana <lesmana at gmx.de>:


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

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

From report at bugs.python.org  Sun Jun  6 18:51:02 2010
From: report at bugs.python.org (tanaga)
Date: Sun, 06 Jun 2010 16:51:02 +0000
Subject: [issue8917] Segmentation error happens in Embedding Python.
In-Reply-To: <1275835663.33.0.520214000656.issue8917@psf.upfronthosting.co.za>
Message-ID: <1275843062.39.0.102402672658.issue8917@psf.upfronthosting.co.za>


tanaga <muranaga9 at gmail.com> added the comment:

I used Python 2.6.5 on CentOS 5.5.

[root at localhost ~]# uname -a
Linux localhost.localdomain 2.6.18-194.3.1.el5 #1 SMP Thu May 13 13:09:10 EDT 2010 i686 i686 i386 GNU/Linux

[root at localhost ~]# python
Python 2.6.5 (r265:79063, May 30 2010, 03:05:19) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

----------

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

From report at bugs.python.org  Sun Jun  6 19:51:00 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sun, 06 Jun 2010 17:51:00 +0000
Subject: [issue8918] distutils test failure on solaris: IOError: [Errno 2] No
	such file or directory: '_configtest.i'
In-Reply-To: <1275846660.59.0.731483262347.issue8918@psf.upfronthosting.co.za>
Message-ID: <1275846660.59.0.731483262347.issue8918@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

OS = SunOS ginsu 5.10 Generic_125101-10 i86pc i386 i86pc
Python 2.7rc1

======================================================================
ERROR: test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/apy/rrun/tmp/autotest/apy/lib/python2.7/distutils/tests/test_config_cmd.py", line 46
, in test_search_cpp
    match = cmd.search_cpp(pattern='xxx', body='// xxx')
  File "/export/home/apy/rrun/tmp/autotest/apy/lib/python2.7/distutils/command/config.py", line 211, in search_cpp
    file = open(out)
IOError: [Errno 2] No such file or directory: '_configtest.i'

----------
assignee: tarek
components: Distutils, Tests
messages: 107196
nosy: srid, tarek
priority: normal
severity: normal
status: open
title: distutils test failure on solaris: IOError: [Errno 2] No such file or directory: '_configtest.i'
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jun  6 19:56:24 2010
From: report at bugs.python.org (lesmana)
Date: Sun, 06 Jun 2010 17:56:24 +0000
Subject: [issue8919] python should read ~/.pythonrc.py by default
In-Reply-To: <1275846984.04.0.731293977336.issue8919@psf.upfronthosting.co.za>
Message-ID: <1275846984.04.0.731293977336.issue8919@psf.upfronthosting.co.za>


New submission from lesmana <lesmana at gmx.de>:

if started as an interactive session python should check for and read ~/.pythonrc.py by default.

furthermore there should be two options added:
--rcfile filename
this will read filename instead of ~/.pythonrc
--norc
this will prevent reading ~/.pythonrc

(this is inspired by how bash handles initialization)

afterwards the variable PYTHONSTARTUP can be deprecated.

as far as i know, everything which can be done by the variable PYTHONSTARTUP can be done with the suggested method. the advantage of the suggested method is that it is "intuitive" in the sense that it is the way most other tools do it (bash for example).

----------
messages: 107197
nosy: lesmana
priority: normal
severity: normal
status: open
title: python should read ~/.pythonrc.py by default
type: feature request

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

From report at bugs.python.org  Sun Jun  6 20:02:45 2010
From: report at bugs.python.org (lesmana)
Date: Sun, 06 Jun 2010 18:02:45 +0000
Subject: [issue8920] PYTHONSTARTUP should expand "~"
In-Reply-To: <1275847365.81.0.275671627787.issue8920@psf.upfronthosting.co.za>
Message-ID: <1275847365.81.0.275671627787.issue8920@psf.upfronthosting.co.za>


New submission from lesmana <lesmana at gmx.de>:

for example, this should be legal:
PYTHONSTARTUP="~/.pythonrc.py"

workaround (in bash)
PYTHONSTARTUP=$(echo ~)"/.pythonrc.py"

----------
messages: 107198
nosy: lesmana
priority: normal
severity: normal
status: open
title: PYTHONSTARTUP should expand "~"
type: feature request

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

From report at bugs.python.org  Sun Jun  6 20:02:53 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sun, 06 Jun 2010 18:02:53 +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: <1275847373.81.0.425210704121.issue8921@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Several test_ttk failures on OSX 10.4 (w/ Tcl/Tk 8.5 installed in /Library/Frameworks) and Python 2.7rc1

======================================================================
ERROR: test_tab_identifiers (test_ttk.test_widgets.NotebookTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/test/test_ttk/test_widgets
.py", line 560, in test_tab_identifiers
    self.assertEqual(self.nb.tab('@5,5'), self.nb.tab('current'))
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/ttk.py", line 922, in tab
    return _val_or_dict(kw, self.tk.call, self._w, "tab", tab_id)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/ttk.py", line 318, in _val
_or_dict
    res = func(*(args + options))
TclError: tab '@5,5' not found

======================================================================
FAIL: test_identify (test_ttk.test_widgets.WidgetTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/test/test_ttk/test_widgets
.py", line 27, in test_identify
    self.assertEqual(self.widget.identify(5, 5), "label")
AssertionError: 'Button.button' != 'label'

======================================================================
FAIL: test_traversal (test_ttk.test_widgets.NotebookTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/test/test_ttk/test_widgets
.py", line 721, in test_traversal
    self.assertEqual(self.nb.select(), str(self.child1))
AssertionError: '.73168616' != '.73169536'

----------------------------------------------------------------------

----------
assignee: ronaldoussoren
components: Macintosh, Tests, Tkinter
messages: 107199
nosy: ronaldoussoren, srid
priority: normal
severity: normal
status: open
title: 2.7rc1: test_ttk failures on OSX 10.4
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jun  6 20:03:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 18:03:33 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1275847413.34.0.971453931467.issue7370@psf.upfronthosting.co.za>


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

You could get a minor speedup by doing ?from email.utils import formatdate?.

Do we have tests know to check that the patch does not break anything?

Can this still go into 2.7?

----------

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

From report at bugs.python.org  Sun Jun  6 20:04:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 18:04:09 +0000
Subject: [issue7463] PyDateTime_IMPORT() causes compiler warnings
In-Reply-To: <1260352911.97.0.550126067946.issue7463@psf.upfronthosting.co.za>
Message-ID: <1275847449.76.0.178808281575.issue7463@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

PyCObject is deprecated in 2.7 and removed in 3.x.  PyCapsule_Import() should be used instead of PyCObject_Import() and it already has correct signature:

Include/pycapsule.h:PyAPI_FUNC(void *) PyCapsule_Import(const char *name, int no_block);

Since this is not a bug, I don't think it is appropriate to change it in 2.x.

----------
resolution:  -> out of date
stage: needs patch -> committed/rejected
status: open -> pending

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

From report at bugs.python.org  Sun Jun  6 20:15:20 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 06 Jun 2010 18:15:20 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1275848120.44.0.785575584663.issue7370@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


Removed file: http://bugs.python.org/file17567/BaseHTTPServer.patch

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

From report at bugs.python.org  Sun Jun  6 20:20:36 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 06 Jun 2010 18:20:36 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1275848436.21.0.784970622093.issue7370@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

> You could get a minor speedup by doing ?from email.utils import formatdate?.

I guess I shall do that. 
Applied the patch and tested it, it does not break anything IMO and should go in python2.7

----------
Added file: http://bugs.python.org/file17573/BaseHTTPServer.patch

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

From report at bugs.python.org  Sun Jun  6 20:23:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jun 2010 18:23:58 +0000
Subject: [issue8922] Improve encoding shortcuts in PyUnicode_AsEncodedString()
In-Reply-To: <1275848637.97.0.606582513318.issue8922@psf.upfronthosting.co.za>
Message-ID: <1275848637.97.0.606582513318.issue8922@psf.upfronthosting.co.za>


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

PyUnicode_Decode() and PyUnicode_AsEncodedString() calls directly builtin decoders/encoders for some known encodings (eg. "utf-8"), instead of using the slow path (call PyCodec_Decode() / PyCodec_Encode()). 

PyUnicode_Decode() does normalize the encoding name: convert to lower and replace "_" by "-", as normalizestring() does. But PyUnicode_AsEncodedString() doesn't normalize the encoding name, it just use strcmp(). PyUnicode_Decode() has a shortcut for ISO-8859-1, whereas PyUnicode_AsEncodedString() doesn't (only for "latin-1").

Attached patch creates a subfunction (static) normalize_encoding(), use it in PyUnicode_Decode() and PyUnicode_AsEncodedString(), and adds a shortcut for ISO-8859-1 to PyUnicode_AsEncodedString().

----------
components: Unicode
files: unicode_shortcuts.patch
keywords: patch
messages: 107203
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: Improve encoding shortcuts in PyUnicode_AsEncodedString()
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file17574/unicode_shortcuts.patch

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

From report at bugs.python.org  Sun Jun  6 20:28:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jun 2010 18:28:41 +0000
Subject: [issue8923] Remove unused "errors" argument from
	_PyUnicode_AsDefaultEncodedString()
In-Reply-To: <1275848921.87.0.52681950966.issue8923@psf.upfronthosting.co.za>
Message-ID: <1275848921.87.0.52681950966.issue8923@psf.upfronthosting.co.za>


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

_PyUnicode_AsDefaultEncodedString() has two arguments: unicode (input string) and errors. If errors is not NULL, it calls Py_FatalError()!

The argument is useful: all functions call it with errors=NULL.

Attached patch removes the argument.

----------
components: Unicode
files: unicode_errors.patch
keywords: patch
messages: 107204
nosy: haypo
priority: normal
severity: normal
status: open
title: Remove unused "errors" argument from _PyUnicode_AsDefaultEncodedString()
versions: Python 3.2
Added file: http://bugs.python.org/file17575/unicode_errors.patch

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

From report at bugs.python.org  Sun Jun  6 20:40:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 18:40:06 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1275849606.19.0.881475538624.issue7370@psf.upfronthosting.co.za>


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

Opinions are nice, tests are better! :)

----------

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

From report at bugs.python.org  Sun Jun  6 20:49:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jun 2010 18:49:48 +0000
Subject: [issue4769] b64decode should accept strings or bytes
In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za>
Message-ID: <1275850188.17.0.472494030379.issue4769@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file17441/base64_main.patch

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

From report at bugs.python.org  Sun Jun  6 20:52:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jun 2010 18:52:18 +0000
Subject: [issue8848] Deprecate or remove "U" and "U#" formats of
	Py_BuildValue()
In-Reply-To: <1275097128.66.0.216673219733.issue8848@psf.upfronthosting.co.za>
Message-ID: <1275850338.38.0.224274252126.issue8848@psf.upfronthosting.co.za>


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

> IMHO removing 'U' should only be done once Py2 is dead.

What do you mean by "once Py2 is dead"? Can I apply the patch in Python 3.2 now?

----------

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

From report at bugs.python.org  Sun Jun  6 20:52:55 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 06 Jun 2010 18:52:55 +0000
Subject: [issue8920] PYTHONSTARTUP should expand "~"
In-Reply-To: <1275847365.81.0.275671627787.issue8920@psf.upfronthosting.co.za>
Message-ID: <1275850375.48.0.436243674048.issue8920@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Here it works with :
PYTHONSTARTUP="$HOME/.pythonrc" ./python

----------
components: +Interpreter Core
nosy: +flox
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> pending
versions: +Python 2.7

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

From report at bugs.python.org  Sun Jun  6 20:53:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jun 2010 18:53:58 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275850438.74.0.0647348369797.issue5094@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/issue5094>
_______________________________________

From report at bugs.python.org  Sun Jun  6 21:01:52 2010
From: report at bugs.python.org (Peter Landgren)
Date: Sun, 06 Jun 2010 19:01:52 +0000
Subject: [issue8924] Error in error message in logging
In-Reply-To: <1275850912.41.0.0811394159532.issue8924@psf.upfronthosting.co.za>
Message-ID: <1275850912.41.0.0811394159532.issue8924@psf.upfronthosting.co.za>


New submission from Peter Landgren <peter.talken at telia.com>:

This is in Windows.
I got an error message in Logging in my application Gramps.
However, there is an error message generated by by this logging, so the original message is never output.
The last line indicate a problem with bytes in certain positions. I was able to check it and it is the Swedish character "?".

The logging call is:
...
    except (IOError, OSError), msg:
        msg = unicode(str(msg), sys.getfilesystemencoding())
        LOG.error(_("Could not make database directory: ") + msg)
which results in:
3165: ERROR: clidbman.py: line 335: Kunde inte skapa databasmappen: [Error 3] Det g??r inte att hitta s??kv??ge
n: u'F:\\'

Traceback (most recent call last):
  File "C:\Python26\lib\logging\__init__.py", line 769, in emit
    msg = self.format(record)
  File "C:\Python26\lib\logging\__init__.py", line 649, in format
    return fmt.format(record)
  File "C:\Python26\lib\logging\__init__.py", line 448, in format
    s = s + record.exc_text
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 608-610: invalid data
4893: ERROR: gramps.py: line 138: Unhandled exception
Traceback (most recent call last):
  File "C:\Program Files (x86)\gramps\gui\grampsgui.py", line 353, in __startgramps
    "Error details: %s %s" % (repr(e), fn), exc_info=True)
  File "C:\Python26\lib\logging\__init__.py", line 1075, in error
    self._log(ERROR, msg, args, **kwargs)
  File "C:\Python26\lib\logging\__init__.py", line 1166, in _log
    self.handle(record)
  File "C:\Python26\lib\logging\__init__.py", line 1176, in handle
    self.callHandlers(record)
  File "C:\Python26\lib\logging\__init__.py", line 1213, in callHandlers
    hdlr.handle(record)
  File "C:\Python26\lib\logging\__init__.py", line 674, in handle
    self.emit(record)
  File "C:\Program Files (x86)\gramps\GrampsLogger\_GtkHandler.py", line 26, in emit
    ErrorView(error_detail=self,rotate_handler=self._rotate_handler)
  File "C:\Program Files (x86)\gramps\GrampsLogger\_ErrorView.py", line 39, in __init__
    self.draw_window()
  File "C:\Program Files (x86)\gramps\GrampsLogger\_ErrorView.py", line 94, in draw_window
    tb_label.get_buffer().set_text(self._error_detail.get_formatted_log())
  File "C:\Program Files (x86)\gramps\GrampsLogger\_GtkHandler.py", line 29, in get_formatted_log
    return self.format(self._record)
  File "C:\Python26\lib\logging\__init__.py", line 649, in format
    return fmt.format(record)
  File "C:\Python26\lib\logging\__init__.py", line 448, in format
    s = s + record.exc_text
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 608-610: invalid data

If I change line 448 in "C:\Python26\lib\logging\__init__.py" to:
    s = s + unicode(str(record.exc_text), sys.getfilesystemencoding())

I get the correct message:
4523: ERROR: grampsgui.py: line 353: Gramps terminated because of OS Error
Error details: WindowsError(3, 'Det g\xe5r inte att hitta s\xf6kv\xe4gen') F:\grdbtest\*.*
Traceback (most recent call last):
  File "C:\Program Files (x86)\gramps\gui\grampsgui.py", line 337, in __startgramps
    Gramps(argparser)
  File "C:\Program Files (x86)\gramps\gui\grampsgui.py", line 268, in __init__
    gui=True)
  File "C:\Program Files (x86)\gramps\cli\arghandler.py", line 81, in __init__
    self.dbman = CLIDbManager(self.dbstate)
  File "C:\Program Files (x86)\gramps\cli\clidbman.py", line 100, in __init__
    self._populate_cli()
  File "C:\Program Files (x86)\gramps\cli\clidbman.py", line 175, in _populate_cli
    for dpath in os.listdir(dbdir):
WindowsError: [Error 3] Det g??r inte att hitta s??kv??gen: u'F:\\grdbtest\\*.*'

(There is a secondary problem with rendering some characers. All strings were generated on a Windows system,
but I report using a Linux system.)

----------
components: Library (Lib)
messages: 107208
nosy: PeterL
priority: normal
severity: normal
status: open
title: Error in error message in logging
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Jun  6 21:03:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jun 2010 19:03:55 +0000
Subject: [issue8925] Improve c-api/arg.rst: use "bytes" or "str" types instead
	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>


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

http://docs.python.org/py3k/c-api/arg.html is unclear about what is a "string".

Attached patch:
 - Use directly bytes, bytearray and str types
 - Replace "default encoding" by "``'utf-8'`` encoding"
 - Add bytes and/or bytearray to "... buffer compatible object" because it's not easy to understand what is a buffer compatible object, especially because there are different kind of buffer objects: read-only, read-write, pinned, etc.
 - Fix reST syntax ("..note ::")
 - Fix "es", "es#", "et" and "et#" formats: they doesn't accept "character buffer compatible object" (can someone double check that?)

Py_BuildValue(): I choosed to mark U and U# formats as deprecated alias to s/s# => see issue #8848.

I wrote the patch by reading getargs.c.

----------
assignee: docs at python
components: Documentation, Unicode
files: arg.patch
keywords: patch
messages: 107209
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: Improve c-api/arg.rst: use "bytes" or "str" types instead of "string"
versions: Python 3.2
Added file: http://bugs.python.org/file17576/arg.patch

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

From report at bugs.python.org  Sun Jun  6 21:11:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jun 2010 19:11:10 +0000
Subject: [issue8926] getargs.c: release the buffer on error
In-Reply-To: <1275851470.16.0.472008534505.issue8926@psf.upfronthosting.co.za>
Message-ID: <1275851470.16.0.472008534505.issue8926@psf.upfronthosting.co.za>


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

PyArg_ParseTuple("t") calls PyObject_GetBuffer() and then raise an error if arg->ob_type->tp_as_buffer->bf_releasebuffer is not NULL. I think that it should call PyBuffer_Release(&view) before raising the error, or simply check bf_releasebuffer before calling PyObject_GetBuffer().

getbuffer() calls PyObject_GetBuffer() and then raise an error if the buffer is not contiguous. I think that it should call PyBuffer_Release() before the error.

Attached patch fixes both errors.

Tell me if I'm wrong :-)

----------
components: Interpreter Core
files: getarg_release.patch
keywords: patch
messages: 107210
nosy: haypo
priority: normal
severity: normal
status: open
title: getargs.c: release the buffer on error
versions: Python 3.2
Added file: http://bugs.python.org/file17577/getarg_release.patch

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

From report at bugs.python.org  Sun Jun  6 21:15:20 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 19:15:20 +0000
Subject: [issue8913] Document that datetime.__format__ is datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1275851720.56.0.383189869494.issue8913@psf.upfronthosting.co.za>


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

I don't find it odd at all that you use datetime-specific formats instead of integral formats to get numbers out of a datetime object; they are totally different things. And one of the reasons for __format__ support is to have DSLs such as the one for datetime objects.

As for pulling out individual objects, that just looks ugly, so I wouldn't advocate pulling out individual values and then formatting them individually in the string itself.

----------

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

From report at bugs.python.org  Sun Jun  6 21:32:00 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 19:32:00 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275852720.21.0.627523212652.issue5094@psf.upfronthosting.co.za>


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

Put yourself down as the maintainer of datetime in Misc/maintainers.rst and you have a deal, Alexander! =)

----------

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

From report at bugs.python.org  Sun Jun  6 21:37:28 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 06 Jun 2010 19:37:28 +0000
Subject: [issue600952] Installing w/o admin generates key error
Message-ID: <1275853048.28.0.762742337864.issue600952@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Seems like it still the issue for 2.4.4

http://scons.tigris.org/issues/show_bug.cgi?id=2533
http://trac.edgewall.org/ticket/9404#comment:2

----------
nosy: +tarek, techtonik

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

From report at bugs.python.org  Sun Jun  6 21:37:40 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Sun, 06 Jun 2010 19:37:40 +0000
Subject: [issue8927] Cannot handle complex requirement resolution
In-Reply-To: <1275853060.23.0.0333552205181.issue8927@psf.upfronthosting.co.za>
Message-ID: <1275853060.23.0.0333552205181.issue8927@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

[This looks like a bug report against PIP because Tarek told me distutils2 would be responsible for this kind of thing and that there was an open ticket for it.  However, I can't find any such ticket so I'm posting it here]

Not only does pip not check for conflicts as noted in http://bitbucket.org/ianb/pip/src/tip/pip/req.py#cl-928, it doesn't consider any requirements on a package other than the first. So if I have

A requires B and C
B requires D<=1.1
C requires D<=0.9

installing A will give us D==1.1 rather than D==0.9

Once responsibility for this functionality is sorted out, we may be able to close this ticket or http://bitbucket.org/ianb/pip/issue/119

----------
assignee: tarek
components: Distutils2
messages: 107214
nosy: dabrahams, tarek
priority: normal
severity: normal
status: open
title: Cannot handle complex requirement resolution
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Jun  6 21:40:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 19:40:54 +0000
Subject: [issue8925] Improve c-api/arg.rst: use "bytes" or "str" types instead
	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275853254.94.0.0809272531495.issue8925@psf.upfronthosting.co.za>


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

-   buffer protocol (such as :class:`bytes` or :class:`bytearray` objects).
+   buffer protocol.

Is there a reST construct to use here, say to reference a PEP or point to a glossary entry that defines this protocol?

----------
nosy: +merwok

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

From report at bugs.python.org  Sun Jun  6 21:42:35 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 06 Jun 2010 19:42:35 +0000
Subject: [issue1674555] sys.path in tests contains system directories
Message-ID: <1275853355.38.0.400359541066.issue1674555@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I noticed the same problem in many tests.
E.g. test___all__ fails when pyxml is installed.

----------
nosy: +Arfrever
title: Python 2.5 testsuite sys.path contains system dirs -> sys.path in tests contains system directories
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Jun  6 21:56:23 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Jun 2010 19:56:23 +0000
Subject: [issue8925] Improve c-api/arg.rst: use "bytes" or "str" types instead
	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275854183.95.0.372846050297.issue8925@psf.upfronthosting.co.za>


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

If there is a glossary entry, use :term:`buffer protocol`.  If there is none, write one :)

PEPs are referenced by :pep:`4711`.

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

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

From report at bugs.python.org  Sun Jun  6 21:58:20 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 06 Jun 2010 19:58:20 +0000
Subject: [issue600952] Installing w/o admin generates key error
Message-ID: <1275854300.56.0.903388645203.issue600952@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

2.4/2.5 are not fixed anymore. Only security patches.

----------

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

From report at bugs.python.org  Sun Jun  6 22:02:41 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 06 Jun 2010 20:02:41 +0000
Subject: [issue8928] wininst: could not create key
In-Reply-To: <1275854561.45.0.0117544967496.issue8928@psf.upfronthosting.co.za>
Message-ID: <1275854561.45.0.0117544967496.issue8928@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Projects that still support Python 2.4 are building distributions with either 2.4.x or 2.5.x versions, because they afraid that newer installers won't run on Windows XP or Windows 2000.

http://trac.edgewall.org/ticket/9404#comment:2

Unfortunately, these installers fail to create uninstall keys with an error like:
Could not create
    scons-py2.6
Could not set key value
    Python 2.6 SCons - a software construction tool
Could not set key value
    ...\Python26\Removescons.exe" -u ...

This is similar to http://bugs.python.org/issue600952 that was reported for Python 2.1 / 2.2 long ago.

http://scons.tigris.org/issues/show_bug.cgi?id=2533
http://trac.edgewall.org/attachment/ticket/9404/win7_install_warnings.png

----------
assignee: tarek
components: Distutils, Windows
messages: 107219
nosy: tarek, techtonik
priority: normal
severity: normal
status: open
title: wininst: could not create key
versions: Python 2.5

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

From report at bugs.python.org  Sun Jun  6 22:05:30 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 06 Jun 2010 20:05:30 +0000
Subject: [issue8928] wininst: could not create key
In-Reply-To: <1275854561.45.0.0117544967496.issue8928@psf.upfronthosting.co.za>
Message-ID: <1275854730.93.0.254725443414.issue8928@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

There is some uncertainty that 2.6 package installers are dependent on msvcr90.dll - http://trac.edgewall.org/ticket/9404#comment:7

----------

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

From report at bugs.python.org  Sun Jun  6 22:17:12 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 06 Jun 2010 20:17:12 +0000
Subject: [issue8928] wininst: could not create key
In-Reply-To: <1275854561.45.0.0117544967496.issue8928@psf.upfronthosting.co.za>
Message-ID: <1275855432.22.0.525348300117.issue8928@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

as I said in the other issue, there's no bug fix for 2.4 or 2.5 anymore, unless it's a security issue. So I am closing this issue.

Also, your second message seems unrelated. If there's an issue with a dependency under 2.6, please open a distinct issue and explain in detail what is the problem.

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

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

From report at bugs.python.org  Sun Jun  6 22:18:01 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 06 Jun 2010 20:18:01 +0000
Subject: [issue8913] Document that datetime.__format__ is datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1275855481.84.0.0594177581524.issue8913@psf.upfronthosting.co.za>


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

I think Alexander's example is best written as:
"Today is: {0:%a %b %d %H:%M:%S %Y}".format(datetime.now())

I agree with Brett that there's nothing unusual about having type-specific formatting languages, and for datetime strftime is the obvious choice. It's a little unfortunate that % is used, as it's mildly confusing with %-formatting, but not much can be done with that issue.

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

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

From report at bugs.python.org  Sun Jun  6 22:19:04 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 06 Jun 2010 20:19:04 +0000
Subject: [issue8913] Document that datetime.__format__ is datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1275855544.24.0.613420693819.issue8913@psf.upfronthosting.co.za>


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

This documentation should also be added for datetime.time and datetime.date, in addition to datetime.datetime.

----------

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

From report at bugs.python.org  Sun Jun  6 22:23:45 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 06 Jun 2010 20:23:45 +0000
Subject: [issue8909] mention bitmap size for bdist_wininst
In-Reply-To: <1275855825.9.0.442655313563.issue8909@psf.upfronthosting.co.za>
Message-ID: <1275855825.9.0.442655313563.issue8909@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

done in r81788, r81789, r81790, r81791

thanks!

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

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

From report at bugs.python.org  Sun Jun  6 22:25:59 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 06 Jun 2010 20:25:59 +0000
Subject: [issue8928] wininst: could not create key
In-Reply-To: <1275854561.45.0.0117544967496.issue8928@psf.upfronthosting.co.za>
Message-ID: <1275855959.86.0.820631755072.issue8928@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Python process is rigid, no surprises here. But this issue is nevertheless useful to link packages that experience this problem. I'll bump it every time I run into broken package. So far I use:

1. SCons
2. Trac

----------

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

From report at bugs.python.org  Sun Jun  6 22:37:35 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 20:37:35 +0000
Subject: [issue1667546] Time zone-capable variant of time.localtime
Message-ID: <1275856655.72.0.384465862793.issue1667546@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I have updated time-4.diff patch for py3k.  Code changes are minimal, mostly due to string to unicode conversion. I have not attempted to fix anything beyond passing supplied unittest, but I did noticed a few missing error return tests.  I was not able to make the final test in test_mktimetz pass because I did not completely understand its logic.

Georg,

I am trying to consolidate and bring to resolution a number to timezone related issues.  Would you like me to take this issue from you or do you want to continue to own it?

----------
Added file: http://bugs.python.org/file17578/time-4-py3k.diff

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

From report at bugs.python.org  Sun Jun  6 22:48:29 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 06 Jun 2010 20:48:29 +0000
Subject: [issue8929] wininst: msvcr90 dependency in x64 build
In-Reply-To: <1275857309.36.0.937792645197.issue8929@psf.upfronthosting.co.za>
Message-ID: <1275857309.36.0.937792645197.issue8929@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Installers generated with x64 version of Python 2.6.5 seems to have msvcr90.dll dependency that may not be present on all platforms.

http://trac.edgewall.org/ticket/9404#comment:17

----------
assignee: tarek
components: Distutils
messages: 107227
nosy: tarek, techtonik
priority: normal
severity: normal
status: open
title: wininst: msvcr90 dependency in x64 build
versions: Python 2.6

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

From report at bugs.python.org  Sun Jun  6 23:06:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 21:06:19 +0000
Subject: [issue8913] Document that datetime.__format__ is datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1275858379.38.0.138699635554.issue8913@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The problem I have with strftime %-format codes is that according to BSD manual page they have already ran out of English alphabet and still "there is no conversion specification for the phase of the moon." :-)

On a serious note, there are no codes to format TZ offset hours and minutes separately which precludes specifying an important RFC 3339 format.

I think we should take this opportunity to define a comprehensive mini-language for datetime formatting rather than slavishly reuse strftime.

The new mini-language may end up to be a superset of that for strftime, but I would rather not commit to supporting %-codes indefinitely.

----------

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

From report at bugs.python.org  Sun Jun  6 23:09:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jun 2010 21:09:16 +0000
Subject: [issue8839] PyArg_ParseTuple(): remove "t# format
In-Reply-To: <1275002949.14.0.769648340098.issue8839@psf.upfronthosting.co.za>
Message-ID: <1275858556.34.0.0118825521828.issue8839@psf.upfronthosting.co.za>


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

New version of the patch:
 - charbuffer_encode() uses y* instead of y# format to accept modifiable buffer objects (eg. bytearray)
 - Improve the documentation about the change

@lemburg: So, do you agree with my patch?

----------
Added file: http://bugs.python.org/file17579/getarg_remove_tdash-2.patch

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

From report at bugs.python.org  Sun Jun  6 23:13:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jun 2010 21:13:59 +0000
Subject: [issue8925] Improve c-api/arg.rst: use "bytes" or "str" types instead
	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275858839.36.0.0955816790332.issue8925@psf.upfronthosting.co.za>


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

> Is there a reST construct to use here, say to reference a PEP 
> or point to a glossary entry that defines this protocol?

buffer API ("protocol" ?) is documented in Doc/c-api/buffer.rst. Should I link to this document? How?

----------

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

From report at bugs.python.org  Sun Jun  6 23:15:00 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 06 Jun 2010 21:15:00 +0000
Subject: [issue8929] wininst: msvcr90 dependency in x64 build
In-Reply-To: <1275857309.36.0.937792645197.issue8929@psf.upfronthosting.co.za>
Message-ID: <1275858900.03.0.213537691964.issue8929@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
nosy: +loewis, mhammond

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

From report at bugs.python.org  Sun Jun  6 23:22:58 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Jun 2010 21:22:58 +0000
Subject: [issue1667546] Time zone-capable variant of time.localtime
Message-ID: <1275859378.39.0.368522205079.issue1667546@psf.upfronthosting.co.za>


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

(Hi Alexander, sorry for not answering on IRC, I got a phonecall and was distracted for a while.)  Please take on this issue -- I've simply not had energy enough to fight it through.

----------
assignee: georg.brandl -> belopolsky

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

From report at bugs.python.org  Sun Jun  6 23:27:25 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 06 Jun 2010 21:27:25 +0000
Subject: [issue8928] wininst: could not create key
In-Reply-To: <1275854561.45.0.0117544967496.issue8928@psf.upfronthosting.co.za>
Message-ID: <1275859645.32.0.161720790272.issue8928@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Please don't add messages in here just to list the projects that suffer from a bug in Python 2.4 or 2.5. This is just making us extra triage/read work for nothing, and doesn't really help.

Your first report is enough so the error and its references are indexed by the search engines. Thanks for them.

----------

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

From report at bugs.python.org  Sun Jun  6 23:29:46 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 06 Jun 2010 21:29:46 +0000
Subject: [issue8913] Document that datetime.__format__ is datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1275859786.36.0.500939390115.issue8913@psf.upfronthosting.co.za>


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

Unfortunately I think it's too late to do anything about this. I, for one, have many lines of code in production that use the strftime format specifier for datetime.__format__.

You only option would be to invent a new language that was somehow distinguishable from the strftime specifiers, but I doubt you'd get much support.

I think it's better to extend strftime, and let __format__ benefit from it.

----------
versions: +Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun Jun  6 23:38:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 21:38:16 +0000
Subject: [issue8925] Improve c-api/arg.rst: use "bytes" or "str" types instead
	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275860296.02.0.677568046881.issue8925@psf.upfronthosting.co.za>


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

I see that the top section of this file can be referenced though the index entry named ?buffer interface?. Georg, would ?:term:`buffer interface`? work?

Victor, ?protocol? is the named used in Python for what you could call an interface, e.g. the iterator protocol, the sequence protocol,?etc. It?s a documented set of methods, return types and use cases.

----------

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

From report at bugs.python.org  Sun Jun  6 23:39:03 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 06 Jun 2010 21:39:03 +0000
Subject: [issue8918] distutils test failure on solaris: IOError: [Errno 2] No
	such file or directory: '_configtest.i'
In-Reply-To: <1275846660.59.0.731483262347.issue8918@psf.upfronthosting.co.za>
Message-ID: <1275860343.09.0.875777975549.issue8918@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I don't have this platform, could you investigate for me Srid ?

Looks like self._preprocess() fails for some reason. we need to trace this down.

----------

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

From report at bugs.python.org  Sun Jun  6 23:42:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 21:42:36 +0000
Subject: [issue8913] Document that datetime.__format__ is datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1275860556.29.0.633089971967.issue8913@psf.upfronthosting.co.za>


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

I think this particular wheel has one very good reinvention as the Locale Data Markup Language specification. Example from the Python Babel package:

>>> format_datetime(dt, "yyyyy.MMMM.dd GGG hh:mm a", locale='en')
u'02007.April.01 AD 03:30 PM'

http://unicode.org/reports/tr35/#Date_Format_Patterns
http://babel.edgewall.org/wiki/Documentation/dates.html#pattern-syntax

----------
nosy: +merwok

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

From report at bugs.python.org  Sun Jun  6 23:55:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 21:55:24 +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: <1275861324.29.0.419712390406.issue8908@psf.upfronthosting.co.za>


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

Side remarks about tracker process:
1) I?m not sure attaching binary executable files is helpful; if I ran Windows, I wouldn?t run them.
2) Select the 3.3 version for bugs that won?t be fixed to 3.2. Selecting both is redundant: 3.2 is current py3k trunk, it?s not a different branch than 3.3, in contrary to 2.6 and 2.7.
HTH

----------
nosy: +merwok
versions:  -Python 3.3

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

From report at bugs.python.org  Sun Jun  6 23:56:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 21:56:00 +0000
Subject: [issue8916] Move PEP 362 (function signature objects) into inspect
In-Reply-To: <1275795560.39.0.398177747359.issue8916@psf.upfronthosting.co.za>
Message-ID: <1275861360.71.0.0910611648008.issue8916@psf.upfronthosting.co.za>


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


----------
nosy: +merwok

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

From report at bugs.python.org  Sun Jun  6 23:58:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 06 Jun 2010 21:58:13 +0000
Subject: [issue8893] file.{read,readlines} behaviour on Solaris
In-Reply-To: <1275609044.71.0.537925857344.issue8893@psf.upfronthosting.co.za>
Message-ID: <1275861493.5.0.825742188873.issue8893@psf.upfronthosting.co.za>


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

> FreeBSD is yet another beast

Does the patch fix it?

----------

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

From report at bugs.python.org  Mon Jun  7 00:05:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 22:05:59 +0000
Subject: [issue8919] python should read ~/.pythonrc.py by default
In-Reply-To: <1275846984.04.0.731293977336.issue8919@psf.upfronthosting.co.za>
Message-ID: <1275861959.02.0.132805827591.issue8919@psf.upfronthosting.co.za>


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

As stated in http://docs.python.org/library/user (found via http://docs.python.org/genindex-Symbols), this file is an older customization hook that is deprecated. I (not a Python core dev, just a user) personally prefer the environment variable: I set it once in my .bashrc and every interactive python invocation uses it. (I admit that I have to cheat and import another module in order to be compatible from 2.4 to 3.1, but it?s not a big hurdle). Recent changes to the interpreter have added more envvars (PYTHONIOENCODING, PYTHONDONTWRITEBYTECODE), so I don?t see people agreeing to the removal of the venerable PYTHONSTARTUP.

Your last argument can also be reverted: Everything that can be done via pythonrc can be done via PYTHONSTARTUP. The advantage of using an envvar is that it mirrors the behavior of a lot of programs: EDITOR, PAGER, MAILER, BROWSER, LESS, GPG_AGENT_INFO, SSH_AUTH_SOCK, GZIP, EMAIL, and so on. :-)

FTR, ignoring PYTHONSTARTUP can be done by unsetting the variable before launching python, or using python -E (which will ignore all envvars, not only this one).

----------
nosy: +merwok

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

From report at bugs.python.org  Mon Jun  7 00:08:37 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 06 Jun 2010 22:08:37 +0000
Subject: [issue8930] messed up formatting after reindenting
In-Reply-To: <1275862117.51.0.974367285734.issue8930@psf.upfronthosting.co.za>
Message-ID: <1275862117.51.0.974367285734.issue8930@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

Some C code is incorrectly formatted after the Grand Indenting (TM). Take a gander at stringobject.c for an example.

----------
messages: 107240
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
status: open
title: messed up formatting after reindenting

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

From report at bugs.python.org  Mon Jun  7 00:09:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 22:09:13 +0000
Subject: [issue8920] PYTHONSTARTUP should expand "~"
In-Reply-To: <1275847365.81.0.275671627787.issue8920@psf.upfronthosting.co.za>
Message-ID: <1275862153.51.0.784348166853.issue8920@psf.upfronthosting.co.za>


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

The shell does not interpret tildes in quotes, but it does interpret variables, so both your examples make sense. Does removing the quotes fix your problem?

----------
nosy: +merwok
status: pending -> open

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

From report at bugs.python.org  Mon Jun  7 00:09:42 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 06 Jun 2010 22:09:42 +0000
Subject: [issue8916] Move PEP 362 (function signature objects) into inspect
In-Reply-To: <1275795560.39.0.398177747359.issue8916@psf.upfronthosting.co.za>
Message-ID: <1275862182.22.0.726294476844.issue8916@psf.upfronthosting.co.za>


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

I presume you'll either integrate this with the methods and objects inspect already has for this or deprecate them in favor of this?

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

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

From report at bugs.python.org  Mon Jun  7 00:21:44 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Jun 2010 22:21:44 +0000
Subject: [issue8925] Improve c-api/arg.rst: use "bytes" or "str" types instead
	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275862904.85.0.533170745092.issue8925@psf.upfronthosting.co.za>


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

The glossary (see docs.python.org/glossary) does not have an entry for "buffer interface" or "buffer protocol".  An index entry just means that some location in the code defines this entry and gets a link back.

Of course, you can also link to the C API section using :ref:`bufferobjects`.

----------

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

From report at bugs.python.org  Mon Jun  7 00:23:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 22:23:45 +0000
Subject: [issue8901] Windows registry path not ignored with -E option
In-Reply-To: <1275705565.03.0.753930892849.issue8901@psf.upfronthosting.co.za>
Message-ID: <1275863025.19.0.67894348207.issue8901@psf.upfronthosting.co.za>


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

Looks good to me. Adding the release manager to the nosy list.

----------
keywords: +needs review
nosy: +benjamin.peterson, merwok

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

From report at bugs.python.org  Mon Jun  7 00:26:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 22:26:31 +0000
Subject: [issue8904] quick example how to fix docs
In-Reply-To: <1275733848.36.0.713191812865.issue8904@psf.upfronthosting.co.za>
Message-ID: <1275863191.75.0.981695971827.issue8904@psf.upfronthosting.co.za>


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

Would the addition of a link to http://www.python.org/dev/patches/ address your request?

----------
nosy: +merwok

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

From report at bugs.python.org  Mon Jun  7 00:28:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 22:28:53 +0000
Subject: [issue8905] difflib: support input generators
In-Reply-To: <1275738341.19.0.989231664853.issue8905@psf.upfronthosting.co.za>
Message-ID: <1275863333.85.0.0147662013129.issue8905@psf.upfronthosting.co.za>


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

If you allow me to rephrase your feature request to ?difflib should allow arbitrary iterators that yield lines?, I?m +1.

Adjusting the version and adding tim_one to nosy as per py3k/Misc/maintainers.rst

----------
nosy: +merwok, tim_one
type: resource usage -> feature request
versions:  -Python 3.1, Python 3.3

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

From report at bugs.python.org  Mon Jun  7 00:32:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 22:32:11 +0000
Subject: [issue7202] "python setup.py MYCOMMAND --verbose" does not yield an
	unrecognized option error but also does not set the verbosity
In-Reply-To: <1256481428.97.0.691214379627.issue7202@psf.upfronthosting.co.za>
Message-ID: <1275863531.43.0.0597475094058.issue7202@psf.upfronthosting.co.za>


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


----------
nosy: +merwok

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

From report at bugs.python.org  Mon Jun  7 00:37:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 22:37:17 +0000
Subject: [issue644744] bdist_rpm fails when installing man pages
Message-ID: <1275863837.25.0.333158098097.issue644744@psf.upfronthosting.co.za>


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

Distutils is frozen, since changing even internal details breaks third-party tools, and Distutils2 has removed RPM support, since it?s better handled by OS-specific tools that comply with various policies and have smaller release cycles. Tarek, are you closing this bug?

----------
nosy: +merwok

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

From report at bugs.python.org  Mon Jun  7 00:40:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 22:40:05 +0000
Subject: [issue1371826] distutils is silent about multiple -I/-L/-R
Message-ID: <1275864005.63.0.0341679981797.issue1371826@psf.upfronthosting.co.za>


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

I suggest changing component to Distutils2.

----------
nosy: +merwok

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

From report at bugs.python.org  Mon Jun  7 00:49:15 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 22:49:15 +0000
Subject: [issue8916] Move PEP 362 (function signature objects) into inspect
In-Reply-To: <1275862182.22.0.726294476844.issue8916@psf.upfronthosting.co.za>
Message-ID: <AANLkTimEqssu-_JCN7BLbqQ_IoFJA_iPEPZVe1SNDrdI@mail.gmail.com>


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

On Sun, Jun 6, 2010 at 15:09, Benjamin Peterson <report at bugs.python.org> wrote:
>
> Benjamin Peterson <benjamin at python.org> added the comment:
>
> I presume you'll either integrate this with the methods and objects inspect already has for this or deprecate them in favor of this?

Yes, that's the thinking as it replaces getargspec and friends with a
much better API.

----------

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

From report at bugs.python.org  Mon Jun  7 01:07:15 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 06 Jun 2010 23:07:15 +0000
Subject: [issue8931] '#' has no affect with 'c' type
In-Reply-To: <1275865635.78.0.716511257083.issue8931@psf.upfronthosting.co.za>
Message-ID: <1275865635.78.0.716511257083.issue8931@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

$ python3
Python 3.1.2 (release31-maint, May  3 2010, 22:18:46)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> format(ord("a"), "c")
'a'
>>> format(ord("a"), "#c")
'a'

I wonder if '#' with 'c' should raise an exception.

----------
assignee: eric.smith
components: Interpreter Core
messages: 107250
nosy: benjamin.peterson, eric.smith
priority: normal
severity: normal
status: open
title: '#' has no affect with 'c' type
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/issue8931>
_______________________________________

From report at bugs.python.org  Mon Jun  7 01:18:20 2010
From: report at bugs.python.org (lesmana)
Date: Sun, 06 Jun 2010 23:18:20 +0000
Subject: [issue8919] python should read ~/.pythonrc.py by default
In-Reply-To: <1275846984.04.0.731293977336.issue8919@psf.upfronthosting.co.za>
Message-ID: <1275866300.59.0.0929781367116.issue8919@psf.upfronthosting.co.za>


lesmana <lesmana at gmx.de> added the comment:

the .pythonrc.py file is not deprecated. only the user module is deprecated.

the problem i have with the PYTHONSTARTUP variable is that i find it is an unecessary intermediate step to set up an initialization file.

let me elaborate: every single time you want to use PYTHONSTARTUP in any meaningfull way you will ALSO have to set up the corresponding file somehwere. it makes no sense to set up PYTHONSTARTUP without the file. it also makes no sense to set up the file without PYTHONSTARTUP. so PYTHONSTARTUP needs the file and the file needs PYTHONSTARTUP.

that means the variable PYTHONSTARTUP has no added value. it is just an extra step, an extra source of error and possibly confusion. that is why i suggest to skip the variable and just load the file directly.

if you (or anyone else) can point out a use case which can be done with PYTHONSTARTUP but cannot be done with my suggested method, or a use case where using PYTHONSTARTUP is so much simpler than using my suggested method, then i say mark this as wontfix. i was not able to think of such a use case, but i might be missing something.

there is the argument that PYTHONSTARTUP allows the flexibility to point to files with other names. that can be easily achieved by setting up an alias in .bashrc (or respective initialization file for your favorite shell) like this: alias python="python --rcfile somefile". alternatively you can symlink .pythonrc.py to somefile.

the effort to set up such an alias or symlink is the same as setting up an environment variable. everyone else who is happy with the default name (the majority in my opinion) will have one step less to set up.

about the name .pythonrc.py: looking around the web i have the impression that many people set their PYTHONSTARTUP variable to point to .pythonrc.py. i think this is because they used to have the .pythonrc.py file loaded by the module user. after they saw that the module user is beeing deprecated they just point PYTHONSTARTUP to that file. other than that i find the name .pythonrc.py is a fitting name for an initialization file.

about the other tools you mentioned. i checked some of them and some other tools which use environment variables. they almost never use the variables to just dully point to a file, exceptions are variables which point to a resource shared with many other tools (the temp directory for example).

----------

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

From report at bugs.python.org  Mon Jun  7 01:32:11 2010
From: report at bugs.python.org (lesmana)
Date: Sun, 06 Jun 2010 23:32:11 +0000
Subject: [issue8920] PYTHONSTARTUP should expand "~"
In-Reply-To: <1275847365.81.0.275671627787.issue8920@psf.upfronthosting.co.za>
Message-ID: <1275867131.01.0.230239576839.issue8920@psf.upfronthosting.co.za>


lesmana <lesmana at gmx.de> added the comment:

yes the quotes prevented the tilde to be expanded by the shell. somehow i failed to check that. i also failed to check that there is $HOME. somehow i failed to see the forest because of the many trees (a german saying).

technically my original description is still a valid bug report (or feature request). but i understand that it wont be fixed.

----------

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

From report at bugs.python.org  Mon Jun  7 01:41:18 2010
From: report at bugs.python.org (Mark Hammond)
Date: Sun, 06 Jun 2010 23:41:18 +0000
Subject: [issue8929] wininst: msvcr90 dependency in x64 build
In-Reply-To: <1275857309.36.0.937792645197.issue8929@psf.upfronthosting.co.za>
Message-ID: <1275867678.6.0.12126929384.issue8929@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

A quick check of my tree shows that the 32 and 64 bit versions are the same in this regard - the raw stubs wininst-9.0.exe and wininst-9.0-amd64.exe do not depend on the CRT.  A test install of 2.6.5-amd64, then using the 64bit versoion of 'depends' against wininst-9.0-amd64.exe also shows no dependency against the msvc* DLLs.

You may be instead striking a slightly different problem whereby the extension(s) installed by bdist_wininst are failing to start due to this dependency and them not finding or being able to use the same DLLs which Python itself depends on?

----------

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

From report at bugs.python.org  Mon Jun  7 02:08:29 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 07 Jun 2010 00:08:29 +0000
Subject: [issue8929] wininst: msvcr90 dependency in x64 build
In-Reply-To: <1275857309.36.0.937792645197.issue8929@psf.upfronthosting.co.za>
Message-ID: <1275869309.91.0.429280673213.issue8929@psf.upfronthosting.co.za>


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

ISTM that this report is based on hearsay; nobody is *actually* experiencing any problems. Proposing to close this as "invalid".

----------

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

From report at bugs.python.org  Mon Jun  7 02:21:18 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 07 Jun 2010 00:21:18 +0000
Subject: [issue8931] '#' has no affect with 'c' type
In-Reply-To: <1275865635.78.0.716511257083.issue8931@psf.upfronthosting.co.za>
Message-ID: <1275870078.62.0.0834157620102.issue8931@psf.upfronthosting.co.za>


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

I think that every type that # does not apply to should raise an exception.

----------

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

From report at bugs.python.org  Mon Jun  7 02:29:55 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 07 Jun 2010 00:29:55 +0000
Subject: [issue8905] difflib: support input generators
In-Reply-To: <1275738341.19.0.989231664853.issue8905@psf.upfronthosting.co.za>
Message-ID: <1275870595.27.0.167105516632.issue8905@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin
stage:  -> needs patch

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

From report at bugs.python.org  Mon Jun  7 02:39:43 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 07 Jun 2010 00:39:43 +0000
Subject: [issue8519] doc: termios and ioctl reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1275871183.72.0.312442273434.issue8519@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
title: [patch] doc: termios and ioctl reference links -> doc: termios and ioctl reference links

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

From report at bugs.python.org  Mon Jun  7 08:34:53 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 07 Jun 2010 06:34:53 +0000
Subject: [issue8905] difflib should accept arbitrary line iterators
In-Reply-To: <1275738341.19.0.989231664853.issue8905@psf.upfronthosting.co.za>
Message-ID: <1275892493.47.0.209763342032.issue8905@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
title: difflib: support input generators -> difflib should accept arbitrary line iterators

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

From report at bugs.python.org  Mon Jun  7 09:32:23 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 07 Jun 2010 07:32:23 +0000
Subject: [issue8904] quick example how to fix docs
In-Reply-To: <1275863191.75.0.981695971827.issue8904@psf.upfronthosting.co.za>
Message-ID: <AANLkTimceeN0SzaSPirXDBbGhGai0WaCsSKR9eKIZBA0@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Mon, Jun 7, 2010 at 1:26 AM, ?ric Araujo <report at bugs.python.org> wrote:
>
> Would the addition of a link to http://www.python.org/dev/patches/ address your request?

No. It is not quick. It short only for an experienced developer. The
example (or documentation HowTo) should be user based with explanation
how to checkout, compile and test the changes.

----------

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

From report at bugs.python.org  Mon Jun  7 09:56:11 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 07 Jun 2010 07:56:11 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1275897371.18.0.774069478672.issue8828@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Atomic file renames are reimplemented by:
1. Mercurial
2. Trac
3. Dulwich (aka HgGit)

and essential for many other projects out there, so this should be in standard library. Atomic renames depend on filesystem more that on the OS.

----------
nosy: +techtonik

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

From report at bugs.python.org  Mon Jun  7 10:06:17 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 07 Jun 2010 08:06:17 +0000
Subject: [issue7989] Transition time/datetime C modules to Python
In-Reply-To: <1275788127.21.0.430829926194.issue7989@psf.upfronthosting.co.za>
Message-ID: <4C0CA874.8090204@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> As far as I remember, the datetime module started as a pure python module and was reimplemented in C around year 2003 or so.  One of the important additions at that time was the C API to datetime functionality.  I am afraid that with the _timemodule.c/timemodule.py split there will be more an more functionality that is awkward to access from C API.

That's correct, though the main reason for rewriting the module in
C was to gain performance - this is essential for basic types like
date/time types.

-1 on undoing the C rewrite.

It would be much better to spell out the problems you mention and
provide patches to implement solutions for them.

----------
nosy: +lemburg

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

From report at bugs.python.org  Mon Jun  7 10:28:21 2010
From: report at bugs.python.org (Christian Boos)
Date: Mon, 07 Jun 2010 08:28:21 +0000
Subject: [issue8929] wininst: msvcr90 dependency in x64 build
In-Reply-To: <1275857309.36.0.937792645197.issue8929@psf.upfronthosting.co.za>
Message-ID: <1275899301.43.0.535689039933.issue8929@psf.upfronthosting.co.za>


Christian Boos <cboos at neuf.fr> added the comment:

I did a mistake and downloaded an older installer, sorry for the trouble this caused.

The actual Python 2.6.5 (x64) has wininst-9.0.exe and wininst-9.0-amd64.exe built statically as expected.

----------
nosy: +cboos

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

From report at bugs.python.org  Mon Jun  7 10:45:08 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 07 Jun 2010 08:45:08 +0000
Subject: [issue8929] wininst: msvcr90 dependency in x64 build
In-Reply-To: <1275857309.36.0.937792645197.issue8929@psf.upfronthosting.co.za>
Message-ID: <1275900308.66.0.174566012683.issue8929@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/issue8929>
_______________________________________

From report at bugs.python.org  Mon Jun  7 10:55:46 2010
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Mon, 07 Jun 2010 08:55:46 +0000
Subject: [issue8848] Deprecate or remove "U" and "U#" formats of
	Py_BuildValue()
In-Reply-To: <1275097128.66.0.216673219733.issue8848@psf.upfronthosting.co.za>
Message-ID: <1275900946.17.0.762945541614.issue8848@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

Yes, I think you should apply the patch.

----------

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

From report at bugs.python.org  Mon Jun  7 11:55:44 2010
From: report at bugs.python.org (Mads Kiilerich)
Date: Mon, 07 Jun 2010 09:55:44 +0000
Subject: [issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum
	recursion depth exceeded in cmp
In-Reply-To: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za>
Message-ID: <1275904544.96.0.658346077634.issue8797@psf.upfronthosting.co.za>


Mads Kiilerich <mads at kiilerich.com> added the comment:

FYI:
The regression was introduced in 2.6.5 with issue3819 .

This also causes problems with Mercurial pushing to google code - see http://mercurial.selenic.com/bts/issue2179 . 

IIRC google code redirects to an url which then in turn requests authentication. I'm not sure how that will work with a retry count of 1. The funny and inconsistent thing is that it apparently would work if they replied 403 instead of 401. "durin42" from google/mercurial knows the details.

(It seems suspicious to me that there are code paths where the retry counter is reset. Doesn't that mean that a remote server will be able to cause endless recursion? Shouldn't there be some kind of hard upper limit on the number of retries?)

----------
nosy: +kiilerix

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

From report at bugs.python.org  Mon Jun  7 12:16:56 2010
From: report at bugs.python.org (Thomas Jollans)
Date: Mon, 07 Jun 2010 10:16:56 +0000
Subject: [issue8897] sunau bytes / str TypeError in Py3k
In-Reply-To: <1275672895.91.0.97400241219.issue8897@psf.upfronthosting.co.za>
Message-ID: <1275905816.04.0.0566553053087.issue8897@psf.upfronthosting.co.za>


Thomas Jollans <thomas at jollans.com> added the comment:

Attached is a patch against the current py3k trunk that fixes this. (as far as I can tell)

----------
keywords: +patch
Added file: http://bugs.python.org/file17580/sunau-bytes.diff

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

From report at bugs.python.org  Mon Jun  7 13:21:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jun 2010 11:21:01 +0000
Subject: [issue8897] sunau bytes / str TypeError in Py3k
In-Reply-To: <1275672895.91.0.97400241219.issue8897@psf.upfronthosting.co.za>
Message-ID: <1275909661.86.0.174618896416.issue8897@psf.upfronthosting.co.za>


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

Can you add a test?

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

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

From report at bugs.python.org  Mon Jun  7 13:27:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jun 2010 11:27:07 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1275910027.57.0.445764818619.issue8828@psf.upfronthosting.co.za>


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

Implementation of "atomic" rename() for Windows in Mercurial:
http://selenic.com/repo/hg/file/tip/mercurial/windows.py
(search for "def rename")

----------

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

From report at bugs.python.org  Mon Jun  7 15:10:01 2010
From: report at bugs.python.org (Daniel Urban)
Date: Mon, 07 Jun 2010 13:10:01 +0000
Subject: [issue7989] Transition time/datetime C modules to Python
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1275916201.64.0.458499217861.issue7989@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/issue7989>
_______________________________________

From report at bugs.python.org  Mon Jun  7 15:25:02 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 07 Jun 2010 13:25:02 +0000
Subject: [issue8904] quick example how to fix docs
In-Reply-To: <1275733848.36.0.713191812865.issue8904@psf.upfronthosting.co.za>
Message-ID: <1275917102.74.0.351202377008.issue8904@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I think what you are suggesting is outside of the scope of that document -- it appears that the page intends to be quick and strictly focused on reporting bugs, not fixing them.

----------
nosy: +brian.curtin
status: open -> pending

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

From report at bugs.python.org  Mon Jun  7 15:45:05 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 07 Jun 2010 13:45:05 +0000
Subject: [issue8875] XML-RPC improvement is described twice.
In-Reply-To: <1275446731.65.0.0364952757342.issue8875@psf.upfronthosting.co.za>
Message-ID: <1275918305.47.0.394499753011.issue8875@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Fixed in rev81801.  Thanks for your report!

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

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

From report at bugs.python.org  Mon Jun  7 16:18:31 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 07 Jun 2010 14:18:31 +0000
Subject: [issue8932] test_capi fails --without-threads
In-Reply-To: <1275920311.66.0.668508833074.issue8932@psf.upfronthosting.co.za>
Message-ID: <1275920311.66.0.668508833074.issue8932@psf.upfronthosting.co.za>


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

test_capi fails when compiled --without-threads:

test test_capi failed -- Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_capi.py", line 49, in test_no_FatalError_infinite_loop
    b'Fatal Python error:'
AssertionError: b'Traceback (most recent call last):\n  File "<string>", line 1, in <module>\nSystemError: error return without exception set\n[34135 refs]' != b'Fatal Python error: PyThreadState_Get: no current thread'

Re-running test test_capi in verbose mode
test_instancemethod (test.test_capi.CAPITest) ... ok
test_no_FatalError_infinite_loop (test.test_capi.CAPITest) ... FAIL

======================================================================
FAIL: test_no_FatalError_infinite_loop (test.test_capi.CAPITest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_capi.py", line 49, in test_no_FatalError_infinite_loop
    b'Fatal Python error:'
AssertionError: b'Traceback (most recent call last):\n  File "<string>", line 1, in <module>\nSystemError: error return without exception set\n[34135 refs]' != b'Fatal Python error: PyThreadState_Get: no current thread'

----------------------------------------------------------------------
Ran 2 tests in 0.635s

FAILED (failures=1)
test test_capi failed -- Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_capi.py", line 49, in test_no_FatalError_infinite_loop
    b'Fatal Python error:'
AssertionError: b'Traceback (most recent call last):\n  File "<string>", line 1, in <module>\nSystemError: error return without exception set\n[34135 refs]' != b'Fatal Python error: PyThreadState_Get: no current thread'

----------
components: Tests
keywords: buildbot
messages: 107267
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_capi fails --without-threads
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Jun  7 18:22:41 2010
From: report at bugs.python.org (Benjamin Liles)
Date: Mon, 07 Jun 2010 16:22:41 +0000
Subject: [issue8933] Invalid detection of metadata version
In-Reply-To: <1275927761.19.0.897367518837.issue8933@psf.upfronthosting.co.za>
Message-ID: <1275927761.19.0.897367518837.issue8933@psf.upfronthosting.co.za>


New submission from Benjamin Liles <benliles at gmail.com>:

The detection for metadata version does not follow what is specified in PEP 241 and PEP 314.

Specifically, the following fields are being sent as version 1.0 when they are not allowed as per PEP 241:

* Classifier
* Download-URL

----------
assignee: tarek
components: Distutils
messages: 107268
nosy: benliles, tarek
priority: normal
severity: normal
status: open
title: Invalid detection of metadata version
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Mon Jun  7 18:25:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 07 Jun 2010 16:25:46 +0000
Subject: [issue8933] Invalid detection of metadata version
In-Reply-To: <1275927761.19.0.897367518837.issue8933@psf.upfronthosting.co.za>
Message-ID: <1275927946.81.0.369629939035.issue8933@psf.upfronthosting.co.za>


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


----------
nosy: +merwok

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

From report at bugs.python.org  Mon Jun  7 19:06:42 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 07 Jun 2010 17:06:42 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1275930402.5.0.810607328258.issue8828@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Dulwich bug discussion (closed) - https://bugs.edge.launchpad.net/dulwich/+bug/557585

Trac implementation - http://trac.edgewall.org/browser/trunk/trac/util/__init__.py?#L82

Stackoverflow - http://stackoverflow.com/questions/167414/is-an-atomic-file-rename-with-overwrite-possible-on-windows

----------

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

From report at bugs.python.org  Mon Jun  7 19:10:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 07 Jun 2010 17:10:25 +0000
Subject: [issue8910] Write a text file explaining why Lib/test/data exists
In-Reply-To: <1275793580.19.0.611567237471.issue8910@psf.upfronthosting.co.za>
Message-ID: <1275930625.8.0.110376020589.issue8910@psf.upfronthosting.co.za>


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

Attaching a proposal.

I think the component is a grey area between tests and documentation, so I?d be for including this file in all four branches.

----------
keywords: +needs review, patch
nosy: +docs at python, merwok
Added file: http://bugs.python.org/file17581/README

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

From report at bugs.python.org  Mon Jun  7 19:14:26 2010
From: report at bugs.python.org (Thomas Jollans)
Date: Mon, 07 Jun 2010 17:14:26 +0000
Subject: [issue8897] sunau bytes / str TypeError in Py3k
In-Reply-To: <1275672895.91.0.97400241219.issue8897@psf.upfronthosting.co.za>
Message-ID: <1275930866.94.0.724530498796.issue8897@psf.upfronthosting.co.za>


Thomas Jollans <thomas at jollans.com> added the comment:

test case for sunau, as requested. Loosely based on test_wave.

----------
Added file: http://bugs.python.org/file17582/sunau-test.diff

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

From report at bugs.python.org  Mon Jun  7 19:15:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 07 Jun 2010 17:15:27 +0000
Subject: [issue4769] b64decode should accept strings or bytes
In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za>
Message-ID: <1275930927.37.0.943350071696.issue4769@psf.upfronthosting.co.za>


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


----------
nosy: +merwok

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

From report at bugs.python.org  Mon Jun  7 19:17:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 07 Jun 2010 17:17:08 +0000
Subject: [issue7989] Transition time/datetime C modules to Python
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1275931028.98.0.75757220062.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

For the datetime module there are also a few more subtle issues that would make it difficult to make a hybrid C/Python implementation.  The problem is that unlike the time module where most of the functionality is implemented in module level functions, datetime functionality is entirely in class methods.

One may suggest to use inheritance and derive datetime classes from those implemented in _datetime.c, but this will not work because for example datetime + timedelta will return a _datetime class unless __add__ is overridden in Python.  There is another even less obvious issue with inheriting from datetime classes: see issue #5516.

Therefore, it looks like there are only two choices:

1. Replicate all functionality in both _datetime.c and datetime.py and thus double the cost of implementing new features in CPython. (OK, maybe not double because Python development is easier than C, but increase instead of decrease.)

2. Incur a performance penalty in every method because every C call wil have to be wrapped in Python.

Another -1 from me.

----------

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

From report at bugs.python.org  Mon Jun  7 19:17:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 07 Jun 2010 17:17:55 +0000
Subject: [issue7989] Transition time/datetime C modules to Python
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1275931075.97.0.693016850825.issue7989@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
versions:  -Python 2.7

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

From report at bugs.python.org  Mon Jun  7 19:34:22 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 07 Jun 2010 17:34:22 +0000
Subject: [issue8719] buildbot: segfault on FreeBSD (signal 11)
In-Reply-To: <1273875581.36.0.231394687131.issue8719@psf.upfronthosting.co.za>
Message-ID: <1275932062.03.0.539419758964.issue8719@psf.upfronthosting.co.za>


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

I ran a test --without-threads: test_runpy and test_exceptions passed,
test_sys was not reached:


test_sqlite
Fatal error 'Cannot allocate red zone for initial thread' at line 384 in file /usr/src/lib/libthr/thread/thr_init.c (errno = 12)
*** Signal 6


No Signal 11. I suspect threads (again).

Would it be a good idea to run the FreeBSD bots --without-threads?

----------
nosy: +db3l, skrah

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

From report at bugs.python.org  Mon Jun  7 20:56:05 2010
From: report at bugs.python.org (Thomas Jollans)
Date: Mon, 07 Jun 2010 18:56:05 +0000
Subject: [issue8934] aifc should use str instead of bytes (wave,
	sunau compatibility)
In-Reply-To: <1275936965.71.0.27334704307.issue8934@psf.upfronthosting.co.za>
Message-ID: <1275936965.71.0.27334704307.issue8934@psf.upfronthosting.co.za>


New submission from Thomas Jollans <thomas at jollans.com>:

aifc getcomptype() and setcomptype() use bytes while the corresponding methods in the sunau and wave modules use str (b'NONE', b'ULAW' vs 'NONE', 'ULAW'). This means that programmers wanting simple format-agnostic audio file output will have to special-case aifc. This was not necessary in Python 2.x, where all three modules used str (obviously). IMHO, there is no reason for this incompatibility.

The solution I propose is to change aifc to use unicode str for "information" strings and bytes for raw data only, like the other two modules. This is, the way I see it, the most sensible behaviour.

I'm attaching a patch that does just this: it changes aifc to use str for all (non-data) strings: comptype, compname, and markers. I've also changed the testcase accordingly.

The problem is, obviously, that this could break existing code. I doubt that it would break a lot of code since:
 - not that many people use aifc anyway (I think), and py3k is still
   young
 - py3k code that's out there now would most likely handle both
   scenarios anyway to account for the wave and sunau modules
 - setcomptype() would still accept bytes.

On the other hand, it would, as I said, simplify writing format-agnostic code. Special-casing any module wouldn't have been necessary with Python 2, why should Python 3 be any different?

There, I've made my case. Georg, I put you on the nosy list because of
  [svn r64023] Remove cl usage from aifc and use bytes throughout.
You, apparently, made the decision I'm arguing should be reverted, if indeed anyone consciously made it at all.

If this is applied, it would have to be properly documented, of course.

----------
components: Library (Lib)
files: aifc_use_str.diff
keywords: patch
messages: 107274
nosy: georg.brandl, tjollans
priority: normal
severity: normal
status: open
title: aifc should use str instead of bytes (wave, sunau compatibility)
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17583/aifc_use_str.diff

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

From report at bugs.python.org  Mon Jun  7 21:14:32 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 07 Jun 2010 19:14:32 +0000
Subject: [issue7989] Transition time/datetime C modules to Python
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1275938072.35.0.635816659728.issue7989@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

It seems like this might not be worth it or a good idea, and I have no strong feeling for this being done. Feel free to close/reject this one.

----------

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

From report at bugs.python.org  Mon Jun  7 21:48:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jun 2010 19:48:29 +0000
Subject: [issue8934] aifc should use str instead of bytes (wave,
	sunau compatibility)
In-Reply-To: <1275936965.71.0.27334704307.issue8934@psf.upfronthosting.co.za>
Message-ID: <1275940109.67.0.33901848128.issue8934@psf.upfronthosting.co.za>


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


----------
components: +Unicode
nosy: +haypo

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

From report at bugs.python.org  Mon Jun  7 22:00:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jun 2010 20:00:47 +0000
Subject: [issue8848] Deprecate or remove "U" and "U#" formats of
	Py_BuildValue()
In-Reply-To: <1275097128.66.0.216673219733.issue8848@psf.upfronthosting.co.za>
Message-ID: <1275940847.66.0.758832354988.issue8848@psf.upfronthosting.co.za>


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

Commited to py3k (r81807), blocked in 3.1 (r81808).

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

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

From report at bugs.python.org  Mon Jun  7 22:02:34 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 07 Jun 2010 20:02:34 +0000
Subject: [issue8905] difflib should accept arbitrary line iterators
In-Reply-To: <1275738341.19.0.989231664853.issue8905@psf.upfronthosting.co.za>
Message-ID: <1275940954.67.0.73115958831.issue8905@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/issue8905>
_______________________________________

From report at bugs.python.org  Mon Jun  7 22:03:52 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 07 Jun 2010 20:03:52 +0000
Subject: [issue8919] python should read ~/.pythonrc.py by default
In-Reply-To: <1275846984.04.0.731293977336.issue8919@psf.upfronthosting.co.za>
Message-ID: <1275941032.07.0.833354137142.issue8919@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/issue8919>
_______________________________________

From report at bugs.python.org  Mon Jun  7 22:26:47 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 07 Jun 2010 20:26:47 +0000
Subject: [issue1982] Feature: extend strftime to accept milliseconds
In-Reply-To: <1201805956.67.0.436839158391.issue1982@psf.upfronthosting.co.za>
Message-ID: <1275942407.35.0.792690160948.issue1982@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/issue1982>
_______________________________________

From report at bugs.python.org  Mon Jun  7 22:26:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jun 2010 20:26:56 +0000
Subject: [issue8897] sunau bytes / str TypeError in Py3k
In-Reply-To: <1275672895.91.0.97400241219.issue8897@psf.upfronthosting.co.za>
Message-ID: <1275942416.51.0.526966014044.issue8897@psf.upfronthosting.co.za>


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

> test case for sunau, as requested. Loosely based on test_wave.

Ok great. Commited to py3k (r81809) and 3.1 (r81810).

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

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

From report at bugs.python.org  Mon Jun  7 22:53:11 2010
From: report at bugs.python.org (Thomas Jollans)
Date: Mon, 07 Jun 2010 20:53:11 +0000
Subject: [issue8934] aifc should use str instead of bytes (wave,
	sunau compatibility)
In-Reply-To: <1275936965.71.0.27334704307.issue8934@psf.upfronthosting.co.za>
Message-ID: <1275943991.59.0.258846570077.issue8934@psf.upfronthosting.co.za>


Thomas Jollans <thomas at jollans.com> added the comment:

tentative documentation patch uploaded

----------
Added file: http://bugs.python.org/file17584/aifc_str_doc.diff

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

From report at bugs.python.org  Mon Jun  7 23:13:28 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 07 Jun 2010 21:13:28 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275945208.06.0.734620807012.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Readying the patch for commit.  Added documentation, tests and implementation of fromutc() method that does not need a dst().

----------
resolution:  -> accepted
Added file: http://bugs.python.org/file17585/issue5094d.diff

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

From report at bugs.python.org  Mon Jun  7 23:25:04 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 07 Jun 2010 21:25:04 +0000
Subject: [issue8922] Improve encoding shortcuts in PyUnicode_AsEncodedString()
In-Reply-To: <1275848637.97.0.606582513318.issue8922@psf.upfronthosting.co.za>
Message-ID: <4C0D63AC.4060705@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_Decode() and PyUnicode_AsEncodedString() calls directly builtin decoders/encoders for some known encodings (eg. "utf-8"), instead of using the slow path (call PyCodec_Decode() / PyCodec_Encode()). 
> 
> PyUnicode_Decode() does normalize the encoding name: convert to lower and replace "_" by "-", as normalizestring() does. But PyUnicode_AsEncodedString() doesn't normalize the encoding name, it just use strcmp(). PyUnicode_Decode() has a shortcut for ISO-8859-1, whereas PyUnicode_AsEncodedString() doesn't (only for "latin-1").
> 
> Attached patch creates a subfunction (static) normalize_encoding(), use it in PyUnicode_Decode() and PyUnicode_AsEncodedString(), and adds a shortcut for ISO-8859-1 to PyUnicode_AsEncodedString().

The normalization in PyUnicode_Decode() must have been added to
Python3 only. It is not present in Python2.

I'm not sure whether it's a good idea to extend this further:
the shortcuts were meant for Python internal use only. Python
itself and it's stdlib should only use the shortcut names
for the resp. special encodings and no variants.

Dealing with variants and normalization is left to the encodings
package and its alias machinery.

Since the Python stdlib and the core already mostly use
the shortcut names, adding normalization won't buy us much.

Note that your change has also made it impossible for the
compiler to do loop unrolling - there's not upper limit
on the size of lower anymore.

In terms of coding style, "static" should go on a separate line.

----------
nosy: +lemburg

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

From report at bugs.python.org  Mon Jun  7 23:33:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jun 2010 21:33:54 +0000
Subject: [issue8925] Improve c-api/arg.rst: use "bytes" or "str" types instead
	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275946434.86.0.499038339355.issue8925@psf.upfronthosting.co.za>


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

Commited to 3.2 (r81811) and 3.1 (r81812). The final patch adds also links to tuple, list, dict, float, complex and int. Replace also long by int (long doesn't exist anymore in Python3).

@merwok: Please open a new issue if you would like to improve the documentation about the buffer protocol.

----------

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

From report at bugs.python.org  Mon Jun  7 23:34:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jun 2010 21:34:32 +0000
Subject: [issue8925] Improve c-api/arg.rst: use "bytes" or "str" types instead
	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275946472.62.0.0249993296533.issue8925@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/issue8925>
_______________________________________

From report at bugs.python.org  Mon Jun  7 23:37:07 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 07 Jun 2010 21:37:07 +0000
Subject: [issue8923] Remove unused "errors" argument
	from	_PyUnicode_AsDefaultEncodedString()
In-Reply-To: <1275848921.87.0.52681950966.issue8923@psf.upfronthosting.co.za>
Message-ID: <4C0D667F.60601@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_AsDefaultEncodedString() has two arguments: unicode (input string) and errors. If errors is not NULL, it calls Py_FatalError()!
> 
> The argument is useful: all functions call it with errors=NULL.
> 
> Attached patch removes the argument.

While it's an internal API, it's still public and we cannot
just remove the extra argument - we're in stable branch mode.

Since Python3 fixes the UTF-8 default encoding, it's better
to enhance PyUnicode_AsUTF8String() to cache the UTF-8
string in the Unicode object or simply return it directly
and then replace all uses of _PyUnicode_AsDefaultEncodedString()
with PyUnicode_AsUTF8String().

We should phase out use of _PyUnicode_AsDefaultEncodedString()
as well as the whole default encoding terminology altogether.

Please also add a documentation patch and a NEWS entry.

----------
nosy: +lemburg
title: Remove unused "errors" argument from _PyUnicode_AsDefaultEncodedString() -> Remove unused "errors" argument from	_PyUnicode_AsDefaultEncodedString()

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

From report at bugs.python.org  Mon Jun  7 23:43:54 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 07 Jun 2010 21:43:54 +0000
Subject: [issue8925] Improve c-api/arg.rst: use "bytes" or "str" types
	instead	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <4C0D680C.9070101@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>:
> 
> http://docs.python.org/py3k/c-api/arg.html is unclear about what is a "string".
> 
> Attached patch:
>  - Use directly bytes, bytearray and str types
>  - Replace "default encoding" by "``'utf-8'`` encoding"
>  - Add bytes and/or bytearray to "... buffer compatible object" because it's not easy to understand what is a buffer compatible object, especially because there are different kind of buffer objects: read-only, read-write, pinned, etc.
>  - Fix reST syntax ("..note ::")
>  - Fix "es", "es#", "et" and "et#" formats: they doesn't accept "character buffer compatible object" (can someone double check that?)

The character buffer concept is (unfortunately) gone in Python3.

There's no way for a buffer compatible object to tell the
arg parser that it is storing text data. Perhaps we can add something
like that back via the Py_buffer flags for getting buffers.

----------
nosy: +lemburg
title: Improve c-api/arg.rst: use "bytes" or "str" types instead of "string" -> Improve c-api/arg.rst: use "bytes" or "str" types instead	of "string"

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

From report at bugs.python.org  Mon Jun  7 23:50:22 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 07 Jun 2010 21:50:22 +0000
Subject: [issue8839] PyArg_ParseTuple(): remove "t# format
In-Reply-To: <1275858556.34.0.0118825521828.issue8839@psf.upfronthosting.co.za>
Message-ID: <4C0D699B.7060000@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:
>  - charbuffer_encode() uses y* instead of y# format to accept modifiable buffer objects (eg. bytearray)
>  - Improve the documentation about the change
> 
> @lemburg: So, do you agree with my patch?

No, because y*/y# are not correct replacements for t#. They don't
accept Unicode objects.

t# was meant to provide access to text data, so replacing it with a
parser code that is meant for binary data is not correct. The
closes Python3 gets to t# from Python2 is s# or s*, so please use
those in the NEWS entry and s* in charbuffer_encode().

----------

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

From report at bugs.python.org  Tue Jun  8 00:00:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jun 2010 22:00:12 +0000
Subject: [issue8922] Improve encoding shortcuts in PyUnicode_AsEncodedString()
In-Reply-To: <1275848637.97.0.606582513318.issue8922@psf.upfronthosting.co.za>
Message-ID: <1275948012.87.0.376828447686.issue8922@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> the shortcuts were meant for Python internal use only

str.encode() calls PyUnicode_AsEncodedString() and bytes.decode() calls PyUnicode_Decode(), so it is not for internal use only. Eg. "text".encode("ASCII") doesn't use the fastpath.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8922>
_______________________________________

From report at bugs.python.org  Tue Jun  8 00:05:30 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 07 Jun 2010 22:05:30 +0000
Subject: [issue8922] Improve encoding shortcuts in PyUnicode_AsEncodedString()
In-Reply-To: <1275948012.87.0.376828447686.issue8922@psf.upfronthosting.co.za>
Message-ID: <4C0D6D26.402@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 shortcuts were meant for Python internal use only
> 
> str.encode() calls PyUnicode_AsEncodedString() and bytes.decode() calls PyUnicode_Decode(), so it is not for internal use only. Eg. "text".encode("ASCII") doesn't use the fastpath.

Right. As I said: the *shortcuts* are meant for internal use
only. External code should not rely on them, but can, of course,
use those canonical names as well.

Note that these shortcut bypass the codec registry logic. Codec
search functions cannot redirect these shortcuts to their
own implementations, so we have to be careful about adding more
such shortcuts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8922>
_______________________________________

From report at bugs.python.org  Tue Jun  8 00:33:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jun 2010 22:33:01 +0000
Subject: [issue8922] Improve encoding shortcuts in PyUnicode_AsEncodedString()
In-Reply-To: <1275848637.97.0.606582513318.issue8922@psf.upfronthosting.co.za>
Message-ID: <1275949981.66.0.571681325081.issue8922@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Note that these shortcut bypass the codec registry logic.

Yes, but it's already the case without my patch. I don't think that it's really useful to override latin1, utf-8, utf-16, utf-32 or mbcs. I prefer a faster Python :-) 

> we have to be careful about adding more such shortcuts.

I just want to add a shortcut for ISO-8859-1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8922>
_______________________________________

From report at bugs.python.org  Tue Jun  8 00:48:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jun 2010 22:48:46 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode()
	and	codecs.charbuffer_encode()
In-Reply-To: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>
Message-ID: <1275950926.09.0.370952171389.issue8838@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

MAL agreed to remove "t#" parsing format (#8839), whereas charbuffer_encode() main goal was to offer "t#" parsing format to Python object space. charbuffer_encode() is now useless in Python3. bytes() accepts any buffer object (read-only and read/write buffer), so readbuffer_encode() became useless in Python3.

readbuffer_encode() and charbuffer_encode() were never documented, and are not used by any 3rd party library.

Can we remove these two functions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Tue Jun  8 01:04:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jun 2010 23:04:58 +0000
Subject: [issue8925] Improve c-api/arg.rst: use "bytes" or "str" types
	instead	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275951898.92.0.197760564329.issue8925@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> There's no way for a buffer compatible object to tell the
> arg parser that it is storing text data.

I think that the buffer protocol targets byte strings/arrays, and that unicode type should be enough.

If applications have to exchange text data, they use utf8, which is a byte string. I don't see the use case. Open a discussion on python-dev if you would like to continue the discussion because this issue is closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8925>
_______________________________________

From report at bugs.python.org  Tue Jun  8 01:29:05 2010
From: report at bugs.python.org (Daniel Urban)
Date: Mon, 07 Jun 2010 23:29:05 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275953345.12.0.0168986057498.issue5094@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

In Doc/library/datetime.rst, in the documentation of datetime.utcnow this part: ".. versionchanged:: 2.7" probably should be ".. versionchanged:: 3.2".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue Jun  8 02:16:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 00:16:51 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1275956211.93.0.291885276543.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Thanks, Daniel.  This was a leftover from the previous patch.  The latest patch does not actually change utcnow().  Instead the users should call datetime.now(timezone.utc). Fixed in issue5094d1.diff.

----------
Added file: http://bugs.python.org/file17586/issue5094d1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue Jun  8 02:28:28 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 00:28:28 +0000
Subject: [issue7989] Transition time/datetime C modules to Python
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1275956908.04.0.88451819431.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Brett Cannon wrote in a comment (msg106498) on another issue:

"""
The stated long-term goal of the stdlib is to minimize the C extension modules to only those that have to be written in C (modules can still have performance enhancing extension back-ends). Since datetime does not meet that requirement it's not a matter of "if" but "when" datetime will get a pure Python version and use the extension code only for performance.
"""

I'll keep this open for a while to give Brett and others a chance to respond to opposition.

----------
nosy: +brett.cannon
priority: normal -> low
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Tue Jun  8 02:35:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 00:35:08 +0000
Subject: [issue7989] Transition time/datetime C modules to Python
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1275957308.33.0.170489863462.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Also, my opposition is only to splitting datetime.  While I am not against splitting the time module, I believe it should be phased out eventually and posix compatibility portion folded into posix module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Tue Jun  8 02:58:40 2010
From: report at bugs.python.org (Stan Klein)
Date: Tue, 08 Jun 2010 00:58:40 +0000
Subject: [issue8935] Syntax error in os.py
In-Reply-To: <1275958720.19.0.807704526769.issue8935@psf.upfronthosting.co.za>
Message-ID: <1275958720.19.0.807704526769.issue8935@psf.upfronthosting.co.za>


New submission from Stan Klein <sklein at cpcug.org>:

I got the following traceback on an "import os" statement:


Traceback (most recent call last):
  File "setup.py", line 53, in ?
    import traceback
  File "/usr/lib/python2.6/traceback.py", line 3, in ?
    import linecache
  File "/usr/lib/python2.6/linecache.py", line 9, in ?
    import os
  File "/usr/lib/python2.6/os.py", line 758
    bs = b""
           ^
SyntaxError: invalid syntax

>From looking at 2.4, the fix is probably bs=""

----------
components: Library (Lib)
messages: 107294
nosy: sklein
priority: normal
severity: normal
status: open
title: Syntax error in os.py
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8935>
_______________________________________

From report at bugs.python.org  Tue Jun  8 02:58:49 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 08 Jun 2010 00:58:49 +0000
Subject: [issue7989] Transition time/datetime C modules to Python
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1275958729.6.0.0895274034574.issue7989@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So I see a couple of objections here to the idea that I will try to address.

First is MAL's thinking that this will undo any C code, which it won't. The idea is that stdlib modules that do not inherently rely on other C code (e.g. sqlite3 does not fall underneath this) would have a pure Python implementation with possible C enhancements. In the case of datetime that  code is done, so it won't go anywhere. In this case it would be bringing in a pure Python implementation like the one PyPy maintains. You can look at heapq if you want an existing example of what it looks like to maintain a pure Python and C version of a module.

Alexander is worried about performance because of Python shims and duplication of work. For the performance issue, there is none. If you look at something like heapq you will see that there is an `import *` in there to pull in all extension code; there is no Python shim to pass through if you don't engineer the extension that way. So in datetime's case all of the extension code would just get pulled into datetime.py directly and not have any indirection cost.

As for duplication of work, we already have that with datetime in the other Python VMs. IronPython, Jython, and PyPy have to do their own version of datetime because the stdlib doesn't provide a pure Python version for them to use. So while CPython might not be duplicating work, other people are. Besides, people typically prototype in Python anyway (including you, Alexander, for the UTC patch) and then write the C code, so there really isn't any wasted development cycles by having the Python and C version already.

The key thing to remember is that this is so the VMs other than CPython are not treated as second-class. They are legit implementations just like CPython, but because we have this legacy stuff written in C in the stdlib they are put at a disadvantage. It would be better to pool resources and make sure everyone gets to use an equivalent standard library when possible.

And I should also mention I expect the PyPy folks to be the ones to move their code over; I would never expect anyone to re-implement datetime from scratch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Tue Jun  8 03:04:15 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 08 Jun 2010 01:04:15 +0000
Subject: [issue8935] Syntax error in os.py
In-Reply-To: <1275958720.19.0.807704526769.issue8935@psf.upfronthosting.co.za>
Message-ID: <1275959055.75.0.923575767957.issue8935@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

In 2.6 b"" is valid syntax.
If you are using 2.6 modules on Python 2.4 you will probably see several more errors.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8935>
_______________________________________

From report at bugs.python.org  Tue Jun  8 05:46:41 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 08 Jun 2010 03:46:41 +0000
Subject: [issue8936] webbrowser regression on windows
In-Reply-To: <1275968801.71.0.456370362373.issue8936@psf.upfronthosting.co.za>
Message-ID: <1275968801.71.0.456370362373.issue8936@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

webbrowser.open("127.0.0.1:8080") opens page in IE even if default system browser is Chrome.

----------
components: Library (Lib), Windows
messages: 107297
nosy: techtonik
priority: normal
severity: normal
status: open
title: webbrowser regression on windows
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8936>
_______________________________________

From report at bugs.python.org  Tue Jun  8 05:51:08 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 08 Jun 2010 03:51:08 +0000
Subject: [issue7989] Transition time/datetime C modules to Python
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1275969068.02.0.551327109676.issue7989@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

It would be nice to see the transition accompanied by some tutorial that could be used as an example for other similar tasks.

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Tue Jun  8 05:53:39 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 08 Jun 2010 03:53:39 +0000
Subject: [issue8936] webbrowser regression on windows
In-Reply-To: <1275968801.71.0.456370362373.issue8936@psf.upfronthosting.co.za>
Message-ID: <1275969219.52.0.667129115703.issue8936@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

See also #8232

----------
nosy: +brian.curtin
stage:  -> unit test needed
type:  -> behavior
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8936>
_______________________________________

From report at bugs.python.org  Tue Jun  8 05:54:26 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 08 Jun 2010 03:54:26 +0000
Subject: [issue8936] webbrowser regression on windows
In-Reply-To: <1275968801.71.0.456370362373.issue8936@psf.upfronthosting.co.za>
Message-ID: <1275969266.39.0.523263080293.issue8936@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Also, since you stated that this is a regression -- what was the last version you saw this work in?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8936>
_______________________________________

From report at bugs.python.org  Tue Jun  8 05:55:58 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 08 Jun 2010 03:55:58 +0000
Subject: [issue8936] webbrowser regression on windows
In-Reply-To: <1275968801.71.0.456370362373.issue8936@psf.upfronthosting.co.za>
Message-ID: <1275969358.81.0.615805767809.issue8936@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If you want it to open it with the default browser you have to specify the protocol (e.g. webbrowser.open("http://127.0.0.1:8080/")).
I don't know exactly why webbrowser decides to open webbrowser.open("127.0.0.1:8080") with IE, but the behavior seems consistent in all the versions, so it's not a regression.

----------
nosy: +ezio.melotti, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8936>
_______________________________________

From report at bugs.python.org  Tue Jun  8 06:30:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 04:30:23 +0000
Subject: [issue7989] Transition time/datetime C modules to Python
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1275971423.86.0.152874870533.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Brett,

Thanks for your explanation.  It looks like I misunderstood the proposal.  I though the idea was to have some methods of e.g. date type implemented in python and some in C.  What you propose is much simpler.  Effectively, your proposal is "let's distribute a pure python implementation of datetime with CPython."  I don't have any problem with this.  Patches welcome!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Tue Jun  8 06:42:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 04:42:09 +0000
Subject: [issue7989] Add pure Python implementation of datetime module to
	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1275972129.18.0.105396192759.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am changing the title to match Brett's explanation better.  Note that since the time module is a thin wrapper around C library calls, it falls under inherently relying on C code exception.

----------
title: Transition time/datetime C modules to Python -> Add pure Python implementation of datetime module to CPython

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Tue Jun  8 07:38:54 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 08 Jun 2010 05:38:54 +0000
Subject: [issue8937] SimpleHTTPServer should contain usage example
In-Reply-To: <1275975534.8.0.563527396515.issue8937@psf.upfronthosting.co.za>
Message-ID: <1275975534.8.0.563527396515.issue8937@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Currently SimpleHTTPServer docs contains phrase "For example usage, see the implementation of the test() function." with no reference where this test() function is located. This is not user friendly.

----------
assignee: docs at python
components: Documentation
messages: 107304
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: SimpleHTTPServer should contain usage example
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8937>
_______________________________________

From report at bugs.python.org  Tue Jun  8 07:40:13 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 08 Jun 2010 05:40:13 +0000
Subject: [issue8936] webbrowser regression on windows
In-Reply-To: <1275968801.71.0.456370362373.issue8936@psf.upfronthosting.co.za>
Message-ID: <1275975613.66.0.903556858614.issue8936@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

2.5 threw exception

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8936>
_______________________________________

From report at bugs.python.org  Tue Jun  8 08:25:22 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 08 Jun 2010 06:25:22 +0000
Subject: [issue8936] webbrowser regression on windows
In-Reply-To: <1275968801.71.0.456370362373.issue8936@psf.upfronthosting.co.za>
Message-ID: <1275978322.02.0.942535651805.issue8936@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

webbrowser.open("%s:%s" % (HOST,PORT))
  File "C:\Python25\lib\webbrowser.py", line 61, in open
    if browser.open(url, new, autoraise):
  File "C:\Python25\lib\webbrowser.py", line 518, in open
    os.startfile(url)
WindowsError: [Error -2147217406] Windows Error 0x80041002: '127.0.0.1:8080'


I do not mind if new Python would handle this exception correctly, but it doesn't launching wrong browser. If I specify "http://" prefix - the Chrome launched as expected. Note that if "127.0.0.1:8080" is executed from shell (search menu or run dialog) - IE is not started by Vista.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8936>
_______________________________________

From report at bugs.python.org  Tue Jun  8 10:00:07 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 08 Jun 2010 08:00:07 +0000
Subject: [issue8838] Remove
	codecs.readbuffer_encode()	and	codecs.charbuffer_encode()
In-Reply-To: <1275950926.09.0.370952171389.issue8838@psf.upfronthosting.co.za>
Message-ID: <4C0DF883.7000409@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:
> 
> MAL agreed to remove "t#" parsing format (#8839), whereas charbuffer_encode() main goal was to offer "t#" parsing format to Python object space. charbuffer_encode() is now useless in Python3. bytes() accepts any buffer object (read-only and read/write buffer), so readbuffer_encode() became useless in Python3.
> 
> readbuffer_encode() and charbuffer_encode() were never documented, and are not used by any 3rd party library.
> 
> Can we remove these two functions?

Like I said before:

We can remore charbuffer_encode() now and perhaps
add it again later on when buffers have learned (again) to
provide access to a text version of their data. In this
case, we'd likely add t# back again as well.

Please leave readbuffer_encode() as-is.

----------
title: Remove codecs.readbuffer_encode() and	codecs.charbuffer_encode() -> Remove codecs.readbuffer_encode()	and	codecs.charbuffer_encode()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Tue Jun  8 10:02:38 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 08 Jun 2010 08:02:38 +0000
Subject: [issue7989] Transition time/datetime C modules to Python
In-Reply-To: <1275958729.6.0.0895274034574.issue7989@psf.upfronthosting.co.za>
Message-ID: <4C0DF91B.8030206@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Brett Cannon wrote:
> 
> Brett Cannon <brett at python.org> added the comment:
> 
> So I see a couple of objections here to the idea that I will try to address.
> 
> First is MAL's thinking that this will undo any C code, which it won't. The idea is that stdlib modules that do not inherently rely on other C code (e.g. sqlite3 does not fall underneath this) would have a pure Python implementation with possible C enhancements. In the case of datetime that  code is done, so it won't go anywhere. In this case it would be bringing in a pure Python implementation like the one PyPy maintains. You can look at heapq if you want an existing example of what it looks like to maintain a pure Python and C version of a module.

So the proposal is to have something like we have for pickle, with
cPickle being the fast version and pickle.py the slow Python one ?

Since no CPython would use the Python version, who would be supporting
the Python-only version ?

----------
title: Add pure Python implementation of datetime module to CPython -> Transition time/datetime C modules to Python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Tue Jun  8 10:20:29 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 08 Jun 2010 08:20:29 +0000
Subject: [issue7989] Add pure Python implementation of datetime module to
	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1275985229.78.0.299020151087.issue7989@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Oops, sorry. Looks like the Roundup email interface changed the ticket
title back to the old one again (I was replying to Brett's comment under the old title).

----------
title: Transition time/datetime C modules to Python -> Add pure Python implementation of datetime module to CPython

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Tue Jun  8 12:49:38 2010
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 08 Jun 2010 10:49:38 +0000
Subject: [issue7839] Popen should raise ValueError if pass a string when
	shell=False or a list when shell=True
In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za>
Message-ID: <1275994178.84.0.269591995907.issue7839@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

I noticed this a while ago.  And FWIW it's not just 3.x; I see this same behavior in 2.6.

I've whipped up a test case, attached, which runs in both Python 2 and Python 3.  The test runs "sys.interpreter -V" four times: it tries all the combinations of shell=True/False and the cmdline argument as either a list or a string.

When shell=True and cmdline is an array, Python runs as an interactive shell.  (You have to press Ctrl-D to close it; the test warns you this is happening.)
When shell=False and cmdline is a string, Python raises OSError, "[Errno 2] No such file or directory".
In the other two cases the code runs correctly, producing the version number of Python.

The test would probably be better if I used stdin=PIPE too, so you didn't have to press Ctrl-D.  But I couldn't figure out how to make it produce the interactive session stuff when I did that.  Anyway, it wouldn't be hard to make this into a proper regression test.

My two cents: I assume from the discussion that this is not fixable; that is, it's not possible to have a shell and a string, or no shell and a list.  Failing that, the right decision is what R. David discussed on 2010-02-28: ignore the shell argument passed in and infer it ourselves from whether cmdline is a list or a string.  I don't buy the security argument--since the invalid combinations of shell and cmdline mean the function doesn't work, existing callers have already made the decision whether they can live with shell=True.  We should deprecate the shell argument and update the documentation to make the behavior crystal clear.

----------
nosy: +larry
Added file: http://bugs.python.org/file17587/test_subprocess.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7839>
_______________________________________

From report at bugs.python.org  Tue Jun  8 12:51:05 2010
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 08 Jun 2010 10:51:05 +0000
Subject: [issue7839] Popen should raise ValueError if pass a string when
	shell=False or a list when shell=True
In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za>
Message-ID: <1275994265.23.0.886712141673.issue7839@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

I realize we're down to the wire, but would it be too late to fix this in 2.7?  It is a genuine bug, and it won't break any correct code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7839>
_______________________________________

From report at bugs.python.org  Tue Jun  8 12:51:25 2010
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 08 Jun 2010 10:51:25 +0000
Subject: [issue7839] Popen should raise ValueError if pass a string when
	shell=False or a list when shell=True
In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za>
Message-ID: <1275994285.58.0.408569276364.issue7839@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7839>
_______________________________________

From report at bugs.python.org  Tue Jun  8 13:06:07 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Jun 2010 11:06:07 +0000
Subject: [issue7989] Add pure Python implementation of datetime module to
	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1275995167.5.0.973900862348.issue7989@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Even from pypy perspective, a pure python implementation is not ideal because it makes it difficult to implement the C API.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Tue Jun  8 13:11:47 2010
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 08 Jun 2010 11:11:47 +0000
Subject: [issue7839] Popen should raise ValueError if pass a string when
	shell=False or a list when shell=True
In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za>
Message-ID: <1275995507.79.0.712291403351.issue7839@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Sorry for spamming updates, but here's two more things to consider.

1) What does it do on Windows?  For all I know all four combinations work fine there and we should preserve the existing functionality.

2) All four combinations work fine if you call a program without arguments.  I tried it with both "/bin/ls" and sys.executable and it worked like a champ.  The problem *only* happens if you specify command-line arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7839>
_______________________________________

From report at bugs.python.org  Tue Jun  8 13:34:32 2010
From: report at bugs.python.org (Pavel Denisow)
Date: Tue, 08 Jun 2010 11:34:32 +0000
Subject: [issue8938] Mac OS  dialogs(Save As..., Load) translation
In-Reply-To: <1275996872.25.0.17428013193.issue8938@psf.upfronthosting.co.za>
Message-ID: <1275996872.25.0.17428013193.issue8938@psf.upfronthosting.co.za>


New submission from Pavel Denisow <denisov at ext.panasonic.ru>:

We have a problem with using native Mac OS dialogs (Save As..., Load) on Russian Mac:
Dialogs are not translated even with file-translation. See attached screenshots.
Same code in Linux works perfect. C++ QT project in Mac has translation in native dialogs.
Test project on python and PyQT contains not-translated dialogs.
For tk and EasyDialogs result is the same - not translated.

Mac OS: 10.5.2, Russian locale.
Python: 2.5.1


PyQt test project
----------------------------------------
from PyQt4 import QtGui, QtCore


app = QtGui.QApplication(sys.argv)

QtGui.QFileDialog().getSaveFileName()
QtGui.QFileDialog().getOpenFileName()

sys.exit(app.exec_())
----------------------------------------




tk test project
----------------------------------------
from tkCommonDialog import Dialog


class OpenDialog(Dialog):
    command = "tk_getOpenFile"
class SaveDialog(Dialog):
    command = "tk_getSaveFile"


OpenDialog().show()
SaveDialog().show()
----------------------------------------



EasyDialogs test project
----------------------------------------
import EasyDialogs

EasyDialogs.AskFileForSave()
EasyDialogs.AskFileForOpen()
----------------------------------------

----------
assignee: ronaldoussoren
components: Macintosh, Unicode
files: filedialogs_mac.zip
messages: 107314
nosy: Pavel.Denisow, ronaldoussoren
priority: normal
severity: normal
status: open
title: Mac OS  dialogs(Save As..., Load) translation
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file17588/filedialogs_mac.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8938>
_______________________________________

From report at bugs.python.org  Tue Jun  8 13:34:52 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Jun 2010 11:34:52 +0000
Subject: [issue3173] external strftime for Python?
In-Reply-To: <1214189093.82.0.548435251403.issue3173@psf.upfronthosting.co.za>
Message-ID: <1275996892.44.0.572744035683.issue3173@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

PyPy also calls the platform's strftime().

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3173>
_______________________________________

From report at bugs.python.org  Tue Jun  8 13:42:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 08 Jun 2010 11:42:37 +0000
Subject: [issue7839] Popen should raise ValueError if pass a string when
	shell=False or a list when shell=True
In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za>
Message-ID: <1275997357.1.0.0820334208597.issue7839@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Unless we go the proliferating-interfaces route, it does represent a behavior change, and so if accepted would need to go through a deprecation cycle.  And if we did go that route, it would be a new feature.  So nothing can happen in 2.7, since it is already in the RC stage.

By the way, I did not suggest dropping the shell parameter, I argued against doing that.  The 'security' I referred to is that when you use a shell you are subject to shell-metacharacter-based attacks (and bugs!) if any elements of the command line come from user input and you don't sanitize them.  This problem doesn't exist with shell=False, which is why it is the default.

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7839>
_______________________________________

From report at bugs.python.org  Tue Jun  8 14:27:15 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 08 Jun 2010 12:27:15 +0000
Subject: [issue7989] Add pure Python implementation of datetime module to
	CPython
In-Reply-To: <1275995167.5.0.973900862348.issue7989@psf.upfronthosting.co.za>
Message-ID: <AANLkTiln_QYfYbvBBaQHK_04lz7HxK-tVmjvCt0Z6w6v@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Tue, Jun 8, 2010 at 2:06 PM, Amaury Forgeot d'Arc
<report at bugs.python.org> wrote:
>
> Even from pypy perspective, a pure python implementation is not ideal because it makes it difficult to implement the C API.

C API
must die
a shadow of Go

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Tue Jun  8 14:42:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Jun 2010 12:42:17 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode()	and
	codecs.charbuffer_encode()
In-Reply-To: <4C0DF883.7000409@egenix.com>
Message-ID: <1276000933.3197.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Please leave readbuffer_encode() as-is.

Then please add documentation for it.

----------
title: Remove codecs.readbuffer_encode()	and	codecs.charbuffer_encode() -> Remove codecs.readbuffer_encode()	and codecs.charbuffer_encode()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Tue Jun  8 14:44:29 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 08 Jun 2010 12:44:29 +0000
Subject: [issue8838] Remove
	codecs.readbuffer_encode()	and	codecs.charbuffer_encode()
In-Reply-To: <1276000933.3197.0.camel@localhost.localdomain>
Message-ID: <4C0E3B2A.80500@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> Please leave readbuffer_encode() as-is.
> 
> Then please add documentation for it.

Will do.

----------
title: Remove codecs.readbuffer_encode()	and codecs.charbuffer_encode() -> Remove codecs.readbuffer_encode()	and	codecs.charbuffer_encode()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Tue Jun  8 15:14:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Jun 2010 13:14:36 +0000
Subject: [issue8939] Use C type names (PyUnicode etc;) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Following r81811 (and issue8925), perhaps we should start using e.g. PyUnicode, PyBytes, PyLong, etc. in the C API docs to more closely follow the C API rather than use the type names you see at the Python level.

----------
assignee: haypo
components: Documentation
messages: 107320
nosy: haypo, lemburg, pitrou
priority: normal
severity: normal
status: open
title: Use C type names (PyUnicode etc;) in the C API docs
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8939>
_______________________________________

From report at bugs.python.org  Tue Jun  8 15:14:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Jun 2010 13:14:51 +0000
Subject: [issue8939] Use C type names (PyUnicode etc;) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276002891.85.0.456830904853.issue8939@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8939>
_______________________________________

From report at bugs.python.org  Tue Jun  8 15:23:16 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 08 Jun 2010 13:23:16 +0000
Subject: [issue8940] *HTTPServer need a summary page with API inheritance table
In-Reply-To: <1276003396.33.0.469317406109.issue8940@psf.upfronthosting.co.za>
Message-ID: <1276003396.33.0.469317406109.issue8940@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

The abundance of methods and hierarchy depth of various servers from "Internet Protocols and Support" section makes it extremely hard to navigate information. You need a strong OOP background to be able to use this doc effectively, as examples are not intuitive otherwise.

Usually you need a decent IDE (such as Eclipse) to get a picture of class hierarchy and a table of all available methods with a mark where they were inherited from.

Such table (at least Class Hierarchy view screenshot from Eclipse) should be available in reference for descendant classes.

----------
assignee: docs at python
components: Documentation
messages: 107321
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: *HTTPServer need a summary page with API inheritance table
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8940>
_______________________________________

From report at bugs.python.org  Tue Jun  8 15:30:28 2010
From: report at bugs.python.org (Zsolt Cserna)
Date: Tue, 08 Jun 2010 13:30:28 +0000
Subject: [issue7839] Popen should raise ValueError if pass a string when
	shell=False or a list when shell=True
In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za>
Message-ID: <1276003828.03.0.06057422021.issue7839@psf.upfronthosting.co.za>


Zsolt Cserna <zsolt.cserna at morganstanley.com> added the comment:

I would say that both string and list should be accepted in args, and depending on the shell parameter, the module should create a list or a string from the specified list/string.

We already have a list2cmdline function to convert a list to string, we would only need to create the inverse of this function to convert a string to a list.

Executing a program whose parameters are coming from external source (eg. user input) can result security problems if those are not specified as a list and in this case I would be really happy to specify my parameters as a list to Popen and it would do the appropriate conversions as above.

----------
nosy: +csernazs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7839>
_______________________________________

From report at bugs.python.org  Tue Jun  8 16:15:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 14:15:29 +0000
Subject: [issue6641] strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276006529.77.0.872351001582.issue6641@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
dependencies: +datetime lacks concrete tzinfo impl. for UTC
stage:  -> unit test needed
type: behavior -> feature request
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Tue Jun  8 16:36:39 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 08 Jun 2010 14:36:39 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1276007799.26.0.507324011602.issue7384@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Committed in r81669,r81672,r81683 (trunk) and r81830,81831 (py3k).


What to do with the releases? To recap, the fix is:

  1) Detect if readline is already linked against ncurses and
     if so, skip any further selection. This must be done.

  2) Use the same version of ncurses for readline.so and _curses.so.


1) should be done in any case. 2) could change the behavior for
users who previously had readline/ncurses, cursesmodule/ncursesw,
but only use the cursesmodule in an application.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Tue Jun  8 17:08:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Jun 2010 15:08:22 +0000
Subject: [issue8850] Remove "w" format of PyParse_ParseTuple()
In-Reply-To: <1275099860.74.0.46695580149.issue8850@psf.upfronthosting.co.za>
Message-ID: <1276009702.5.0.4058713571.issue8850@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8850>
_______________________________________

From report at bugs.python.org  Tue Jun  8 17:09:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Jun 2010 15:09:59 +0000
Subject: [issue8850] Remove "w" format of PyParse_ParseTuple()
In-Reply-To: <1275099860.74.0.46695580149.issue8850@psf.upfronthosting.co.za>
Message-ID: <1276009799.52.0.936034318773.issue8850@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'd point out that "w#" is mostly useless too. It's supposed to return a read-write buffer, but as the doc says it also doesn't support "mutable objects", since it isn't able to properly lock/pin the buffer; therefore it probably doesn't support anything useful.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8850>
_______________________________________

From report at bugs.python.org  Tue Jun  8 18:09:49 2010
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 08 Jun 2010 16:09:49 +0000
Subject: [issue7768] raw_input should encode unicode prompt with
	std.stdout.encoding.
In-Reply-To: <1264309924.17.0.144254143298.issue7768@psf.upfronthosting.co.za>
Message-ID: <1276013389.75.0.853151053062.issue7768@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

I agree to close this bug without fix.
I hope that Python3 will be mainstream soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7768>
_______________________________________

From report at bugs.python.org  Tue Jun  8 18:14:58 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 08 Jun 2010 16:14:58 +0000
Subject: [issue7768] raw_input should encode unicode prompt with
	std.stdout.encoding.
In-Reply-To: <1264309924.17.0.144254143298.issue7768@psf.upfronthosting.co.za>
Message-ID: <1276013698.97.0.454919156036.issue7768@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7768>
_______________________________________

From report at bugs.python.org  Tue Jun  8 18:15:24 2010
From: report at bugs.python.org (Dave Opstad)
Date: Tue, 08 Jun 2010 16:15:24 +0000
Subject: [issue8941] utf-32be codec failing on 16-bit python build for 32-bit
	value
In-Reply-To: <1276013724.21.0.174818104611.issue8941@psf.upfronthosting.co.za>
Message-ID: <1276013724.21.0.174818104611.issue8941@psf.upfronthosting.co.za>


New submission from Dave Opstad <dave.opstad at monotypeimaging.com>:

The utf-32 little-endian codec works fine, but the big-endian codec is producing incorrect results:

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.
>>> str(b'\x00\x00\x01\x00', 'utf-32le') # works
'\U00010000'
>>> str(b'\x00\x01\x00\x00', 'utf-32be') # doesn't work
'\ud800\x02'

----------
components: Unicode
messages: 107326
nosy: opstad
priority: normal
severity: normal
status: open
title: utf-32be codec failing on 16-bit python build for 32-bit value
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8941>
_______________________________________

From report at bugs.python.org  Tue Jun  8 18:15:32 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 08 Jun 2010 16:15:32 +0000
Subject: [issue8942] __path__ attribute of modules loaded by zipimporter is
	untested
In-Reply-To: <1276013732.57.0.515191754786.issue8942@psf.upfronthosting.co.za>
Message-ID: <1276013732.57.0.515191754786.issue8942@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at twistedmatrix.com>:

Packages loaded from zip files have a __path__ sort of like any other package.  The zipimport tests don't verify that this attribute has the correct value, though.

----------
components: Tests
messages: 107327
nosy: exarkun
priority: normal
severity: normal
status: open
title: __path__ attribute of modules loaded by zipimporter is untested

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8942>
_______________________________________

From report at bugs.python.org  Tue Jun  8 18:24:23 2010
From: report at bugs.python.org (Fabio Zadrozny)
Date: Tue, 08 Jun 2010 16:24:23 +0000
Subject: [issue8943] Bug in InteractiveConsole
In-Reply-To: <1276014263.34.0.524334073977.issue8943@psf.upfronthosting.co.za>
Message-ID: <1276014263.34.0.524334073977.issue8943@psf.upfronthosting.co.za>


New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:

Unable to pickle classes used in the InteractiveConsole. The code attached works in python 2.5 and fails on python 3.1.2.

----------
components: Library (Lib)
files: fast_test.py
messages: 107328
nosy: fabioz
priority: normal
severity: normal
status: open
title: Bug in InteractiveConsole
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file17589/fast_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8943>
_______________________________________

From report at bugs.python.org  Tue Jun  8 18:40:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 16:40:30 +0000
Subject: [issue6641] strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276015230.56.0.759499586588.issue6641@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch includes issue 5094 patch.

----------
keywords: +patch
nosy: +mark.dickinson
stage: unit test needed -> commit review
Added file: http://bugs.python.org/file17590/issue6641.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Tue Jun  8 19:35:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 17:35:07 +0000
Subject: [issue2651] Strings passed to KeyError do not round trip
In-Reply-To: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za>
Message-ID: <1276018507.62.0.145425768715.issue2651@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

KeyError.patch is out of date.  Is anyone motivated enough to update it for py3k?  I like the idea, but don't have spare cycles at the moment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2651>
_______________________________________

From report at bugs.python.org  Tue Jun  8 19:59:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 17:59:04 +0000
Subject: [issue8902] add datetime.time.now() for consistency
In-Reply-To: <1275719789.45.0.168425659941.issue8902@psf.upfronthosting.co.za>
Message-ID: <1276019944.53.0.915496597645.issue8902@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Anatoly,

msg107191 belongs to issue8903, not here and it is not a use case, but rather a demonstration of how the proposed feature would work.

My question is why would an application need current time without current date?  I feel providing time.now() may lead so people to call date.today() and time.now() separately instead of datetime.now() leading to interesting bugs.

One think I would consider an improvement over the current situation, would be to rename date.today() to date.now().  There are too many ways to spell the same thing:

date.today()
datetime.today()
datetime.now().date()

and no easy way to write a "how long ago" function that would work for both date and datetime:

def ago(t):
    t.now() - t

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8902>
_______________________________________

From report at bugs.python.org  Tue Jun  8 20:07:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 18:07:57 +0000
Subject: [issue8903] Add module level now() and today() functions to datetime
	module
In-Reply-To: <1275720507.31.0.185559003971.issue8903@psf.upfronthosting.co.za>
Message-ID: <1276020477.54.0.488524033701.issue8903@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Note that it is important to keep class methods because in some cases it is convenient to obtain now/today from datetime/date instances instead of importing them from the module.  So deprecating class methods is not an option and adding module level functions that are equivalent to existing class methods is not TOOWTDI.

----------
resolution:  -> rejected
status: open -> pending
title: datetime functions -> Add module level now() and today() functions to datetime module
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8903>
_______________________________________

From report at bugs.python.org  Tue Jun  8 20:09:38 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 08 Jun 2010 18:09:38 +0000
Subject: [issue7989] Add pure Python implementation of datetime module to
	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276020578.25.0.642954542569.issue7989@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So yes, cPickle/pickle, cStringIO/StringIO, heapq, etc. are all examples of the approach. One could choose to write the pure Python version first, profile the code, and only write extension code for the hot spots, but obviously that typically doesn't happen.

As for who maintains it, that's python-dev, just like every other module that is structured like this. When the stdlib gets more of a clear separation from CPython I suspect the other VM maintainers will contribute more.

As for PyPy not specifically needing this, that still doesn't solve the problem that Jython and IronPython have with extension code or any other future VM that doesn't try to come up with a solution for extensions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Tue Jun  8 20:29:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 18:29:14 +0000
Subject: [issue8907] time module documentation differs in trunk and py3k
In-Reply-To: <1275752348.33.0.507552521147.issue8907@psf.upfronthosting.co.za>
Message-ID: <1276021754.11.0.911361105469.issue8907@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

There seems to be a few legitimate differences such as "int or long" vs. integer, or parenthesis for print.  Patch is forthcoming.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8907>
_______________________________________

From report at bugs.python.org  Tue Jun  8 20:34:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 18:34:09 +0000
Subject: [issue8907] time module documentation differs in trunk and py3k
In-Reply-To: <1275752348.33.0.507552521147.issue8907@psf.upfronthosting.co.za>
Message-ID: <1276022049.91.0.806183097212.issue8907@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

.. also 3.x does not track versionadded from 2.x

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8907>
_______________________________________

From report at bugs.python.org  Tue Jun  8 20:39:07 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Jun 2010 18:39:07 +0000
Subject: [issue8907] time module documentation differs in trunk and py3k
In-Reply-To: <1275752348.33.0.507552521147.issue8907@psf.upfronthosting.co.za>
Message-ID: <1276022347.86.0.0506147725704.issue8907@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r81489 should probably also be svnmerged to py3k before applying this doc change.  (As far as I can tell, this is the only outstanding unmerged trunk change.)

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8907>
_______________________________________

From report at bugs.python.org  Tue Jun  8 20:57:13 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 08 Jun 2010 18:57:13 +0000
Subject: [issue8944] test_winreg.test_reflection_functions fails on Windows
	Server 2003
In-Reply-To: <1276023433.0.0.59191647284.issue8944@psf.upfronthosting.co.za>
Message-ID: <1276023433.0.0.59191647284.issue8944@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

The key/subkey used in this test causes a failure when run on Windows Server 2003 x64.

----------
assignee: brian.curtin
components: Tests, Windows
messages: 107337
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: test_winreg.test_reflection_functions fails on Windows Server 2003
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8944>
_______________________________________

From report at bugs.python.org  Tue Jun  8 21:11:30 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Jun 2010 19:11:30 +0000
Subject: [issue8945] Bug in **kwds expansion on call?
In-Reply-To: <1276024245.06.0.703861128554.issue8945@psf.upfronthosting.co.za>
Message-ID: <1276024245.06.0.703861128554.issue8945@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

In 2.6, the requirement for **kwds keyword argument expansion in calls (LangRef 5.3.4. Calls) is relaxed from "(subclass of) dictionary" (2.5) to "mapping".  The requirement in this context for 'mapping' is not specified. LRef3.2 merely says "The subscript notation a[k]  selects the item indexed by k from the mapping a;". Here, .keys seems to be needed in addition to .__getitem__. (.items alone does not make an object a mapping.)

In python-list thread "Which objects are expanded by double-star ** operator?", Peter Otten posted 2.6 results for

class A(object):
     def keys(self): return list("ab")
     def __getitem__(self, key):
         return 42
        
class B(dict):
     def keys(self): return list("ab")
     def __getitem__(self, key):
         return 42

def f(**kw):
     print(kw)

f(**A())
# {'a': 42, 'b': 42}

b = B(); print(b['a'], b['b']) # I added this
# 42, 42
f(**b)
# {}

I get same with 3.1. It appears .keys() is called in the first case, but not the second, possibly due to an internal optimization.

The different of outcome seems like a bug, though one could argue that the doc is so vague that it makes no promise to be broken.

----------
components: Interpreter Core
messages: 107338
nosy: tjreedy
priority: normal
severity: normal
status: open
title: Bug in **kwds expansion on call?
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/issue8945>
_______________________________________

From report at bugs.python.org  Tue Jun  8 21:57:44 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 08 Jun 2010 19:57:44 +0000
Subject: [issue8832] automate minidom.unlink() with a context manager
In-Reply-To: <1274965382.14.0.210712489615.issue8832@psf.upfronthosting.co.za>
Message-ID: <1276027064.73.0.219036495005.issue8832@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Any comments?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8832>
_______________________________________

From report at bugs.python.org  Tue Jun  8 22:16:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 20:16:53 +0000
Subject: [issue614557] LookupError etc. need API to get the key
Message-ID: <1276028213.53.0.600337212199.issue614557@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It looks like issue2651 is the first step for this.  See msg66432. I am merging the nosy lists.

----------
assignee:  -> belopolsky
dependencies: +Strings passed to KeyError do not round trip
nosy: +amaury.forgeotdarc, belopolsky, pitrou, rharris
stage:  -> needs patch
type:  -> feature request
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue614557>
_______________________________________

From report at bugs.python.org  Tue Jun  8 22:25:08 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Tue, 08 Jun 2010 20:25:08 +0000
Subject: [issue8832] automate minidom.unlink() with a context manager
In-Reply-To: <1274965382.14.0.210712489615.issue8832@psf.upfronthosting.co.za>
Message-ID: <1276028708.54.0.516883681838.issue8832@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

+1

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8832>
_______________________________________

From report at bugs.python.org  Tue Jun  8 22:25:46 2010
From: report at bugs.python.org (Dave Opstad)
Date: Tue, 08 Jun 2010 20:25:46 +0000
Subject: [issue8946] PyBuffer_Release signature in 3.1 documentation is
	incorrect
In-Reply-To: <1276028746.19.0.698782351102.issue8946@psf.upfronthosting.co.za>
Message-ID: <1276028746.19.0.698782351102.issue8946@psf.upfronthosting.co.za>


New submission from Dave Opstad <dave.opstad at monotypeimaging.com>:

According to the 3.1 documentation, the prototype for PyBuffer_Release is:

void PyBuffer_Release(PyObject *obj, Py_buffer *view);

However, abstract.h has this prototype:

PyAPI_FUNC(void) PyBuffer_Release(Py_buffer *view);

The documentation's reference to "obj" should be removed.

----------
assignee: docs at python
components: Documentation
messages: 107342
nosy: docs at python, opstad
priority: normal
severity: normal
status: open
title: PyBuffer_Release signature in 3.1 documentation is incorrect
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8946>
_______________________________________

From report at bugs.python.org  Tue Jun  8 22:29:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 20:29:13 +0000
Subject: [issue836035] strftime month name is encoded somehow
Message-ID: <1276028953.78.0.4212172152.issue836035@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Is this still an issue in 3.x?  With time.strftime() returning unicode, I don't think any encoding issues remain.

----------
assignee:  -> belopolsky
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue836035>
_______________________________________

From report at bugs.python.org  Tue Jun  8 22:33:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 20:33:47 +0000
Subject: [issue887237] Machine integers
Message-ID: <1276029227.47.0.170448977491.issue887237@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
components: +Extension Modules, ctypes -Library (Lib)
nosy:  -Alexander.Belopolsky
stage:  -> patch review
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue887237>
_______________________________________

From report at bugs.python.org  Tue Jun  8 22:38:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jun 2010 20:38:41 +0000
Subject: [issue7768] raw_input should encode unicode prompt with
	std.stdout.encoding.
In-Reply-To: <1264309924.17.0.144254143298.issue7768@psf.upfronthosting.co.za>
Message-ID: <1276029521.34.0.325920800762.issue7768@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I hope that Python3 will be mainstream soon.

What do you mean by "mainstream"? Python3 is available in Ubuntu (since Karmic), Fedora 13, Mandriva 2010.0, Gentoo, Debian (only Sid for now), ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7768>
_______________________________________

From report at bugs.python.org  Tue Jun  8 22:51:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 20:51:08 +0000
Subject: [issue8947] Provide  as_integer_ratio() method to Decimal
In-Reply-To: <1276030268.17.0.98739433208.issue8947@psf.upfronthosting.co.za>
Message-ID: <1276030268.17.0.98739433208.issue8947@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Here is my use case: recently implemented timedelta * float operation starts with converting float to an int ratio.  The same algorithm can be used for decimals, but they don't support as_integer_ratio().

----------
components: Extension Modules
messages: 107345
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Provide  as_integer_ratio() method to Decimal
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8947>
_______________________________________

From report at bugs.python.org  Tue Jun  8 22:55:25 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 08 Jun 2010 20:55:25 +0000
Subject: [issue8948] cleanup functions are not executed with
	unittest.TestCase.debug()
In-Reply-To: <1276030525.65.0.633421030518.issue8948@psf.upfronthosting.co.za>
Message-ID: <1276030525.65.0.633421030518.issue8948@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Also class / module tearDowns are not executed with TestSuite.debug()

----------
assignee: michael.foord
components: Library (Lib)
messages: 107346
nosy: michael.foord
priority: normal
severity: normal
status: open
title: cleanup functions are not executed with unittest.TestCase.debug()
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8948>
_______________________________________

From report at bugs.python.org  Tue Jun  8 23:07:19 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 08 Jun 2010 21:07:19 +0000
Subject: [issue8945] Bug in **kwds expansion on call?
In-Reply-To: <1276024245.06.0.703861128554.issue8945@psf.upfronthosting.co.za>
Message-ID: <1276031239.42.0.800256573419.issue8945@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This falls under the usual category of dict subclasses not having their methods called. Especially since the B dict doesn't actually contain anything.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8945>
_______________________________________

From report at bugs.python.org  Tue Jun  8 23:10:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Jun 2010 21:10:31 +0000
Subject: [issue8947] Provide  as_integer_ratio() method to Decimal
In-Reply-To: <1276030268.17.0.98739433208.issue8947@psf.upfronthosting.co.za>
Message-ID: <1276031431.84.0.685201384686.issue8947@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This seems like a reasonable request to me;  I'd like to see a little bit of convergence between the float and Decimal APIs.

One difference between the two types that's worth noting is that the float.as_integer_ratio() method can never take a ridiculous amount of time or memory, whereas Decimal.as_integer_ratio() could:  e.g., consider Decimal('1e999999999').as_integer_ratio().  But I don't really see that as a problem.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8947>
_______________________________________

From report at bugs.python.org  Tue Jun  8 23:14:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 08 Jun 2010 21:14:12 +0000
Subject: [issue8832] automate minidom.unlink() with a context manager
In-Reply-To: <1274965382.14.0.210712489615.issue8832@psf.upfronthosting.co.za>
Message-ID: <1276031652.44.0.294682630993.issue8832@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good to me.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8832>
_______________________________________

From report at bugs.python.org  Tue Jun  8 23:15:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 08 Jun 2010 21:15:48 +0000
Subject: [issue8832] automate minidom.unlink() with a context manager
In-Reply-To: <1274965382.14.0.210712489615.issue8832@psf.upfronthosting.co.za>
Message-ID: <1276031748.43.0.129005673291.issue8832@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The test passes if __exit__ doesn't call unlink.  Otherwise the patch looks good to me.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8832>
_______________________________________

From report at bugs.python.org  Tue Jun  8 23:18:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Jun 2010 21:18:45 +0000
Subject: [issue8947] Provide  as_integer_ratio() method to Decimal
In-Reply-To: <1276030268.17.0.98739433208.issue8947@psf.upfronthosting.co.za>
Message-ID: <1276031925.31.0.198945973528.issue8947@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8947>
_______________________________________

From report at bugs.python.org  Tue Jun  8 23:23:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jun 2010 21:23:23 +0000
Subject: [issue8949] PyArg_Parse*(): "z" should not accept bytes
In-Reply-To: <1276032203.54.0.364398342729.issue8949@psf.upfronthosting.co.za>
Message-ID: <1276032203.54.0.364398342729.issue8949@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

"z" is supposed to be the same format than "s" but accepts None.... Except that "z" does also accept bytes. I suppose that "s" was "fixed" between Python2 and Python3, but "z" is not fixed yet.

I think that it can be fixed in Python 3.2 without any deprecation process.

----------
components: Interpreter Core
messages: 107351
nosy: haypo
priority: normal
severity: normal
status: open
title: PyArg_Parse*(): "z" should not accept bytes
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8949>
_______________________________________

From report at bugs.python.org  Tue Jun  8 23:24:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jun 2010 21:24:15 +0000
Subject: [issue8949] PyArg_Parse*(): "z" should not accept bytes
In-Reply-To: <1276032203.54.0.364398342729.issue8949@psf.upfronthosting.co.za>
Message-ID: <1276032255.14.0.176353402463.issue8949@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file17591/pyarg_z_no_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8949>
_______________________________________

From report at bugs.python.org  Tue Jun  8 23:42:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Jun 2010 21:42:48 +0000
Subject: [issue8950] In getargs.c,
	make 'L' code raise TypeError for float arguments.
In-Reply-To: <1276033368.49.0.876712618605.issue8950@psf.upfronthosting.co.za>
Message-ID: <1276033368.49.0.876712618605.issue8950@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Currently all but one of the integer format codes for getargs.c raise TypeError when passed a float.  The 'L' code produces a warning rather than raising an error.

This was deliberate at the time, because all except the 'L' code already raised a DeprecationWarning in Python 3.1, and were converted to raise TypeError for 3.2.  Since the 'L' code didn't raise a warning for float inputs in 3.1, directly raising a TypeError in 3.2 seemed a bit abrupt.

However, I'd like to revisit this decision, and make the 'L' code raise a TypeError in 3.2.  Note that

(1) The 'L' code represents the Py_LONG_LONG type, and isn't used very much;  I think the risk of unexpected breakage from this change is fairly small.

(2) One of the places that the 'L' code *is* used is when parsing strange C types (like off_t) that are matched with either size_t, long or long long at configure + build time.  So one platform might end up parsing off_t types with the 'n' code, while another parses them with the 'L' code.  It would be desirable for both platforms to have the same behaviour when passed a float.

Any objections to making this change?

See also issue 5080.

----------
assignee: mark.dickinson
components: Interpreter Core
messages: 107352
nosy: haypo, mark.dickinson
priority: normal
severity: normal
status: open
title: In getargs.c, make 'L' code raise TypeError for float arguments.
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8950>
_______________________________________

From report at bugs.python.org  Tue Jun  8 23:45:39 2010
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 08 Jun 2010 21:45:39 +0000
Subject: [issue7839] Popen should raise ValueError if pass a string when
	shell=False or a list when shell=True
In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za>
Message-ID: <1276033539.04.0.311365993607.issue7839@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Zsolt: an excellent idea!  That shouldn't change the semantics of the function, and therefore is strictly a bug fix.  Which means we could potentially backport it, yes?

Obviously we only need to change it between string / list if we're going to have this problem, and that only happens when there are parameters.  So the change could be very narrow in scope.  Lovely!

R. David: Why did you remove Python 2.7 from the list?  We see the behavior there too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7839>
_______________________________________

From report at bugs.python.org  Tue Jun  8 23:57:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jun 2010 21:57:42 +0000
Subject: [issue8950] In getargs.c,
	make 'L' code raise TypeError for float arguments.
In-Reply-To: <1276033368.49.0.876712618605.issue8950@psf.upfronthosting.co.za>
Message-ID: <1276034262.58.0.704700895441.issue8950@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> One of the places that the 'L' code *is* used is when parsing
> strange C types (like off_t)

It has unexepected consequences. Example:

   >>> x=open("x", "w")
   >>> x.seek(0.0)
   0.0
   >>> x.seek(-0.0)
   -0.0
   >>> x.seek(0.1)
   0.1
   >>> x.tell()
   0

I think that we should just raise an error in Python 3.2 because I consider this as a bug. It remembers me another bug related to file and float: http://bugs.python.org/issue5080#msg92400

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8950>
_______________________________________

From report at bugs.python.org  Wed Jun  9 00:05:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 22:05:03 +0000
Subject: [issue8907] time module documentation differs in trunk and py3k
In-Reply-To: <1275752348.33.0.507552521147.issue8907@psf.upfronthosting.co.za>
Message-ID: <1276034703.36.0.790370438667.issue8907@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Merged r81489 to py3k (r81840), but this affects datetime module docs, not time.  On a closer examination, the differences in time.rst are correct.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8907>
_______________________________________

From report at bugs.python.org  Wed Jun  9 00:11:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jun 2010 22:11:05 +0000
Subject: [issue8951] PyArg_Parse*(): factorize code of 's' and 'z' formats,
	and 'u' and 'Z' formats
In-Reply-To: <1276035065.31.0.617634960026.issue8951@psf.upfronthosting.co.za>
Message-ID: <1276035065.31.0.617634960026.issue8951@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Code of 's' and 'z' formats is *mostly* the same... except a bug (#8949).

Code of 'u' and 'Z' formats can also easily be factorized.

I don't really understand why the code was duplicated.

----------
components: Interpreter Core
files: factorize_getargs_sz_uZ.patch
keywords: patch
messages: 107356
nosy: haypo
priority: normal
severity: normal
status: open
title: PyArg_Parse*(): factorize code of 's' and 'z' formats, and 'u' and 'Z' formats
versions: Python 3.2
Added file: http://bugs.python.org/file17592/factorize_getargs_sz_uZ.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8951>
_______________________________________

From report at bugs.python.org  Wed Jun  9 00:12:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jun 2010 22:12:04 +0000
Subject: [issue8949] PyArg_Parse*(): "z" should not accept bytes
In-Reply-To: <1276032203.54.0.364398342729.issue8949@psf.upfronthosting.co.za>
Message-ID: <1276035124.45.0.685002367161.issue8949@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Hum, the patch doesn't update the documentation (at least Porting section of the What's new in Python 3.2).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8949>
_______________________________________

From report at bugs.python.org  Wed Jun  9 00:30:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jun 2010 22:30:41 +0000
Subject: [issue8939] Use C type names (PyUnicode etc;) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276036241.77.0.435177115911.issue8939@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Big patch:
 - replace Python types by C Python types (eg. str => PyUnicodeObject* and None => Py_None)
 - fix "w" / "w*" / "w#" doc: similar to "y" / "y*" / "y#" (and not "s" / "s*" / "s#")
 - add quotes to the formats, eg. s => "s"
 - use :ctype: to add links to some terms (eg. Py_BEGIN_ALLOW_THREADS) and use a fixed width font
 - replace "the default encoding" by "'utf-8' encoding"
 - replace true by 1, and false by 0 (C API of Python doesn't use stdbool.h but classic int)
 - use a list for the two modes of "es#"
 - Py_BuildValue(), "s" and "s#" formats: specify that the Python object is a str

1 and 0 were formatted with ``1`` and ``0``. I don't understand why, so I removed the italic style.

Sorry for the length of the patch, but it was easy to work on only one aspect.

----------
keywords: +patch
Added file: http://bugs.python.org/file17593/c_api_arg.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8939>
_______________________________________

From report at bugs.python.org  Wed Jun  9 00:32:08 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 08 Jun 2010 22:32:08 +0000
Subject: [issue8946] PyBuffer_Release signature in 3.1 documentation is
	incorrect
In-Reply-To: <1276028746.19.0.698782351102.issue8946@psf.upfronthosting.co.za>
Message-ID: <1276036328.31.0.512320980132.issue8946@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed in r81851 (py3k) and r81852 (release31-maint). Thanks!

----------
assignee: docs at python -> brian.curtin
nosy: +brian.curtin
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8946>
_______________________________________

From report at bugs.python.org  Wed Jun  9 00:33:08 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Tue, 08 Jun 2010 22:33:08 +0000
Subject: [issue8939] Use C type names (PyUnicode etc;) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276036388.08.0.500522361712.issue8939@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at acm.org>:


----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8939>
_______________________________________

From report at bugs.python.org  Wed Jun  9 00:41:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jun 2010 22:41:27 +0000
Subject: [issue8939] Use C type names (PyUnicode etc;) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276036887.74.0.601154262352.issue8939@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Other changes of the patch:
 - "u#": remove "Non-Unicode objects are handled by interpreting their read-buffer pointer ...", it's no more true
 - "es", "es#": remove "... and objects convertible to Unicode into a character buffer", it's no more true
 - Py_BuildValue(), "K" and "L" formats: specify the name of the C type on Windows (_int64 / unsigned _int64) as done for PyArg_Parse*() long long types

If the patch is too long, I can try to split it into smaller parts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8939>
_______________________________________

From report at bugs.python.org  Wed Jun  9 00:42:23 2010
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 08 Jun 2010 22:42:23 +0000
Subject: [issue7768] raw_input should encode unicode prompt with
	std.stdout.encoding.
In-Reply-To: <1264309924.17.0.144254143298.issue7768@psf.upfronthosting.co.za>
Message-ID: <1276036943.35.0.793951960477.issue7768@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

>What do you mean by "mainstream"? Python3 is available in Ubuntu (since Karmic), Fedora 13, Mandriva 2010.0, Gentoo, Debian (only Sid for now), ...

It means most of Pythonista uses Python3 rather than Python2 and
most of libraries supports Python3.

Currently, many new Pythonista starts with Python2 because libraries
they want support only it, and are suffered by UnicodeError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7768>
_______________________________________

From report at bugs.python.org  Wed Jun  9 01:02:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jun 2010 23:02:03 +0000
Subject: [issue8839] PyArg_ParseTuple(): remove "t# format
In-Reply-To: <1275002949.14.0.769648340098.issue8839@psf.upfronthosting.co.za>
Message-ID: <1276038123.97.0.00682322523581.issue8839@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> t# was meant to provide access to text data, so replacing it with a
> parser code that is meant for binary data is not correct. The
> closes Python3 gets to t# from Python2 is s# or s*, so please use
> those in the NEWS entry and s* in charbuffer_encode().

Done. Patch commited as r81854 in 3.2: it removes also codecs.charbuffer_encode(). Commit blocked in 3.1 (r81855).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8839>
_______________________________________

From report at bugs.python.org  Wed Jun  9 01:13:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jun 2010 23:13:34 +0000
Subject: [issue8838] Remove
	codecs.readbuffer_encode()	and	codecs.charbuffer_encode()
In-Reply-To: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>
Message-ID: <1276038814.42.0.999450131558.issue8838@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r81854 removes codecs.charbuffer_encode() (and t# parsing format) from Python 3.2 (blocked in 3.1: r81855).

--

My problem with codecs.readbuffer_encode() is that it does accept byte *and* character strings. If you want to get a byte string, just use bytes(input). If you want to convert a character string to a byte string, use input.encode("utf-8"). But accepting both types may lead to mojibake as we had in Python2.

MAL> That's a common misunderstanding. The codec system does not
MAL> mandate a specific type combination. Only the helper methods
MAL> .encode() and .decode() on bytes and str objects in Python3 do.

This is related to #7475: we have to decide if we drop completly this  (currently unused) feature (eg. remove codecs.readbuffer_encode()), or if we "reenable" this feature again (reintroduce hex, bz2, rot13, ... codecs). This discussion should occur on the mailing list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Wed Jun  9 01:13:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jun 2010 23:13:56 +0000
Subject: [issue8839] PyArg_ParseTuple(): remove "t# format
In-Reply-To: <1275002949.14.0.769648340098.issue8839@psf.upfronthosting.co.za>
Message-ID: <1276038836.7.0.74714317969.issue8839@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/issue8839>
_______________________________________

From report at bugs.python.org  Wed Jun  9 01:18:57 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 08 Jun 2010 23:18:57 +0000
Subject: [issue8948] cleanup functions are not executed with
	unittest.TestCase.debug()
In-Reply-To: <1276030525.65.0.633421030518.issue8948@psf.upfronthosting.co.za>
Message-ID: <1276039137.88.0.667359895288.issue8948@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 81853. Still needs porting to py3k (and unittest2).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8948>
_______________________________________

From report at bugs.python.org  Wed Jun  9 01:57:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 08 Jun 2010 23:57:09 +0000
Subject: [issue7839] Popen should raise ValueError if pass a string when
	shell=False or a list when shell=True
In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za>
Message-ID: <1276041429.48.0.541586399034.issue7839@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Because we use the versions field to indicate which versions a patch will be applied to, if it is, and I created this bug as a feature request, and as such it is not a candidate for 2.7.

Changing list to string for shell=True is a behavior change (currently excess list elements are passed to the shell...and I don't *know* that that is useless, someone might be exploiting it) and hard to get right.  Changing string to list might be possible on unix using shlex, but is a distinctly non-trivial change, would need to be considered carefully with regard to its implications, and I have no idea what it would mean on Windows.

Since 2.7 is in RC status, there is no way such a fix will be accepted for 2.7.  You can try to make a case for this proposal as a bug fix for 2.7.1, but I'm not sanguine about its chances.  Personally I'm -0.5 on such a change.  I think it is better to leave the control of the command formatting in the hands of the programmer.  Doing such a conversion is too close to guessing for my taste.

If you want a wider selection of opinions you can post the issue to python-dev and request feedback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7839>
_______________________________________

From report at bugs.python.org  Wed Jun  9 01:59:47 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Jun 2010 23:59:47 +0000
Subject: [issue8945] Bug in **kwds expansion on call?
In-Reply-To: <1276024245.06.0.703861128554.issue8945@psf.upfronthosting.co.za>
Message-ID: <1276041587.08.0.774843971851.issue8945@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Might that 'usual' fact be somehow documented? I am hard put to suggest anything since it is a fact I, like others, am not aware of. Is this a general rule for subclasses of builtins? or specific to dicts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8945>
_______________________________________

From report at bugs.python.org  Wed Jun  9 02:03:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2010 00:03:07 +0000
Subject: [issue8850] Remove "w" format of PyParse_ParseTuple()
In-Reply-To: <1275099860.74.0.46695580149.issue8850@psf.upfronthosting.co.za>
Message-ID: <1276041787.84.0.232411200155.issue8850@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #8592: 'y' does not check for embedded NUL bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8850>
_______________________________________

From report at bugs.python.org  Wed Jun  9 02:04:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2010 00:04:34 +0000
Subject: [issue8592] 'y' does not check for embedded NUL bytes
In-Reply-To: <1272737075.21.0.258918022173.issue8592@psf.upfronthosting.co.za>
Message-ID: <1276041874.08.0.633853861036.issue8592@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #8850: Remove "w" format of PyParse_ParseTuple().

--

About "y": the parser HAVE TO check for embedded NUL bytes, because the caller doesn't know the size of the buffer (and strlen() would give the wrong size).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8592>
_______________________________________

From report at bugs.python.org  Wed Jun  9 02:15:37 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 09 Jun 2010 00:15:37 +0000
Subject: [issue7839] Popen should raise ValueError if pass a string when
	shell=False or a list when shell=True
In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za>
Message-ID: <1276042537.89.0.665237148268.issue7839@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree with David. For the issue raised here, at most I would make (list, shell=True) and (str, shell=False) raise errors.

There's an issue (that I can't find right now) for creating functions that convert from str->list and list->str for cases such as this. shlex is sort of str->list, but it has issues on Windows. I've mentioned elsewhere that for Windows list->str is not always possible, because there is no standard for the corresponding str->list that each program is responsible for.

On Unix-like systems, when the called programs are run they get a pre-parsed list (argv). This list is created by the caller, either directly or through a shell. When a shell is doing this, at least the behavior is somewhat standard.

On Windows, the called programs get a string, and they're in charge of parsing it, if they want to. Many programs use the C library to create argv, but exactly how that parsing works changes between runtime vendors and over time within a vendor. There's no solution that will work in all cases.

Which is not to suggest that we shouldn't try, just that it will be hard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7839>
_______________________________________

From report at bugs.python.org  Wed Jun  9 02:17:17 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 09 Jun 2010 00:17:17 +0000
Subject: [issue8945] Bug in **kwds expansion on call?
In-Reply-To: <1276024245.06.0.703861128554.issue8945@psf.upfronthosting.co.za>
Message-ID: <1276042637.75.0.116609326088.issue8945@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Somewhere, we should document the-facts-of-life for subclassing builtins.

1) For the most part, C code has the pattern
       if isinstance(obj, some_builtin_type):
           call the built_type's methods directly using slotted methods
       otherwise:
           use slower getattribute style calls

2) A subclasser of a dict needs to actually populate the dict with the values they want used.   The built-in dict class is "open for extension and closed for modification" -- the open/closed principle.  This is necessary or else a subclasser could easily break the built-in type's invariants and crash python.

3) For the most part, only something like subclassing UserDict gives you full control.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8945>
_______________________________________

From report at bugs.python.org  Wed Jun  9 08:34:08 2010
From: report at bugs.python.org (Andres Freund)
Date: Wed, 09 Jun 2010 06:34:08 +0000
Subject: [issue3831] Multiprocessing: Expose underlying pipe in queues
In-Reply-To: <1221095639.45.0.136100950642.issue3831@psf.upfronthosting.co.za>
Message-ID: <1276065248.55.0.942732814245.issue3831@psf.upfronthosting.co.za>


Andres Freund <andres at anarazel.de> added the comment:

As soon as some bytes are signalled as being available one can simply do a normal get(). I don't really see the problem here?
Sure, the get() might not be completely non-blocking (especially if the transferred event is more than the size of a pipe-buffer) but I have a hard time seing that as a problem as that should be both rare and only last a short time.

My personal use-case is being able to efficiently wait for evens from different queues - using the standard api one currently can only do that by busy looping...

The biggest thing I see where you have to be careful here is some stomping herd phenomenon you will get into if you have multiple readers doing a poll().
Namely *all* off those processes will awake and run into .get() which isnt exactly nice, but thats hardly solvable on python level.

----------
nosy: +andresfreund

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3831>
_______________________________________

From report at bugs.python.org  Wed Jun  9 10:12:08 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 09 Jun 2010 08:12:08 +0000
Subject: [issue8932] test_capi fails --without-threads
In-Reply-To: <1275920311.66.0.668508833074.issue8932@psf.upfronthosting.co.za>
Message-ID: <1276071128.85.0.250569694645.issue8932@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file17594/issue8932.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8932>
_______________________________________

From report at bugs.python.org  Wed Jun  9 10:14:48 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 09 Jun 2010 08:14:48 +0000
Subject: [issue8832] automate minidom.unlink() with a context manager
In-Reply-To: <1274965382.14.0.210712489615.issue8832@psf.upfronthosting.co.za>
Message-ID: <1276071288.12.0.227830403532.issue8832@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Thank you all.
I updated the unittest, and committed this in:
revision: 81856

----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8832>
_______________________________________

From report at bugs.python.org  Wed Jun  9 10:20:34 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 09 Jun 2010 08:20:34 +0000
Subject: [issue8838]
	Remove	codecs.readbuffer_encode()	and	codecs.charbuffer_encode()
In-Reply-To: <1276038814.42.0.999450131558.issue8838@psf.upfronthosting.co.za>
Message-ID: <4C0F4ECD.2050400@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:
> 
> r81854 removes codecs.charbuffer_encode() (and t# parsing format) from Python 3.2 (blocked in 3.1: r81855).
> 
> --
> 
> My problem with codecs.readbuffer_encode() is that it does accept byte *and* character strings. If you want to get a byte string, just use bytes(input). If you want to convert a character string to a byte string, use input.encode("utf-8"). But accepting both types may lead to mojibake as we had in Python2.

The point is to have an interface to the "s#" parser marker
from Python. This accepts bytes, objects with a buffer interface
and Unicode objects (via the default encoding).

It does not accept e.g. lists, tuples or plain integers like
bytes() does.

> MAL> That's a common misunderstanding. The codec system does not
> MAL> mandate a specific type combination. Only the helper methods
> MAL> .encode() and .decode() on bytes and str objects in Python3 do.
> 
> This is related to #7475: we have to decide if we drop completly this  (currently unused) feature (eg. remove codecs.readbuffer_encode()), or if we "reenable" this feature again (reintroduce hex, bz2, rot13, ... codecs). This discussion should occur on the mailing list.

We are not going to drop this design feature of the codec system
and we've already had the discussion in 2008.

The statement that it is an unused feature is plain wrong. Please
don't forget that people are actually using these things in their
applications, many of which have not been ported to Python3.
We're not just talking about code that you find in CPython or the
stdlib.

The removed codecs will go back into 3.2.

----------
title: Remove codecs.readbuffer_encode()	and	codecs.charbuffer_encode() -> Remove	codecs.readbuffer_encode()	and	codecs.charbuffer_encode()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Wed Jun  9 11:06:25 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 09 Jun 2010 09:06:25 +0000
Subject: [issue8939] Use C type names (PyUnicode etc;) in the C API docs
In-Reply-To: <1276036241.77.0.435177115911.issue8939@psf.upfronthosting.co.za>
Message-ID: <4C0F598D.4000202@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:
> 
> Big patch:
>  - replace Python types by C Python types (eg. str => PyUnicodeObject* and None => Py_None)

I was thinking of e.g. "PyUnicode", not "PyUnicodeObject*".

>  - add quotes to the formats, eg. s => "s"

Why do you put the parser codes in double quotes ?

>  - use :ctype: to add links to some terms (eg. Py_BEGIN_ALLOW_THREADS) and use a fixed width font
>  - replace "the default encoding" by "'utf-8' encoding"
>  - replace true by 1, and false by 0 (C API of Python doesn't use stdbool.h but classic int)

That's not necessarily correct: true in C means non-zero. Only
false equates to 0. You can however, make that change if the
function actually does always return 1.

In general, most C functions in Python use these integer
return values:

 1  - success
 0  - no success
 -1 - error

Some of them also return a positive integer >1 for success or
a negative integer <-1 for error, but those are exceptions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8939>
_______________________________________

From report at bugs.python.org  Wed Jun  9 11:10:01 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 09 Jun 2010 09:10:01 +0000
Subject: [issue8932] test_capi fails --without-threads
In-Reply-To: <1275920311.66.0.668508833074.issue8932@psf.upfronthosting.co.za>
Message-ID: <1276074601.51.0.247535953837.issue8932@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Committed in r81857. Blocked for release31-maint (requires additional fixes).

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8932>
_______________________________________

From report at bugs.python.org  Wed Jun  9 11:28:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2010 09:28:32 +0000
Subject: [issue8939] Use C type names (PyUnicode etc;) in the C API docs
In-Reply-To: <4C0F598D.4000202@egenix.com>
Message-ID: <201006091128.23447.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le mercredi 09 juin 2010 11:06:25, vous avez ?crit :
> >  - replace Python types by C Python types (eg. str => PyUnicodeObject*
> >  and None => Py_None)
> 
> I was thinking of e.g. "PyUnicode", not "PyUnicodeObject*".

I don't know PyUnicode, only "unicode" (Python type) or "PyUnicodeObject*" (C 
Python type). :ctype:`PyUnicodeObject*` creates a link in the HTML 
documentation.

> >  - add quotes to the formats, eg. s => "s"
> 
> Why do you put the parser codes in double quotes ?

It's easier to search a format: try to search s or b format in the current 
documentation, you will see :-)

I think that it's also more readable and closer to the "real" source code (eg. 
a call to PyArg_ParseTuple() uses quotes).

> >  - replace true by 1, and false by 0 (C API of Python doesn't use
> >  stdbool.h but classic int)
> 
> That's not necessarily correct: true in C means non-zero. Only
> false equates to 0. You can however, make that change if the
> function actually does always return 1.

There are only 2 possible results: 0 or 1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8939>
_______________________________________

From report at bugs.python.org  Wed Jun  9 12:04:03 2010
From: report at bugs.python.org (Tal Einat)
Date: Wed, 09 Jun 2010 10:04:03 +0000
Subject: [issue8904] quick example how to fix docs
In-Reply-To: <1275733848.36.0.713191812865.issue8904@psf.upfronthosting.co.za>
Message-ID: <1276077843.6.0.084165816444.issue8904@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

AFAIK submitting patches in general is covered well enough in several places. What I'm missing specifically regarding patches for documentation is instructions on how to preview them before submitting them. Editing reST is easy, but making sure you've done it correctly without knowing how to run it through Sphinx is impossible. I spent quite some time and couldn't figure this one out, and ended up submitting a doc patch without previewing it.

To be specific, http://www.python.org/dev/contributing/ points to http://docs.python.org/dev/documenting/index.html which has quite a bit of information on reST but no information on Sphinx, despite the main page clearly stating:
"This document describes the style guide for our documentation, the custom reStructuredText markup introduced to support Python documentation and how it should be used, as well as the Sphinx build system."

Finally, a simple how-to with concrete, technical steps on how to write, preview and submit a doc patch would really help, especially for those who have never before submitted a patch. A simple video example (e.g. on ShowMeDo) would be fantastic, but even just updated detailed textual instructions would be a great step forward.

----------
nosy: +taleinat
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8904>
_______________________________________

From report at bugs.python.org  Wed Jun  9 12:32:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 09 Jun 2010 10:32:25 +0000
Subject: [issue8832] automate minidom.unlink() with a context manager
In-Reply-To: <1274965382.14.0.210712489615.issue8832@psf.upfronthosting.co.za>
Message-ID: <1276079545.74.0.251209349679.issue8832@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You forgot to close the bug :)

Note that if you write ?rNNNN? or ?revision NNNN?, Roundup will make a link out of it.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8832>
_______________________________________

From report at bugs.python.org  Wed Jun  9 12:34:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2010 10:34:49 +0000
Subject: [issue8952] Doc/c-api/arg.rst: fix documentation of number formats
In-Reply-To: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za>
Message-ID: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The documentation of PyArg_Parse*() number formats specify that only int / float / complex are accepted, whereas any int / float / complex compatible object is accepted. "compatible" means that it has an __int__() / __float__() / __complex__() method, or nb_int / nb_float of Py_TYPE(obj)->tp_as_number->nb_int is defined (tp_as_number has no nb_complex).

I suppose that the following paragraph is also outdated:

"It is possible to pass "long" integers (integers whose value exceeds the
 platform's :const:`LONG_MAX`) however no proper range checking is done --- the
 most significant bits are silently truncated when the receiving field is too
 small to receive the value (actually, the semantics are inherited from downcasts
 in C --- your mileage may vary)."

Moreover, "without overflow checking" should be explained (Mark told me that the number is truncated to a power of 2).

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 107379
nosy: docs at python, haypo, mark.dickinson
priority: normal
severity: normal
status: open
title: Doc/c-api/arg.rst: fix documentation of number formats
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8952>
_______________________________________

From report at bugs.python.org  Wed Jun  9 12:37:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2010 10:37:17 +0000
Subject: [issue8949] PyArg_Parse*(): "z" should not accept bytes
In-Reply-To: <1276032203.54.0.364398342729.issue8949@psf.upfronthosting.co.za>
Message-ID: <1276079837.5.0.626056383147.issue8949@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8949>
_______________________________________

From report at bugs.python.org  Wed Jun  9 12:46:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2010 10:46:58 +0000
Subject: [issue8923] Remove unused "errors" argument
	from	_PyUnicode_AsDefaultEncodedString()
In-Reply-To: <1275848921.87.0.52681950966.issue8923@psf.upfronthosting.co.za>
Message-ID: <1276080418.09.0.77643256484.issue8923@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Since Python3 fixes the UTF-8 default encoding, it's better
> to enhance PyUnicode_AsUTF8String() to cache the UTF-8
> string in the Unicode object

Right, that sounds like a great idea. Attached patch implements that: patch PyUnicode_AsUTF8String() and PyUnicode_AsEncodedString(). Does it look ok?

> replace all uses of _PyUnicode_AsDefaultEncodedString() 
> with PyUnicode_AsUTF8String()

I'm waiting for your approval of the first patch before working on the second part.

----------
Added file: http://bugs.python.org/file17595/utf8_defenc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8923>
_______________________________________

From report at bugs.python.org  Wed Jun  9 12:47:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Jun 2010 10:47:00 +0000
Subject: [issue8952] Doc/c-api/arg.rst: fix documentation of number formats
In-Reply-To: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za>
Message-ID: <1276080420.18.0.660421615312.issue8952@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, most of that paragraph is outdated.

We should check exactly what does happen when the "receiving field is too small" (both in practice and in theory).  In C, downcasting to an unsigned type is well-defined and will always reduce modulo 2**<width_of_type>.  The result of downcasting to a signed type is implementation-defined, however;  do we actually do that anywhere?  If so, it would be nice to fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8952>
_______________________________________

From report at bugs.python.org  Wed Jun  9 12:48:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Jun 2010 10:48:48 +0000
Subject: [issue8952] Doc/c-api/arg.rst: fix documentation of number formats
In-Reply-To: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za>
Message-ID: <1276080528.52.0.0744371433205.issue8952@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The other variable of interest here is that some integer formats will accept types with an __index__ method, while others won't.  I'm not sure which types fall into each category, right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8952>
_______________________________________

From report at bugs.python.org  Wed Jun  9 12:59:02 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 09 Jun 2010 10:59:02 +0000
Subject: [issue8939] Use C type names (PyUnicode etc;) in the C API docs
In-Reply-To: <201006091128.23447.victor.stinner@haypocalc.com>
Message-ID: <4C0F73F3.3040609@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 09 juin 2010 11:06:25, vous avez ?crit :
>>>  - replace Python types by C Python types (eg. str => PyUnicodeObject*
>>>  and None => Py_None)
>>
>> I was thinking of e.g. "PyUnicode", not "PyUnicodeObject*".
> 
> I don't know PyUnicode, only "unicode" (Python type) or "PyUnicodeObject*" (C 
> Python type). :ctype:`PyUnicodeObject*` creates a link in the HTML 
> documentation.

The "PyUnicode" style is just an abbreviated version of the longer
"PyUnicodeObject", that we sometimes use, since writing "Pass
a PyUnicodeObject object to this function" looks a bit silly.

I don't have a strong opinion about this, though. The longer
version is fine as well.

>>>  - add quotes to the formats, eg. s => "s"
>>
>> Why do you put the parser codes in double quotes ?
> 
> It's easier to search a format: try to search s or b format in the current 
> documentation, you will see :-)
> 
> I think that it's also more readable and closer to the "real" source code (eg. 
> a call to PyArg_ParseTuple() uses quotes).

It could lead developers into thinking that they have to use
those quotes in their code.

Perhaps you should add a note about this typographic addition
to docs.

>>>  - replace true by 1, and false by 0 (C API of Python doesn't use
>>>  stdbool.h but classic int)
>>
>> That's not necessarily correct: true in C means non-zero. Only
>> false equates to 0. You can however, make that change if the
>> function actually does always return 1.
> 
> There are only 2 possible results: 0 or 1.

I wouldn't count on this. It may be the case now, but it's both
hard to check by reading the code and knowing that only 1 can
be returned doesn't buy a developer much.

In fact, this has
bitten us before with the cmp() function: users starting writing
code like this because we documented the return codes as -1, 0, 1:

a = b + z * cmp(x, y)

Please use "non-zero" instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8939>
_______________________________________

From report at bugs.python.org  Wed Jun  9 13:06:53 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 09 Jun 2010 11:06:53 +0000
Subject: [issue8949] PyArg_Parse*(): "z" should not accept bytes
In-Reply-To: <1276079837.6.0.123398824969.issue8949@psf.upfronthosting.co.za>
Message-ID: <4C0F75CA.5080103@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

"z" should not accept bytes... why not ?

"z" is the same as "s" with the addition that passing None
as parameter will result in the pointer to get set to NULL.

"s" accepts bytes via the buffer interface, so why should
"z" behave differently ?

If a function should only accept Unicode or None, then "Z"
should be used instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8949>
_______________________________________

From report at bugs.python.org  Wed Jun  9 13:14:00 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 09 Jun 2010 11:14:00 +0000
Subject: [issue8923] Remove unused "errors"
	argument	from	_PyUnicode_AsDefaultEncodedString()
In-Reply-To: <1276080418.09.0.77643256484.issue8923@psf.upfronthosting.co.za>
Message-ID: <4C0F7775.7000208@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:
> 
>> Since Python3 fixes the UTF-8 default encoding, it's better
>> to enhance PyUnicode_AsUTF8String() to cache the UTF-8
>> string in the Unicode object
> 
> Right, that sounds like a great idea. Attached patch implements that: patch PyUnicode_AsUTF8String() and PyUnicode_AsEncodedString(). Does it look ok?

Looks good.

>> replace all uses of _PyUnicode_AsDefaultEncodedString() 
>> with PyUnicode_AsUTF8String()
> 
> I'm waiting for your approval of the first patch before working on the second part.

When replacing uses of _PyUnicode_AsDefaultEncodedString() with
PyUnicode_AsUTF8String() you have to take great care to decref
the object returned by the latter. Otherwise, we get huge memory
leaks.

----------
title: Remove unused "errors" argument from	_PyUnicode_AsDefaultEncodedString() -> Remove unused "errors" argument	from	_PyUnicode_AsDefaultEncodedString()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8923>
_______________________________________

From report at bugs.python.org  Wed Jun  9 13:27:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Jun 2010 11:27:09 +0000
Subject: [issue8941] utf-32be codec failing on UCS-2 python build for 32-bit
	value
In-Reply-To: <1276013724.21.0.174818104611.issue8941@psf.upfronthosting.co.za>
Message-ID: <1276082829.73.0.412611830099.issue8941@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Also witnessed on 2.x (UCS-2 build):

>>> unicode(b'\x00\x01\x00\x00', 'utf-32be')
u'\ud800\u0773'
>>> unicode(b'\x00\x00\x01\x00', 'utf-32le')
u'\U00010000'

----------
nosy: +haypo, lemburg, pitrou
priority: normal -> high
title: utf-32be codec failing on 16-bit python build for 32-bit value -> utf-32be codec failing on UCS-2 python build for 32-bit value
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8941>
_______________________________________

From report at bugs.python.org  Wed Jun  9 13:31:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Jun 2010 11:31:20 +0000
Subject: [issue8941] utf-32be codec failing on UCS-2 python build for 32-bit
	value
In-Reply-To: <1276013724.21.0.174818104611.issue8941@psf.upfronthosting.co.za>
Message-ID: <1276083080.36.0.57761091609.issue8941@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The following code at the beginning of PyUnicode_DecodeUTF32Stateful is buggy when codec endianness doesn't match the native endianness (not to mention it could also crash if the underlying CPU arch doesn't support unaligned access to 4-byte integers):

#ifndef Py_UNICODE_WIDE
    for (i = pairs = 0; i < size/4; i++)
        if (((Py_UCS4 *)s)[i] >= 0x10000)
            pairs++;
#endif

As a result, the preallocated unicode object isn't long enough and Python writes into memory it shouldn't write into. It can produce hard crashes, such as:

>>> l = unicode(b'\x00\x01\x00\x00' * 1024, 'utf-32be')
Debug memory block at address p=0xf2b310:
    2050 bytes originally requested
    The 8 pad bytes at p-8 are FORBIDDENBYTE, as expected.
    The 8 pad bytes at tail=0xf2bb12 are not all FORBIDDENBYTE (0xfb):
        at tail+0: 0x00 *** OUCH
        at tail+1: 0xdc *** OUCH
        at tail+2: 0x00 *** OUCH
        at tail+3: 0xd8 *** OUCH
        at tail+4: 0x00 *** OUCH
        at tail+5: 0xdc *** OUCH
        at tail+6: 0x00 *** OUCH
        at tail+7: 0xd8 *** OUCH
    The block was made by call #61925422603698392 to debug malloc/realloc.
    Data at p: 00 d8 00 dc 00 d8 00 dc ... 00 dc 00 d8 00 dc 00 d8
Fatal Python error: bad trailing pad byte
Abandon

----------
priority: high -> critical
type: behavior -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8941>
_______________________________________

From report at bugs.python.org  Wed Jun  9 13:48:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Jun 2010 11:48:34 +0000
Subject: [issue8941] utf-32be codec failing on UCS-2 python build for 32-bit
	value
In-Reply-To: <1276013724.21.0.174818104611.issue8941@psf.upfronthosting.co.za>
Message-ID: <1276084114.59.0.619243605952.issue8941@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +doerwalter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8941>
_______________________________________

From report at bugs.python.org  Wed Jun  9 14:02:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2010 12:02:06 +0000
Subject: [issue8949] PyArg_Parse*(): "z" should not accept bytes
In-Reply-To: <4C0F75CA.5080103@egenix.com>
Message-ID: <201006091401.58165.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le mercredi 09 juin 2010 13:06:53, vous avez ?crit :
> "s" accepts bytes via the buffer interface

No. "s*" and "s#" do accept any buffer compatible object (including bytes and 
bytearray), but "s" doesn't.

I fixed recently the documentation about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8949>
_______________________________________

From report at bugs.python.org  Wed Jun  9 14:03:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Jun 2010 12:03:30 +0000
Subject: [issue8941] utf-32be codec failing on UCS-2 python build for 32-bit
	value
In-Reply-To: <1276013724.21.0.174818104611.issue8941@psf.upfronthosting.co.za>
Message-ID: <1276085010.78.0.565711537744.issue8941@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a simple patch. A test should be added, though.

----------
keywords: +patch
Added file: http://bugs.python.org/file17596/utf32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8941>
_______________________________________

From report at bugs.python.org  Wed Jun  9 14:14:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 09 Jun 2010 12:14:04 +0000
Subject: [issue8939] Use C type names (PyUnicode etc;) in the C API docs
In-Reply-To: <1276036241.77.0.435177115911.issue8939@psf.upfronthosting.co.za>
Message-ID: <4C0F8589.6090004@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

> 1 and 0 were formatted with ``1`` and ``0``. I don't understand why,
> so I removed the italic style.

This reST construct marks up code. Please revert this change. :)

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8939>
_______________________________________

From report at bugs.python.org  Wed Jun  9 14:15:12 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 09 Jun 2010 12:15:12 +0000
Subject: [issue8941] utf-32be codec failing on UCS-2 python build for
	32-bit	value
In-Reply-To: <1276083080.36.0.57761091609.issue8941@psf.upfronthosting.co.za>
Message-ID: <4C0F85C9.5060202@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> The following code at the beginning of PyUnicode_DecodeUTF32Stateful is buggy when codec endianness doesn't match the native endianness (not to mention it could also crash if the underlying CPU arch doesn't support unaligned access to 4-byte integers):
> 
> #ifndef Py_UNICODE_WIDE
>     for (i = pairs = 0; i < size/4; i++)
>         if (((Py_UCS4 *)s)[i] >= 0x10000)
>             pairs++;
> #endif

Good catch !

I wonder whether it wouldn't be better to preallocate
a Unicode object with size of e.g. size/4 + 16 and
then resize the object as necessary in case a surrogate
pair needs to be created (won't happen that often in
practice).

The extra scan for pairs can take long depending on
how much data you have to decode and likely doesn't
go down well with CPU caches.

----------
title: utf-32be codec failing on UCS-2 python build for 32-bit value -> utf-32be codec failing on UCS-2 python build for 32-bit	value

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8941>
_______________________________________

From report at bugs.python.org  Wed Jun  9 14:24:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Jun 2010 12:24:00 +0000
Subject: [issue8950] In getargs.c,
	make 'L' code raise TypeError for float arguments.
In-Reply-To: <1276033368.49.0.876712618605.issue8950@psf.upfronthosting.co.za>
Message-ID: <1276086240.73.0.727976409779.issue8950@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch.  Victor, are you interested in reviewing?

----------
keywords: +patch
Added file: http://bugs.python.org/file17597/issue8950.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8950>
_______________________________________

From report at bugs.python.org  Wed Jun  9 14:24:06 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 09 Jun 2010 12:24:06 +0000
Subject: [issue8949] PyArg_Parse*(): "z" should not accept bytes
In-Reply-To: <201006091401.58165.victor.stinner@haypocalc.com>
Message-ID: <4C0F87DB.2040301@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 09 juin 2010 13:06:53, vous avez ?crit :
>> "s" accepts bytes via the buffer interface
> 
> No. "s*" and "s#" do accept any buffer compatible object (including bytes and 
> bytearray), but "s" doesn't.
> 
> I fixed recently the documentation about that.

Hmm, that sounds like an oversight to me. Why should "s" not accept
bytes when "s#" and "s*" do ?

The only difference between "s" and "s#" is that you work with
NUL-terminated strings as opposed to binary or text data with embedded
NULs. Even Unicode objects can contain embedded NULs, so from that
perspective there's no difference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8949>
_______________________________________

From report at bugs.python.org  Wed Jun  9 14:26:09 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 09 Jun 2010 12:26:09 +0000
Subject: [issue8941] utf-32be codec failing on UCS-2 python build for
	32-bit	value
In-Reply-To: <1276013724.21.0.174818104611.issue8941@psf.upfronthosting.co.za>
Message-ID: <1276086369.26.0.813937739899.issue8941@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8941>
_______________________________________

From report at bugs.python.org  Wed Jun  9 14:30:23 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 09 Jun 2010 12:30:23 +0000
Subject: [issue8948] cleanup functions are not executed with
	unittest.TestCase.debug()
In-Reply-To: <1276030525.65.0.633421030518.issue8948@psf.upfronthosting.co.za>
Message-ID: <1276086623.15.0.667585834307.issue8948@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Typo correction in revision 81859. Also needs merging onto py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8948>
_______________________________________

From report at bugs.python.org  Wed Jun  9 14:35:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2010 12:35:36 +0000
Subject: [issue8950] In getargs.c,
	make 'L' code raise TypeError for float arguments.
In-Reply-To: <1276086240.73.0.727976409779.issue8950@psf.upfronthosting.co.za>
Message-ID: <201006091435.28137.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le mercredi 09 juin 2010 14:24:01, vous avez ?crit :
> Here's a patch.  Victor, are you interested in reviewing?

I ran the whole test suite: there is no error. The patch is ok, please commit 
it in Python 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8950>
_______________________________________

From report at bugs.python.org  Wed Jun  9 15:07:45 2010
From: report at bugs.python.org (Jean Jordaan)
Date: Wed, 09 Jun 2010 13:07:45 +0000
Subject: [issue8953] Syntax error in
	http://docs.python.org/library/decimal.html#recipes
In-Reply-To: <1276088865.47.0.391393017311.issue8953@psf.upfronthosting.co.za>
Message-ID: <1276088865.47.0.391393017311.issue8953@psf.upfronthosting.co.za>


New submission from Jean Jordaan <jean.jordaan at gmail.com>:

http://docs.python.org/library/decimal.html#recipes
has this code: 

    for i in range(places):
        build(next() if digits else '0')

Mismatched parenthesis.

----------
assignee: docs at python
components: Documentation
messages: 107396
nosy: Jean.Jordaan, docs at python
priority: normal
severity: normal
status: open
title: Syntax error in http://docs.python.org/library/decimal.html#recipes
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8953>
_______________________________________

From report at bugs.python.org  Wed Jun  9 15:09:17 2010
From: report at bugs.python.org (Jean Jordaan)
Date: Wed, 09 Jun 2010 13:09:17 +0000
Subject: [issue8953] Syntax error in
	http://docs.python.org/library/decimal.html#recipes
In-Reply-To: <1276088865.47.0.391393017311.issue8953@psf.upfronthosting.co.za>
Message-ID: <1276088957.31.0.268229966076.issue8953@psf.upfronthosting.co.za>


Jean Jordaan <jean.jordaan at gmail.com> added the comment:

Aargh, sorry, sent too quick :-(

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8953>
_______________________________________

From report at bugs.python.org  Wed Jun  9 15:22:02 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 09 Jun 2010 13:22:02 +0000
Subject: [issue8953] Syntax error in
	http://docs.python.org/library/decimal.html#recipes
In-Reply-To: <1276088865.47.0.391393017311.issue8953@psf.upfronthosting.co.za>
Message-ID: <1276089722.42.0.677211714417.issue8953@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8953>
_______________________________________

From report at bugs.python.org  Wed Jun  9 16:20:44 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 09 Jun 2010 14:20:44 +0000
Subject: [issue8954] wininst regression: errors when building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

2.5.1 version of distutils was able to correctly build wininst dists from linux. Right now there are errors which I'll describe in more details once I can get some Linux box.

----------
assignee: tarek
components: Distutils
messages: 107398
nosy: tarek, techtonik
priority: normal
severity: normal
status: open
title: wininst regression: errors when building on linux
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8954>
_______________________________________

From report at bugs.python.org  Wed Jun  9 16:23:56 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 09 Jun 2010 14:23:56 +0000
Subject: [issue8954] wininst regression: errors when building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1276093436.97.0.63686856312.issue8954@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

At least is was reported that compiled binaries contains wrong platform name, i.e. 'linux' and there are errors about inability to look up some compiler options in windows registry while building.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8954>
_______________________________________

From report at bugs.python.org  Wed Jun  9 16:37:02 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 09 Jun 2010 14:37:02 +0000
Subject: [issue8954] wininst regression: errors when building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1276094222.55.0.553639928055.issue8954@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Where was that reported?

----------
nosy: +brian.curtin
stage:  -> unit test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8954>
_______________________________________

From report at bugs.python.org  Wed Jun  9 17:12:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Jun 2010 15:12:41 +0000
Subject: [issue8941] utf-32be codec failing on UCS-2 python build for
	32-bit	value
In-Reply-To: <1276013724.21.0.174818104611.issue8941@psf.upfronthosting.co.za>
Message-ID: <1276096361.9.0.0288036083746.issue8941@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a new patch with tests.

> I wonder whether it wouldn't be better to preallocate
> a Unicode object with size of e.g. size/4 + 16 and
> then resize the object as necessary in case a surrogate
> pair needs to be created (won't happen that often in
> practice).
> 
> The extra scan for pairs can take long depending on
> how much data you have to decode and likely doesn't
> go down well with CPU caches.

Perhaps, but I think this should measured and be the target of a separate issue. We're in rc phase and we should probably minimize potential disruption.

----------
Added file: http://bugs.python.org/file17598/utf32-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8941>
_______________________________________

From report at bugs.python.org  Wed Jun  9 17:17:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Jun 2010 15:17:25 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1276096645.43.0.2408957473.issue1100942@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I have updated Amaury's patch for py3k.  I simplified the test for default date values and fixed a documentation nit. (Time fileds are [4:7], not [4:6]).  The result is attached as issue1100942.diff.

Note that date.strptime accepts some time specs and time.strptime accepts some date specs:

>>> time.strptime('1900', '%Y')
datetime.time(0, 0)
>>> date.strptime('00', '%H')
datetime.date(1900, 1, 1)

This matches the proposed documentation, but I am not sure is desirable.  
I am about +0 for making the test more robust by scanning the format string and rejecting date format codes in time.strptime and time format codes in date.  This will also allow better diagnostic messages.  For example, instead of 

>>> date.strptime('01', '%M')
Traceback (most recent call last):
  ..
ValueError: date.strptime value cannot have a time part

we can produce "'%M' is not valid in date format specification."

----------
keywords: +easy, patch
Added file: http://bugs.python.org/file17599/issue1100942.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Wed Jun  9 17:31:30 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 09 Jun 2010 15:31:30 +0000
Subject: [issue8947] Provide  as_integer_ratio() method to Decimal
In-Reply-To: <1276030268.17.0.98739433208.issue8947@psf.upfronthosting.co.za>
Message-ID: <1276097490.26.0.26800306496.issue8947@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8947>
_______________________________________

From report at bugs.python.org  Wed Jun  9 17:44:15 2010
From: report at bugs.python.org (James)
Date: Wed, 09 Jun 2010 15:44:15 +0000
Subject: [issue8955] import doesn't notice changes to working directory
In-Reply-To: <1276098255.67.0.264247838489.issue8955@psf.upfronthosting.co.za>
Message-ID: <1276098255.67.0.264247838489.issue8955@psf.upfronthosting.co.za>


New submission from James <purpleidea at gmail.com>:

Attempting to change the working directory and then import based on that change has no effect. Import seems impossible. Attached is tarball example. As seen below, bar1.py can import foo from src, however bar2.py bar3.py and bar4.py cannot, despite their respective scripts changing their cwd. Below is results of a terminal session. Thanks in advance.

james at hostname:~$ tree import_bug/
import_bug/
|-- bar1.py
|-- __init__.py
|-- src
|   |-- foo.py
|   `-- __init__.py
`-- test
    |-- bar2.py
    |-- bar3.py
    |-- bar4.py
    |-- bar5.py
    `-- __init__.py

2 directories, 9 files
james at hostname:~$ cat import_bug/src/foo.py 
# this is foo.py
print('this is foo.py')

james at hostname:~$ cat import_bug/bar1.py 
# this is bar1.py
import os



print(os.getcwd())
from src import foo
print('this is bar1.py')

james at hostname:~$ cat import_bug/test/bar2.py 
# this is bar2.py
import os

os.chdir(os.path.join(os.path.dirname(__file__), os.pardir))

print(os.getcwd())
from src import foo
print('this is bar2.py')

james at hostname:~$ python import_bug/bar1.py 
/home/james
this is foo.py
this is bar1.py
james at hostname:~$ python import_bug/test/bar2.py 
/home/james/import_bug
Traceback (most recent call last):
  File "import_bug/test/bar2.py", line 7, in <module>
    from src import foo
ImportError: No module named src
james at hostname:~$

----------
components: Library (Lib)
files: import_bug.tar
messages: 107403
nosy: purpleidea
priority: normal
severity: normal
status: open
title: import doesn't notice changes to working directory
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file17600/import_bug.tar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8955>
_______________________________________

From report at bugs.python.org  Wed Jun  9 18:36:56 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 09 Jun 2010 16:36:56 +0000
Subject: [issue8941] utf-32be codec failing on UCS-2 python build for
	32-bit	value
In-Reply-To: <1276096361.9.0.0288036083746.issue8941@psf.upfronthosting.co.za>
Message-ID: <4C0FC326.6020800@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> Here is a new patch with tests.
> 
>> I wonder whether it wouldn't be better to preallocate
>> a Unicode object with size of e.g. size/4 + 16 and
>> then resize the object as necessary in case a surrogate
>> pair needs to be created (won't happen that often in
>> practice).
>>
>> The extra scan for pairs can take long depending on
>> how much data you have to decode and likely doesn't
>> go down well with CPU caches.
> 
> Perhaps, but I think this should measured and be the target of a separate issue. We're in rc phase and we should probably minimize potential disruption.

Fair enough.

Here's a little optimization:

-        if (qq[iorder[3]] != 0 || qq[iorder[2]] != 0)
+        if (qq[iorder[2]] != 0 || qq[iorder[3]] != 0)

For non-BMP code points, it's more likely that byte 2
will be non-zero.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8941>
_______________________________________

From report at bugs.python.org  Wed Jun  9 18:57:15 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 09 Jun 2010 16:57:15 +0000
Subject: [issue8077] cgi handling of POSTed files is broken
In-Reply-To: <1267839820.97.0.586792235494.issue8077@psf.upfronthosting.co.za>
Message-ID: <1276102635.71.0.0321536018137.issue8077@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

The example works for me if I make this change:

--- Lib/cgi.py	(revision 81862)
+++ Lib/cgi.py	(working copy)
@@ -608,7 +608,7 @@
         parser = email.parser.FeedParser()
         # Create bogus content-type header for proper multipart parsing
         parser.feed('Content-Type: %s; boundary=%s\r\n\r\n' % (self.type, ib))
-        parser.feed(self.fp.read())
+        parser.feed(self.fp.read(self.length))
         full_msg = parser.close()
         # Get subparts
         msgs = full_msg.get_payload()


However this seems iffy to me because the content length presumably counts bytes whereas self.fp seems to be a text file, but since most HTTP clients don't close the connection, without some kind of boundary on the read() call it just hangs forever.

Also someone pointed out to me offline that this change may be needed, separately (though I haven't confirmed this yet):

--- Lib/cgi.py	(revision 81862)
+++ Lib/cgi.py	(working copy)
@@ -233,6 +233,7 @@
         lines = []
         while 1:
             line = fp.readline()
+            line = line.decode()
             if not line:
                 terminator = lastpart # End outer loop
                 break

----------
components:  -Documentation
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8077>
_______________________________________

From report at bugs.python.org  Wed Jun  9 18:59:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Jun 2010 16:59:23 +0000
Subject: [issue8930] messed up formatting after reindenting
In-Reply-To: <1275862117.51.0.974367285734.issue8930@psf.upfronthosting.co.za>
Message-ID: <1276102763.91.0.219752796217.issue8930@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've fixed some in r81860. If you see others, please signal them here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8930>
_______________________________________

From report at bugs.python.org  Wed Jun  9 19:25:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Jun 2010 17:25:34 +0000
Subject: [issue8949] PyArg_Parse*(): "z" should not accept bytes
In-Reply-To: <1276032203.54.0.364398342729.issue8949@psf.upfronthosting.co.za>
Message-ID: <1276104334.69.0.251858792876.issue8949@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8949>
_______________________________________

From report at bugs.python.org  Wed Jun  9 19:39:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 09 Jun 2010 17:39:57 +0000
Subject: [issue8955] import doesn't notice changes to working directory
In-Reply-To: <1276098255.67.0.264247838489.issue8955@psf.upfronthosting.co.za>
Message-ID: <1276105197.0.0.909837028194.issue8955@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is working as designed.

Try printing sys.path in your scripts.  It is what's in sys.path that matters, not the cwd.  (The cwd is put in the path as "" in the specific case of running the python interactive shell...and in certain applications that embed Python because of a bug in those applications.)

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8955>
_______________________________________

From report at bugs.python.org  Wed Jun  9 19:45:29 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 09 Jun 2010 17:45:29 +0000
Subject: [issue5115] Extend subprocess.kill to be able to kill process groups
In-Reply-To: <1233370260.58.0.70597374825.issue5115@psf.upfronthosting.co.za>
Message-ID: <1276105529.54.0.265390848735.issue5115@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5115>
_______________________________________

From report at bugs.python.org  Wed Jun  9 20:25:36 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 09 Jun 2010 18:25:36 +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: <1276107936.75.0.980203852578.issue8956@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

def send_signal(self, sig):
            """Send a signal to the process
            """
            if sig == signal.SIGTERM:
                self.terminate()
            elif sig == signal.CTRL_C_EVENT:
                os.kill(self.pid, signal.CTRL_C_EVENT)
            elif sig == signal.CTRL_BREAK_EVENT:
                os.kill(self.pid, signal.CTRL_BREAK_EVENT)
            else:
                raise ValueError("Only SIGTERM is supported on Windows")


Just noticed right now while I was reading subprocess source code.
I guess that should be "Only SIGTERM, CTRL_C_EVENT or CTRL_BREAK_EVENT are supported on Windows".

----------
components: Library (Lib)
messages: 107408
nosy: astrand, giampaolo.rodola
priority: normal
severity: normal
status: open
title: Incorrect ValueError message for subprocess.Popen.send_signal() on Windows
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8956>
_______________________________________

From report at bugs.python.org  Wed Jun  9 20:37:25 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 09 Jun 2010 18:37:25 +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: <1276108645.31.0.245059216912.issue8956@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Good catch, I forgot to update that message when adding the other signal support.

Would you rather see something more generic like "Unsupported signal" rather than start listing all of the signals?

Another alternative is to allow any signal through including integers, which are then just passed to os.kill (ints passed to kill get set as the proc exit code). However, we can't do that with 2.7, but could with 3.2.

----------
assignee:  -> brian.curtin
components: +Windows
nosy: +brian.curtin
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8956>
_______________________________________

From report at bugs.python.org  Wed Jun  9 20:49:30 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 09 Jun 2010 18:49:30 +0000
Subject: [issue7839] Popen should raise ValueError if pass a string when
	shell=False or a list when shell=True
In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za>
Message-ID: <1276109370.72.0.91619218942.issue7839@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/issue7839>
_______________________________________

From report at bugs.python.org  Wed Jun  9 20:51:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Jun 2010 18:51:08 +0000
Subject: [issue2267] datetime.datetime operator methods are not
	subclass-friendly
In-Reply-To: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za>
Message-ID: <1276109468.29.0.842124770808.issue2267@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I would like to take another shot at this. The link in Amaury's closing comment no longer works, so here is the relevant post:

"""
Returning same type as self for arithmetic in subclasses

Tim Peters tim.peters at gmail.com 
Sat Jan 8 02:09:27 CET 2005

[Max M]
> """
> I subclass datetime and timedelta
> 
> >>> dt = myDatetime(1970,1,1)
> >>> type(dt)
> <class 'dtime.myDatetime'>
> 
> >>> td = myTimedelta(hours=1)
> >>> type(td)
> <class 'dtime.myTimedelta'>
> 
> But when I do arithmetic with these classes, they return datetime and
> timedelta,
...
> >>> new_time = dt + td
> >>> new_time
> datetime.datetime(1970, 1, 1, 1, 0)
> 
> >>> type(new_time)
> <type 'datetime.datetime'>

Yes, and all builtin Python types work that way.  For example,
int.__add__ or float.__add__ applied to a subclass of int or float
will return an int or float; similarly for a subclass of str.  This
was Guido's decision, based on that an implementation of any method in
a base class has no idea what requirements may exist for invoking a
subclass's constructor.  For example, a subclass may restrict the
values of constructor arguments, or require more arguments than a base
class constructor; it may permute the order of positional arguments in
the base class constructor; it may even be "a feature" that a subclass
constructor gives a different meaning to an argument it shares with
the base class constructor.  Since there isn't a way to guess, Python
does a safe thing instead.

> where I want them to return myDatetime and myTimedelta
>
> So I wondered if there was a simlpler way to coerce the result into my
> desired types rather than overwriting the __add__, __sub__ etc. methods?

Generally speaking, no.  But I'm sure someone will torture you with a
framework that purports to make it easy <wink>.
"""  http://mail.python.org/pipermail/python-list/2005-January/925838.html


As I explained in my previous post, the same argument, "base class has no idea what requirements may exist for invoking a subclass's constructor", applies to class methods, but they nevertheless consistently construct subclass instances:

>>> class d(datetime): pass
>>> d.utcfromtimestamp(0)
d(1970, 1, 1, 0, 0)
>>> d.fromtimestamp(0)
d(1969, 12, 31, 19, 0)
>>> d.combine(date(1,1,1), time(1,1))
d(1, 1, 1, 1, 1)


Similar example for the date class:

>>> class Date(date): pass
>>> Date.fromordinal(1)
Date(1, 1, 1)


In my view it is hard to justify that for a Date instance d, and integer days, Date.fromordinal(d.toordinal() + days) happily produces a Date instance, but d + timedelta(days) returns a basic date instance.

----------
assignee:  -> belopolsky
components: +Extension Modules -Library (Lib)
nosy: +mark.dickinson
resolution: wont fix -> 
status: closed -> open
versions: +Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2267>
_______________________________________

From report at bugs.python.org  Wed Jun  9 20:55:08 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 09 Jun 2010 18:55:08 +0000
Subject: [issue6457] subprocess.Popen.communicate can lose data from
	output/error streams when broken input pipe occures
In-Reply-To: <1247229365.37.0.486388451669.issue6457@psf.upfronthosting.co.za>
Message-ID: <1276109708.39.0.70054518.issue6457@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/issue6457>
_______________________________________

From report at bugs.python.org  Wed Jun  9 21:48:51 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 09 Jun 2010 19:48:51 +0000
Subject: [issue6973] subprocess.Popen.send_signal doesn't check whether the
	process has terminated
In-Reply-To: <1253659668.76.0.344119676181.issue6973@psf.upfronthosting.co.za>
Message-ID: <1276112931.18.0.287025323111.issue6973@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I totally agree this should be fixed (there was a similar issue for psutil: http://code.google.com/p/psutil/issues/detail?id=58) but communicate() and wait() should be affected in the same manner.

Probably it would make sense to add an is_running() method and decorate send_signal(), kill(), communicate() and wait() methods with a function which makes sure that the process is still running, otherwise raises an exception instead.

Maybe it would also makes sense to provide a brand new NoSuchProcess exception class.

----------
nosy: +astrand, brian.curtin, giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6973>
_______________________________________

From report at bugs.python.org  Wed Jun  9 22:06:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Jun 2010 20:06:21 +0000
Subject: [issue1578643] various datetime methods fail in restricted mode
Message-ID: <1276113981.25.0.966297233022.issue1578643@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I would like to remove datetime module dependency on time module altogether.  For example getting timestamp as a float and later break it into sec/usec just to satisfy time module API looks rather inefficient.

----------
assignee:  -> belopolsky
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578643>
_______________________________________

From report at bugs.python.org  Wed Jun  9 22:24:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Jun 2010 20:24:41 +0000
Subject: [issue8957] strptime('%c', ..) fails to parse output of strftime('%c',
	..) in non-English locale
In-Reply-To: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>
Message-ID: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

The following code:

import locale, time
locale.setlocale(locale.LC_ALL, "fr_FR.UTF-8")
t = time.localtime()
s = time.strftime('%c', t)
time.strptime('%c', s)

Raises

ValueError: time data '%c' does not match format 'Mer  9 jui 16:14:46 2010'

in any locale where month follows day in '%c' format.  Note that attached C code works as expected on my OSX laptop.

I wonder it it would make sense to call platform strptime where available? I wonder if platform support for strptime has improved since 2002 when _strptime.py was introduced.

----------
assignee: belopolsky
components: Extension Modules
files: strptime-locale-bug.c
messages: 107413
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: strptime('%c', ..) fails to parse output of strftime('%c', ..) in non-English locale
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file17601/strptime-locale-bug.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Wed Jun  9 22:25:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Jun 2010 20:25:05 +0000
Subject: [issue8957] strptime('%c', ..) fails to parse output of strftime('%c',
	..) in non-English locale
In-Reply-To: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>
Message-ID: <1276115105.78.0.14013709193.issue8957@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17602/strptime-locale-bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8957>
_______________________________________

From report at bugs.python.org  Wed Jun  9 22:31:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Jun 2010 20:31:16 +0000
Subject: [issue2267] datetime.datetime operator methods are not
	subclass-friendly
In-Reply-To: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za>
Message-ID: <1276115476.39.0.325748491706.issue2267@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

If you want to challenge Guido's design decision, I think python-dev would be the place to do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2267>
_______________________________________

From report at bugs.python.org  Wed Jun  9 22:55:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Jun 2010 20:55:12 +0000
Subject: [issue7739] time.strftime may hung while trying to open
	/etc/localtime but does not release GIL
In-Reply-To: <1263893036.59.0.158350465414.issue7739@psf.upfronthosting.co.za>
Message-ID: <1276116912.75.0.168529945631.issue7739@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Victor,

I understand your last comment as wanting to keep the GIL while calling tzset(), but release it around the strftime() call.  You still want to apply your patch, right?

I think the problem is not with a concurrent tzset() call, but with another thread changing TZ environment variable.

See http://sourceware.org/bugzilla/show_bug.cgi?id=4350

----------
assignee:  -> belopolsky
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7739>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:03:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Jun 2010 21:03:19 +0000
Subject: [issue2267] datetime.datetime operator methods are not
	subclass-friendly
In-Reply-To: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za>
Message-ID: <1276117399.26.0.468914284034.issue2267@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> If you want to challenge Guido's design decision, I think
> python-dev would be the place to do it.

Do you have a link supporting that it was "Guido's design decision"?  This decision must have been made around class/type unification, but I don't remember reading about it in Guido's essays.

I don't want to make a fool of myself by coming to python-dev with this unprepared. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2267>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:06:01 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Jun 2010 21:06:01 +0000
Subject: [issue2267] datetime.datetime operator methods are not
	subclass-friendly
In-Reply-To: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za>
Message-ID: <1276117561.34.0.179126049684.issue2267@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I also believe something needs to be fixed here in any case.  Either Date.fromordinal(..) should return date or Date(..) + timedelta(..) should return Date.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2267>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:08:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Jun 2010 21:08:37 +0000
Subject: [issue2267] datetime.datetime operator methods are not
	subclass-friendly
In-Reply-To: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za>
Message-ID: <1276117717.16.0.614469735923.issue2267@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Do you have a link [...]

Nope.  Just going on Tim's description of it as "Guido's decision".  I've no idea of the history, and I don't particularly recall any recent relevant python-dev discussions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2267>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:17:04 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 21:17:04 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1276118224.07.0.883647061649.issue3297@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.4, Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3297>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:20:21 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 21:20:21 +0000
Subject: [issue1193610] Expat Parser to supply document locator in incremental
	parse
Message-ID: <1276118421.47.0.289283762969.issue1193610@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2 -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1193610>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:20:55 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 09 Jun 2010 21:20:55 +0000
Subject: [issue8958] 2.7rc1 tarfile.py: `bltn_open(targetpath,
	"wb")` -> IOError: Is a directory
In-Reply-To: <1276118455.66.0.211402542637.issue8958@psf.upfronthosting.co.za>
Message-ID: <1276118455.66.0.211402542637.issue8958@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

1. Find an OSX 10.5.8 machine 
2. wget http://hntool.googlecode.com/files/hntool-0.1.1.tar.gz
3. $ python2.7 -c "import tarfile as T; t=T.open('hntool-0.1.1.tar.gz'); t.extractall()"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py", line 2046, in extractall
    self.extract(tarinfo, path)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py", line 2083, in extract
    self._extract_member(tarinfo, os.path.join(path, tarinfo.name))
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py", line 2159, in _extract_member
    self.makefile(tarinfo, targetpath)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py", line 2198, in makefile
    target = bltn_open(targetpath, "wb")
IOError: [Errno 21] Is a directory: './hntool-0.1.1/hntool'

...


Note that, when extracted open via other tools, hntool-0.1.1.tar.gz contains within it ... both a directory named "HnTool" (note the case) and a file  called "hntool".

----------
components: Library (Lib)
messages: 107419
nosy: srid
priority: normal
severity: normal
status: open
title: 2.7rc1 tarfile.py: `bltn_open(targetpath, "wb")` -> IOError: Is a directory
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8958>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:20:57 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 21:20:57 +0000
Subject: [issue1193610] Expat Parser to supply document locator in incremental
	parse
Message-ID: <1276118457.84.0.682629691207.issue1193610@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1193610>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:23:58 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 21:23:58 +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: <1276118638.07.0.48105209517.issue4947@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4947>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:25:35 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 21:25:35 +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: <1276118735.92.0.851555057153.issue1856@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1856>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:28:01 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 21:28:01 +0000
Subject: [issue5302] Allow package_data globs match directories
In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za>
Message-ID: <1276118881.67.0.94649949755.issue5302@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
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/issue5302>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:29:09 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 21:29:09 +0000
Subject: [issue3710] Reference leak in thread._local
In-Reply-To: <1219882144.91.0.399316525956.issue3710@psf.upfronthosting.co.za>
Message-ID: <1276118949.56.0.984268339381.issue3710@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3710>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:34:25 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 21:34:25 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1276119265.14.0.0114916331052.issue2620@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Brett, open and fixed are contradictory? for what version did you reopen this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2620>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:36:47 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 21:36:47 +0000
Subject: [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1276119407.2.0.302066539858.issue1753718@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1753718>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:37:24 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 21:37:24 +0000
Subject: [issue1767511] SocketServer.DatagramRequestHandler
Message-ID: <1276119444.24.0.950394870551.issue1767511@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767511>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:39:21 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 21:39:21 +0000
Subject: [issue2020] _sha256 module missing if openssl is not in a "normal"
	directory.
In-Reply-To: <1202312744.16.0.269773483749.issue2020@psf.upfronthosting.co.za>
Message-ID: <1276119561.37.0.203592529234.issue2020@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Does this 2.5 issue apply to anything current?

----------
nosy: +tjreedy
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2020>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:41:28 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 21:41:28 +0000
Subject: [issue1739842] xmlrpclib can no longer marshal Fault objects
Message-ID: <1276119688.02.0.976494998964.issue1739842@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
status: open -> closed
versions: +Python 2.6 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1739842>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:43:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 09 Jun 2010 21:43:07 +0000
Subject: [issue5302] Allow package_data globs match directories
In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za>
Message-ID: <1276119787.82.0.233078192087.issue5302@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Terry, I?m undoing your changes. Tarek told me to set these versions, since Distutils2 will be compatible from 2.4 to 3.2. Triaging-ly y?rs ;)

----------
versions: +Python 2.5, Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5302>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:44:22 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 21:44:22 +0000
Subject: [issue2401] Solaris: ctypes tests being skipped despite following
	#1516
In-Reply-To: <1205867491.87.0.489555231909.issue2401@psf.upfronthosting.co.za>
Message-ID: <1276119862.2.0.124552178322.issue2401@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Does this apply to any current version?

----------
nosy: +tjreedy
resolution:  -> out of date
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2401>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:57:05 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 21:57:05 +0000
Subject: [issue2148] nis module not supporting group aliases
In-Reply-To: <1203510631.66.0.497834646199.issue2148@psf.upfronthosting.co.za>
Message-ID: <1276120625.32.0.306176801542.issue2148@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Is this really a bug (discrepancy between nis.cat doc and behavior) or a feature request?

----------
nosy: +tjreedy
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2148>
_______________________________________

From report at bugs.python.org  Wed Jun  9 23:59:34 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 21:59:34 +0000
Subject: [issue2174] xml.sax.xmlreader does not support the InputSource
	protocol
In-Reply-To: <1203861152.32.0.18277152276.issue2174@psf.upfronthosting.co.za>
Message-ID: <1276120774.56.0.125295580478.issue2174@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2174>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:00:39 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 22:00:39 +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: <1276120839.54.0.216725141447.issue2175@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2175>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:02:12 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 22:02:12 +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: <1276120932.87.0.183118775474.issue1483@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Are this and the other issues still problems in 2.7 (rc out now) and 3.1?

----------
nosy: +tjreedy
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1483>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:04:49 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 22:04:49 +0000
Subject: [issue2209] mailbox module doesn't support compressed mbox
In-Reply-To: <1204283686.29.0.398991298124.issue2209@psf.upfronthosting.co.za>
Message-ID: <1276121089.94.0.115834790759.issue2209@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2209>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:08:03 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 22:08:03 +0000
Subject: [issue2212] Cookie.BaseCookie has ambiguous unicode handling
In-Reply-To: <1204315669.5.0.476777122389.issue2212@psf.upfronthosting.co.za>
Message-ID: <1276121283.75.0.360593210224.issue2212@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Sean, I don't understand 'inline' in this context.

----------
nosy: +tjreedy
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2212>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:10:52 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 22:10:52 +0000
Subject: [issue2126] BaseHTTPServer.py fails long POST from IE
In-Reply-To: <1203167938.11.0.556138107236.issue2126@psf.upfronthosting.co.za>
Message-ID: <1276121452.97.0.259671540452.issue2126@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2126>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:12:13 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 22:12:13 +0000
Subject: [issue2604] doctest.DocTestCase fails when run repeatedly
In-Reply-To: <1207798847.15.0.203205049744.issue2604@psf.upfronthosting.co.za>
Message-ID: <1276121533.6.0.519922645257.issue2604@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.4, Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2604>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:13:56 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 22:13:56 +0000
Subject: [issue1738] filecmp.dircmp does exact match only
In-Reply-To: <1199482445.72.0.241275927673.issue1738@psf.upfronthosting.co.za>
Message-ID: <1276121636.91.0.105707635776.issue1738@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1738>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:14:10 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 22:14:10 +0000
Subject: [issue1738] filecmp.dircmp does exact match only
In-Reply-To: <1199482445.72.0.241275927673.issue1738@psf.upfronthosting.co.za>
Message-ID: <1276121650.04.0.687779123736.issue1738@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1738>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:15:03 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 22:15:03 +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: <1276121703.87.0.971083125201.issue1874@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1874>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:16:33 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 22:16:33 +0000
Subject: [issue2818] pulldom cannot handle xml file with large external entity
	properly
In-Reply-To: <1210512738.34.0.315015103661.issue2818@psf.upfronthosting.co.za>
Message-ID: <1276121793.95.0.905763995682.issue2818@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2818>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:17:09 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 22:17:09 +0000
Subject: [issue2840] Expat parser locks XML source file if ContentHandler
	raises an exception
In-Reply-To: <1210621474.39.0.327877522239.issue2840@psf.upfronthosting.co.za>
Message-ID: <1276121829.79.0.607191176278.issue2840@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2840>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:18:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2010 22:18:50 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1276121930.83.0.648294639533.issue8604@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Trac has an AtomicFile class which copies file mode, owner, etc.
http://trac.edgewall.org/browser/trunk/trac/util/__init__.py?#L145

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:19:08 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 22:19:08 +0000
Subject: [issue2892] improve cElementTree iterparse error handling
In-Reply-To: <1210940435.5.0.243679200602.issue2892@psf.upfronthosting.co.za>
Message-ID: <1276121948.2.0.782679273265.issue2892@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
type: behavior -> feature request
versions: +Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2892>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:19:50 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 22:19:50 +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: <1276121990.09.0.665996267141.issue1257@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.4, Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1257>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:23:37 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 22:23:37 +0000
Subject: [issue2901] "error: can't allocate region" from mmap() when receiving
	big chunk of data
In-Reply-To: <1211069816.05.0.311102248623.issue2901@psf.upfronthosting.co.za>
Message-ID: <1276122217.04.0.629727992978.issue2901@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Please test on 2.6 or better, 2.7 (rc already out) and 3.1 to verify there still is a problem.

----------
nosy: +tjreedy
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2901>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:29:37 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 22:29:37 +0000
Subject: [issue1730136] tkFont.__eq__ gives type error
Message-ID: <1276122577.71.0.129865749327.issue1730136@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree that this change is sensible and verified that it is needed for 3.1 as well. I think it should be applied.

----------
nosy: +tjreedy
stage:  -> commit review
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1730136>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:29:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Jun 2010 22:29:49 +0000
Subject: [issue1738] filecmp.dircmp does exact match only
In-Reply-To: <1199482445.72.0.241275927673.issue1738@psf.upfronthosting.co.za>
Message-ID: <1276122589.04.0.352036148025.issue1738@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The patch does not apply to py3k branch.

----------
assignee:  -> belopolsky
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1738>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:33:36 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 22:33:36 +0000
Subject: [issue3053] test_shutil fails under AIX
In-Reply-To: <1212763867.85.0.395528995267.issue3053@psf.upfronthosting.co.za>
Message-ID: <1276122816.05.0.865422574937.issue3053@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3053>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:37:26 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 22:37:26 +0000
Subject: [issue2657] Curses sometimes fails to initialize terminal
In-Reply-To: <1208559068.96.0.196247088071.issue2657@psf.upfronthosting.co.za>
Message-ID: <1276123046.46.0.449397155404.issue2657@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Is this an issue with 2.7 or 3.1?

----------
nosy: +tjreedy
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2657>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:39:11 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 09 Jun 2010 22:39:11 +0000
Subject: [issue8954] wininst regression: errors when building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1276123151.43.0.127800509324.issue8954@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

In this SCons thread http://scons.tigris.org/ds/viewMessage.do?dsForumId=1268&dsMessageId=2617686

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8954>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:46:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2010 22:46:21 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1276123581.83.0.525381899307.issue8828@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

About the function names:
 - shutil.atomic_move_file(): only available on some OS
 - shutil.move_file(): use shutil.atomic_move_file() if available, or fall back to a best effort implementation

Implement an atomic function to rename a directory is more complex and should be done in another issue. That's why I added "_file" suffix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:52:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2010 22:52:36 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1276123956.01.0.973687045781.issue8828@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

[atomic_move_file-windows.py]: implementation of atomic_move_file() for Windows, depends on CreateTransaction() and MoveFileTransacted(), only available on Windows Vista, Windows Server 2008, or more recent version. This function *is* atomic.

This function is also able to rename a directory!

----------
Added file: http://bugs.python.org/file17603/atomic_move_file-windows.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:57:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2010 22:57:03 +0000
Subject: [issue8784] tarfile/Windows: Don't use mbcs as the default encoding
In-Reply-To: <1274491335.43.0.732437213128.issue8784@psf.upfronthosting.co.za>
Message-ID: <1276124223.75.0.29436500518.issue8784@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I created a TAR archive with the 7-zip archiver of file with diacritics in their name (eg. "?" and "?"). Then I opened the archive with WinRAR: the file names were not displayed correctly :-/

7-zip encodes "?" (U+00e0) as 0x85 (1 byte), and "?" (U+00e9) as 0x82 (1 byte). I don't know this encoding.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8784>
_______________________________________

From report at bugs.python.org  Thu Jun 10 00:58:36 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Jun 2010 22:58:36 +0000
Subject: [issue665194] datetime-RFC2822 roundtripping
Message-ID: <1276124316.51.0.0234833695293.issue665194@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

-1 on adding more formatting/parsing methods to datetime. +1 on adding functions to email.utils that work with datetime objects.  Adding #5094 as a dependency because RFC 2822 requires timezone information for proper formatting.

----------
dependencies: +datetime lacks concrete tzinfo impl. for UTC
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue665194>
_______________________________________

From report at bugs.python.org  Thu Jun 10 01:05:38 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 23:05:38 +0000
Subject: [issue3129] struct allows repeat spec. without a format specifier
In-Reply-To: <1213694469.69.0.0950890622628.issue3129@psf.upfronthosting.co.za>
Message-ID: <1276124738.71.0.524652191464.issue3129@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I verified that 3.1 has same behavior. Doc says format strings "are built up from format characters" which "may be preceded by an integral repeat count". So I agree that such formats are bugs that should be reported and that ignoring repeat counts of nothing is a bug.

While I cannot apply and test the (trivial) patch, I read it and it looks sensible. Pending independent test, I would say apply. I am not familiar with whether it needs to be rebuilt against current code or not.

----------
keywords: +patch
nosy: +tjreedy
stage:  -> commit review
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3129>
_______________________________________

From report at bugs.python.org  Thu Jun 10 01:07:13 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 23:07:13 +0000
Subject: [issue3213] "pydoc -p" should listen to [::] if IPv6 is supported
In-Reply-To: <1214525489.78.0.574038651579.issue3213@psf.upfronthosting.co.za>
Message-ID: <1276124833.67.0.863123275927.issue3213@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3213>
_______________________________________

From report at bugs.python.org  Thu Jun 10 01:09:12 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 09 Jun 2010 23:09:12 +0000
Subject: [issue8784] tarfile/Windows: Don't use mbcs as the default encoding
In-Reply-To: <1276124223.75.0.29436500518.issue8784@psf.upfronthosting.co.za>
Message-ID: <4C101F12.7090102@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 created a TAR archive with the 7-zip archiver of file with diacritics in their name (eg. "?" and "?"). Then I opened the archive with WinRAR: the file names were not displayed correctly :-/
> 
> 7-zip encodes "?" (U+00e0) as 0x85 (1 byte), and "?" (U+00e9) as 0x82 (1 byte). I don't know this encoding.

That's an old DOS code paged used in Europe: CP850

http://en.wikipedia.org/wiki/Code_page_850

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8784>
_______________________________________

From report at bugs.python.org  Thu Jun 10 01:16:47 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 23:16:47 +0000
Subject: [issue3276] httplib.HTTPConnection._send_request should not blindly
	assume dicts for headers
In-Reply-To: <1215130769.47.0.0230905543783.issue3276@psf.upfronthosting.co.za>
Message-ID: <1276125407.07.0.623232365167.issue3276@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is a feature request for now old versions. It would have to be reformulated as a feature request for a 3.2 module. I do not see the dict (mapping now?) requirement being changed.

----------
nosy: +tjreedy
resolution:  -> out of date
status: open -> pending
type:  -> feature request
versions:  -Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3276>
_______________________________________

From report at bugs.python.org  Thu Jun 10 01:21:37 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 09 Jun 2010 23:21:37 +0000
Subject: [issue8784] tarfile/Windows: Don't use mbcs as the default encoding
In-Reply-To: <4C101F12.7090102@egenix.com>
Message-ID: <4C1021FD.8050307@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Marc-Andre Lemburg wrote:
> 
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> 
> STINNER Victor wrote:
>>
>> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>>
>> I created a TAR archive with the 7-zip archiver of file with diacritics in their name (eg. "?" and "?"). Then I opened the archive with WinRAR: the file names were not displayed correctly :-/
>>
>> 7-zip encodes "?" (U+00e0) as 0x85 (1 byte), and "?" (U+00e9) as 0x82 (1 byte). I don't know this encoding.
> 
> That's an old DOS code paged used in Europe: CP850
> 
> http://en.wikipedia.org/wiki/Code_page_850

Looks like the cmd.exe on WinXP still uses it. At least on my German
WinXP it does for Python 2.3 and older. Starting with Python 2.4,
the behavior changed to use CP1252 instead:

D:\Python26>python
Python 2.6 (r26:66721, Oct  2 2008, 11:35:03) [MSC v.1500 32 bit (Intel)] on wi
32
Type "help", "copyright", "credits" or "license" for more information.
>>> u'??'
u'\xe0\xe9'

D:\Python25>python
Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> u'??'
u'\xe1\xe9'

D:\Python24>python
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> u'??'
u'\xe0\xe9'

D:\Python23>python
Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> u'??'
u'\x85\x82'
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8784>
_______________________________________

From report at bugs.python.org  Thu Jun 10 01:42:38 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 23:42:38 +0000
Subject: [issue3423] DeprecationWarning message applies to wrong context with
	exec()
In-Reply-To: <1216687242.26.0.837867299264.issue3423@psf.upfronthosting.co.za>
Message-ID: <1276126958.93.0.402761511433.issue3423@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In 3.1, I get
>>> exec("1/0")
Traceback (most recent call last):
  File "<pyshell#5>", line 1, in <module>
    exec("1/0")
  File "<string>", line 1, in <module>
ZeroDivisionError: int division or modulo by zero

In your example, would you really prefer that the warning message start with "<string>1" (or the 2.x equivalent) instead of "t.py1"? If I were running a multi-file app with warnings turned on, I would prefer the latter. The message "DeprecationWarning: raising a string exception is deprecated" is certainly enough to suggest that one search the file for 'raise'.

In any case, this would only be a bug if it disagreed with docs or if this were different from the usual behavior with deprecation warnings. It is too late for new features in 2.x and this does not apply to 3.x.

----------
nosy: +tjreedy
resolution:  -> rejected
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3423>
_______________________________________

From report at bugs.python.org  Thu Jun 10 01:45:29 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 23:45:29 +0000
Subject: [issue3430] httplib.HTTPResponse documentations inconsistent
In-Reply-To: <1216747880.73.0.0581734704537.issue3430@psf.upfronthosting.co.za>
Message-ID: <1276127129.98.0.734644629291.issue3430@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Docs have been considerably updated since 2.5. Please check if this still applies to the 2.7 docs

----------
nosy: +tjreedy
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3430>
_______________________________________

From report at bugs.python.org  Thu Jun 10 01:48:52 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 23:48:52 +0000
Subject: [issue3456] compile python using MinGW
In-Reply-To: <1217231208.12.0.680278518143.issue3456@psf.upfronthosting.co.za>
Message-ID: <1276127332.55.0.842622793074.issue3456@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2 -Python 2.6, Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3456>
_______________________________________

From report at bugs.python.org  Thu Jun 10 01:49:10 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 23:49:10 +0000
Subject: [issue3456] compile python using MinGW
In-Reply-To: <1217231208.12.0.680278518143.issue3456@psf.upfronthosting.co.za>
Message-ID: <1276127350.38.0.573335192768.issue3456@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3456>
_______________________________________

From report at bugs.python.org  Thu Jun 10 01:57:14 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jun 2010 23:57:14 +0000
Subject: [issue3494] "[Errno 11] Resource temporarily unavailable" while using
	tracing facility/threads (in linux listdir with unicode path)
In-Reply-To: <1217704277.74.0.0700671746724.issue3494@psf.upfronthosting.co.za>
Message-ID: <1276127834.38.0.502960729504.issue3494@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

"The above fix could be backported."
Too late now.

----------
nosy: +tjreedy
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3494>
_______________________________________

From report at bugs.python.org  Thu Jun 10 02:14:24 2010
From: report at bugs.python.org (Greg Hazel)
Date: Thu, 10 Jun 2010 00:14:24 +0000
Subject: [issue3423] DeprecationWarning message applies to wrong context with
	exec()
In-Reply-To: <1216687242.26.0.837867299264.issue3423@psf.upfronthosting.co.za>
Message-ID: <1276128864.16.0.537137296814.issue3423@psf.upfronthosting.co.za>


Greg Hazel <ghazel at users.sourceforge.net> added the comment:

Searching the file for "raise" is sort of pointless, since exec() takes a string which might have come from anywhere, and there might be any number of exec() calls in the module. See: http://codepad.org/7EBMhb0O

There are at least two reasonable answers:

<string>:1: DeprecationWarning: raising a string exception is deprecated
  raise 'two'

or:

t.py:7: DeprecationWarning: raising a string exception is deprecated
  exec(x)

Either one would be fine, but randomly choosing the first line of the module where exec() is called is just nonsense.

If you want one that applies to Python 3.x, here you go: http://codepad.org/Mq1eZyoE

----------
status: closed -> open
versions: +Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3423>
_______________________________________

From report at bugs.python.org  Thu Jun 10 06:46:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Jun 2010 04:46:16 +0000
Subject: [issue8915] Use locale.nl_langinfo in _strptime
In-Reply-To: <1275795309.62.0.41465361185.issue8915@psf.upfronthosting.co.za>
Message-ID: <1276145176.69.0.301496673293.issue8915@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

See also issue8957.  If this happens, I would like to add a pure python implementation strftime.  See also issue7989.

----------
assignee:  -> belopolsky
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8915>
_______________________________________

From report at bugs.python.org  Thu Jun 10 07:27:36 2010
From: report at bugs.python.org (Atro Tossavainen)
Date: Thu, 10 Jun 2010 05:27:36 +0000
Subject: [issue2401] Solaris: ctypes tests being skipped despite following
	#1516
In-Reply-To: <1276119862.2.0.124552178322.issue2401@psf.upfronthosting.co.za>
Message-ID: <201006100527.o5A5RSdT016195@ruuvi.it.helsinki.fi>


Atro Tossavainen <atro.tossavainen+pythonbugs at helsinki.fi> added the comment:

> Does this apply to any current version?

Funny you should ask, I've just started building Python 2.6.5 yesterday.
I should know in a bit.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2401>
_______________________________________

From report at bugs.python.org  Thu Jun 10 09:06:00 2010
From: report at bugs.python.org (Michael Curran)
Date: Thu, 10 Jun 2010 07:06:00 +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: <1276153559.93.0.766128008061.issue8959@psf.upfronthosting.co.za>


New submission from Michael Curran <mick at nvaccess.org>:

There seem to be problems with WINFUNCTYPE callbacks causing exceptions, and or getting their return value ignored by the caller, when using Python 2.7 rc1.
Two examples provided.

Example 1:
Providing a WINFUNCTYPE wrapped python function when calling EnumWindows from user32.dll with ctypes, EnumWindows enumerates (calls the python function) for the first 5 windows and then causes a WindowsError, sometimes an access violation (reading, or writing), or even other strange unknown exceptions.
This specific testcase is attached to the bug.
Run this script in  Python 2.7 you should see the WindowsErrors. On Python 2.6 it successfully enumerates through all windows.

Example 2:
Hooking low-level keyboard input in Windows with SetWindowsHookEx from user32.dll, providing a WINFUNCTYPE wrapped python function as the callback, and then typing some keys, causes the callback to be called but the return value is always ignored, which means the hook never blocks keys completely, even if  the value 1 is returned from the callback, to do so.
Again, a testcase is attached to the bug.
Run this script in Python. It will ask you to type some characters and press enter. On Python 2.6 no characters should be echoed to the screen, but you will hear beeps to let you know the keyboard hook is seeing the keys. On Python 2.7, the keys will be echoed to the screen, and you will also hear the beeps (meaning that the hook was seeing the keys, but was unable to actually block them -- its return value was being ignored).
Also in Python 2.7, after the quit message is sent to the hook thread, GetMessageW (in user32.dll) causes a WindowsError exception. This does not happen on Python 2.6.

Perhaps it may be related to this entry in the Python 2.7 What's new:
The underlying libffi library has been updated to version 3.0.9, containing various fixes for different platforms. (Updated by Matthias Klose; issue 8142.)

----------
assignee: theller
components: ctypes
files: test_callbackRetval.py
messages: 107447
nosy: mdcurran, theller
priority: normal
severity: normal
status: open
title: WINFUNCTYPE wrapped ctypes callbacks not functioning correctly in Python 2.7
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file17604/test_callbackRetval.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8959>
_______________________________________

From report at bugs.python.org  Thu Jun 10 09:07:05 2010
From: report at bugs.python.org (Michael Curran)
Date: Thu, 10 Jun 2010 07:07:05 +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: <1276153625.75.0.0673476246923.issue8959@psf.upfronthosting.co.za>


Changes by Michael Curran <mick at nvaccess.org>:


Added file: http://bugs.python.org/file17605/test_keyHook.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8959>
_______________________________________

From report at bugs.python.org  Thu Jun 10 09:10:25 2010
From: report at bugs.python.org (Michael Curran)
Date: Thu, 10 Jun 2010 07:10:25 +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: <1276153825.8.0.807844926795.issue8959@psf.upfronthosting.co.za>


Michael Curran <mick at nvaccess.org> added the comment:

I should also note that this has been tested on Windows 7 and XP (32 bit).
I have also seen cases where Python has crashed completely, rather than just causing a WindowsError, in these circomstances.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8959>
_______________________________________

From report at bugs.python.org  Thu Jun 10 11:36:19 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 10 Jun 2010 09:36:19 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1276162579.28.0.0773243129484.issue8828@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Does it work with FAT32 or network filesystem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Thu Jun 10 11:43:47 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 10 Jun 2010 09:43:47 +0000
Subject: [issue8839] PyArg_ParseTuple(): remove "t# format
In-Reply-To: <1276038123.97.0.00682322523581.issue8839@psf.upfronthosting.co.za>
Message-ID: <4C10B3CF.7000607@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:
> 
>> t# was meant to provide access to text data, so replacing it with a
>> parser code that is meant for binary data is not correct. The
>> closes Python3 gets to t# from Python2 is s# or s*, so please use
>> those in the NEWS entry and s* in charbuffer_encode().
> 
> Done. Patch commited as r81854 in 3.2: it removes also codecs.charbuffer_encode(). Commit blocked in 3.1 (r81855).

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8839>
_______________________________________

From report at bugs.python.org  Thu Jun 10 11:55:00 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 10 Jun 2010 09:55:00 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1276020578.25.0.642954542569.issue7989@psf.upfronthosting.co.za>
Message-ID: <4C10B66F.4060203@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Brett Cannon wrote:
> 
> Brett Cannon <brett at python.org> added the comment:
> 
> So yes, cPickle/pickle, cStringIO/StringIO, heapq, etc. are all examples of the approach. One could choose to write the pure Python version first, profile the code, and only write extension code for the hot spots, but obviously that typically doesn't happen.

That's what was done for the datetime module. The pure-Python version
just never made it into the stdlib, AFAIK.

Note that we've just dropped the pure-Python version of the io package
as well, so an approach where we keep the pure-Python prototype
would be a novelty in Python land and should probably be codified
in a PEP.

> As for who maintains it, that's python-dev, just like every other module that is structured like this. When the stdlib gets more of a clear separation from CPython I suspect the other VM maintainers will contribute more.

I'm not sure whether there would be much interest in this. Unless
the core devs are also active in other VM implementations, there's
little motivation to maintain two separate implementations of the
same thing.

Users of CPython will likely only use the C version anyway, so the
pure-Python code would also get little real-life testing.

Perhaps we should open up python-dev to external VM developers
that would have to rely on those pure-Python implementations ?!

> As for PyPy not specifically needing this, that still doesn't solve the problem that Jython and IronPython have with extension code or any other future VM that doesn't try to come up with a solution for extensions.

Both Jython and IronPython could add bridges to CPython extensions
(Jython via the JNI and IronPython via unmanaged code.

Still, you're right in that it's unlikely they will move away from
being pure-Java or pure-C# implementations, so they do have a need
for such pure-Python implementations.

----------
title: Add pure Python implementation of datetime module to CPython -> Add pure Python implementation of datetime module to	CPython

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 10 12:35:02 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 10 Jun 2010 10:35:02 +0000
Subject: [issue8922] Improve encoding shortcuts in PyUnicode_AsEncodedString()
In-Reply-To: <1275949981.66.0.571681325081.issue8922@psf.upfronthosting.co.za>
Message-ID: <4C10BFD2.5000702@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:
> 
>> Note that these shortcut bypass the codec registry logic.
> 
> Yes, but it's already the case without my patch. I don't think that it's really useful to override latin1, utf-8, utf-16, utf-32 or mbcs. I prefer a faster Python :-) 

Depends on your use case. E.g. utf-32 is hardly ever used in practice,
utf-16 is only common on Windows and then only as utf-16-le,
I'm not sure about mbcs since that's a meta-codec. In reality, this
will likely be the same as cp1252 most of the time.

I'm ok on ascii, latin1, utf-8 and mbcs (including the additional
normalization, aliasiing and case mapping), but not on the others.

>> we have to be careful about adding more such shortcuts.
> 
> I just want to add a shortcut for ISO-8859-1.

Fine, even though that name is really not used much in Python code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8922>
_______________________________________

From report at bugs.python.org  Thu Jun 10 12:48:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jun 2010 10:48:51 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276166931.63.0.284106214297.issue7989@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I like the idea of a pure Python implementation of the datetime module, for different reasons:
 - it will become the reference implementation
 - other Python interpreters can use it
 - it can be used to test another implementation, eg. the current C version
 - implement/test a new feature is much faster in Python than in C

About the last point: I already used _pyio many times to fix a bug or to develop a new feature. _pyio helps to choice the right solution because you can easily write a short patch and so compare different solutions.

If other Python interpreters have already their Python implementation, we can just choose the best one, and patch it to add last new features of the C version.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 10 13:03:04 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 10 Jun 2010 11:03:04 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1276166931.63.0.284106214297.issue7989@psf.upfronthosting.co.za>
Message-ID: <4C10C665.6050005@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 like the idea of a pure Python implementation of the datetime module, for different reasons:
>  - it will become the reference implementation
>  - other Python interpreters can use it
>  - it can be used to test another implementation, eg. the current C version
>  - implement/test a new feature is much faster in Python than in C
> 
> About the last point: I already used _pyio many times to fix a bug or to develop a new feature. _pyio helps to choice the right solution because you can easily write a short patch and so compare different solutions.

Ah, so that where the Python io module hides. Thanks for the pointer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 10 13:47:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jun 2010 11:47:40 +0000
Subject: [issue8784] tarfile/Windows: Don't use mbcs as the default encoding
In-Reply-To: <1274491335.43.0.732437213128.issue8784@psf.upfronthosting.co.za>
Message-ID: <1276170460.83.0.595396051352.issue8784@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I created a tarball (.tar.gz) on Windows with Python 3.1 (which uses "mbcs" encoding). With locale.getpreferredencoding() == 'cp1252', "?" (U+00e9) is encoded 0xe9 (1 byte) and "?" (U+00e0) as 0xe0 (1 byte). WinRAR displays correctly the file names, but 7-zip displays the wrong glyphs.

So WinRAR expects CP1252 whereas 7-zip expects CP850.

I also tested an archive encoded with UTF-8: WinRAR and 7-zip display the wrong glyph, they decode utf-8 with CP1252 / CP850 :-/

If an archive will be used on UNIX, I think that the archive should use UTF-8 (on Windows and UNIX). But if the archive is read on Windows with WinRAR or 7-zip, the archive should use a codepage.

Since mbcs looks to be the least worst choice, it may be used but with "replace" error handler (because it doesn't support "surrogateescape" error handler).

--

About the code pages:

 - chcp command displays "Active code page: 850"
 - python -c "import locale; print(locale.getpreferredencoding())" displays "cp1252"
 - python -c "import sys; print(sys.stdout.encoding)" displays "cp850"

Python calls GetConsoleOutputCP() to get stdout/stderr encoding (code page), whereas locale.getpreferredencoding() (_locale.getdefaultencoding()) calls GetACP().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8784>
_______________________________________

From report at bugs.python.org  Thu Jun 10 14:02:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jun 2010 12:02:34 +0000
Subject: [issue8922] Improve encoding shortcuts in PyUnicode_AsEncodedString()
In-Reply-To: <1275848637.97.0.606582513318.issue8922@psf.upfronthosting.co.za>
Message-ID: <1276171354.44.0.72252059036.issue8922@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited in 3.2 (r81869), blocked in 3.1 (r81870).

--

Oops, I don't know why I wrote utf-16 and utf-32. I don't want to add them to the shortcuts.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8922>
_______________________________________

From report at bugs.python.org  Thu Jun 10 14:02:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 10 Jun 2010 12:02:43 +0000
Subject: [issue8885] markerbase declaration errors aren't recoverable
In-Reply-To: <1275563651.6.0.351540013915.issue8885@psf.upfronthosting.co.za>
Message-ID: <1276171363.23.0.690735213428.issue8885@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

"This module is used as a foundation for the HTMLParser and sgmllib
modules (indirectly, for htmllib as well).  It has no documented
public API and should not be used directly."

So, #2 is not relevant unless you are talking about a docstring update or comment in ParserBase.

Do you have a test case using one of the consumer modules that demonstrates a bug?  markupbase has no test suite of its own (which probably should be fixed someday :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8885>
_______________________________________

From report at bugs.python.org  Thu Jun 10 14:04:37 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 10 Jun 2010 12:04:37 +0000
Subject: [issue8924] Error in error message in logging
In-Reply-To: <1275850912.41.0.0811394159532.issue8924@psf.upfronthosting.co.za>
Message-ID: <1276171477.83.0.629518539239.issue8924@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> vinay.sajip
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8924>
_______________________________________

From report at bugs.python.org  Thu Jun 10 14:49:33 2010
From: report at bugs.python.org (=?utf-8?q?Vojt=C4=9Bch_Rylko?=)
Date: Thu, 10 Jun 2010 12:49:33 +0000
Subject: [issue8960] 2.6 README
In-Reply-To: <1276174173.81.0.364137552022.issue8960@psf.upfronthosting.co.za>
Message-ID: <1276174173.81.0.364137552022.issue8960@psf.upfronthosting.co.za>


New submission from Vojt?ch Rylko <vojta.rylko at seznam.cz>:

In 2.6 README are this paragraphs from 2.5 README:

A number of features are not supported in Python 2.5 anymore. Some
support code is still present, but will be removed in Python 2.6. 

The following systems are still supported in Python 2.5, but
support will be dropped in 2.6:
- Systems using --with-wctype-functions
- Win9x, WinME

Following Microsoft's closing of Extended Support for
Windows 98/ME (July 11, 2006), Python 2.6 will stop
supporting these platforms.

----------
assignee: docs at python
components: Documentation
messages: 107458
nosy: docs at python, vojta.rylko
priority: normal
severity: normal
status: open
title: 2.6 README
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8960>
_______________________________________

From report at bugs.python.org  Thu Jun 10 15:48:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jun 2010 13:48:35 +0000
Subject: [issue8922] Improve encoding shortcuts in PyUnicode_AsEncodedString()
In-Reply-To: <1276171354.44.0.72252059036.issue8922@psf.upfronthosting.co.za>
Message-ID: <201006101548.13860.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le jeudi 10 juin 2010 14:02:34, vous avez ?crit :
> Commited in 3.2 (r81869), blocked in 3.1 (r81870).

This commit introduced a regression: ISO-8859-15 was seen as an alias to 
ISO-8859-1 because the normalized string was truncated. Fixed in r81871 
(blocked in 3.1: r81872).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8922>
_______________________________________

From report at bugs.python.org  Thu Jun 10 15:57:36 2010
From: report at bugs.python.org (=?utf-8?b?VGFtw6FzIEd1bMOhY3Np?=)
Date: Thu, 10 Jun 2010 13:57:36 +0000
Subject: [issue8961] compile Python-2.7rc1 on AIX 5.3 with xlc_r
In-Reply-To: <1276178256.7.0.316939316511.issue8961@psf.upfronthosting.co.za>
Message-ID: <1276178256.7.0.316939316511.issue8961@psf.upfronthosting.co.za>


New submission from Tam?s Gul?csi <gt-dev at gthomas.homelinux.org>:

I'm trying to compile Python2.7rc1 on AIX 5.3 with the following call:
FW=/home/kobe/kobed/tgulacsi/freeware
CC='xlc_r -q64' CXX='xlC_r -q64' AR='ar -X64' NM='nm -X64' LD='ld -X64' \
LD_LIBRARY_PATH=$FW/lib:$LD_LIBRARY_PATH \
  ./configure -C --without-gcc \
  CFLAGS="-DHAVE_BROKEN_POSIX_SEMAPHORES -I$FW/include" \
  LDFLAGS='-L$FW/lib' \
  ARFLAGS='cru' \
  --prefix=$FW

make

The result is attached, as I see sysconfig.get_config_var doesn't have CONFIG_ARGS set.

Thanks in advance,
Tam?s Gul?csi

----------
components: Build
files: python-2.7rc1-aix5.3.log
messages: 107460
nosy: tgulacsi
priority: normal
severity: normal
status: open
title: compile Python-2.7rc1 on AIX 5.3 with xlc_r
versions: Python 2.7
Added file: http://bugs.python.org/file17606/python-2.7rc1-aix5.3.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8961>
_______________________________________

From report at bugs.python.org  Thu Jun 10 16:38:36 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 10 Jun 2010 14:38:36 +0000
Subject: [issue8961] compile Python-2.7rc1 on AIX 5.3 with xlc_r
In-Reply-To: <1276178256.7.0.316939316511.issue8961@psf.upfronthosting.co.za>
Message-ID: <1276180716.42.0.302090097612.issue8961@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8961>
_______________________________________

From report at bugs.python.org  Thu Jun 10 17:13:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Jun 2010 15:13:15 +0000
Subject: [issue8961] compile Python-2.7rc1 on AIX 5.3 with xlc_r
In-Reply-To: <1276178256.7.0.316939316511.issue8961@psf.upfronthosting.co.za>
Message-ID: <1276182795.57.0.326525500824.issue8961@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> tarek
nosy: +tarek
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8961>
_______________________________________

From report at bugs.python.org  Thu Jun 10 18:05:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 10 Jun 2010 16:05:47 +0000
Subject: [issue8950] In getargs.c,
	make 'L' code raise TypeError for float arguments.
In-Reply-To: <1276033368.49.0.876712618605.issue8950@psf.upfronthosting.co.za>
Message-ID: <1276185947.16.0.656011623951.issue8950@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Committed, r81873.  Thanks for reviewing, Victor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8950>
_______________________________________

From report at bugs.python.org  Thu Jun 10 18:17:44 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 10 Jun 2010 16:17:44 +0000
Subject: [issue8939] Use C type names (PyUnicode etc;) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276186664.11.0.278787056251.issue8939@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

FWIW, I prefer PyLongObject* over PyLong.  (Though I'm sure I'm guilty of writing PyLong in comments.)

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8939>
_______________________________________

From report at bugs.python.org  Thu Jun 10 18:21:05 2010
From: report at bugs.python.org (Caitlin Kavanaugh)
Date: Thu, 10 Jun 2010 16:21:05 +0000
Subject: [issue8962] IOError: [Errno 13] permission denied
In-Reply-To: <1276186865.91.0.457294354342.issue8962@psf.upfronthosting.co.za>
Message-ID: <1276186865.91.0.457294354342.issue8962@psf.upfronthosting.co.za>


New submission from Caitlin Kavanaugh <cnkavanaugh at gmail.com>:

Hi, I'm new to python, so I'm sorry if my explanation is terribly concise, I'm trying to explain it with fairly limited terminology.

I have been attempting to write data out to a file, yet I continually receive the error:

IOError: [Errno 13] permission denied '/trained.nn'

No matter where or what I try to save the file as, it returns this error with the corresponding file name. My friend insists that I need to use a slash, yet I'm not sure this is the correct syntax. Otherwise, I'm absolutely lost in how to solve this.

I tried looking up possible solutions first, but either the terminology was beyond me, or they supplied a piece of code that could fix it. I don't really want a plug and chug solution. I really want to understand this, so any explanation would be greatly appreciated.

Thank you!

----------
components: Windows
messages: 107463
nosy: Caitlin.Kavanaugh
priority: normal
severity: normal
status: open
title: IOError: [Errno 13] permission denied
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8962>
_______________________________________

From report at bugs.python.org  Thu Jun 10 18:29:05 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 10 Jun 2010 16:29:05 +0000
Subject: [issue8948] cleanup functions are not executed with
	unittest.TestCase.debug()
In-Reply-To: <1276030525.65.0.633421030518.issue8948@psf.upfronthosting.co.za>
Message-ID: <1276187345.34.0.808731352112.issue8948@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 81875.
Committed revision 81874.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8948>
_______________________________________

From report at bugs.python.org  Thu Jun 10 18:33:42 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 10 Jun 2010 16:33:42 +0000
Subject: [issue8962] IOError: [Errno 13] permission denied
In-Reply-To: <1276186865.91.0.457294354342.issue8962@psf.upfronthosting.co.za>
Message-ID: <1276187622.03.0.118166564335.issue8962@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hi,

Sorry, but this tracker is for reporting bugs in Python itself, not for getting help with using Python.  You might try asking on one of the python mailing lists:

http://mail.python.org/mailman/listinfo/python-list

or

http://mail.python.org/mailman/listinfo/tutor

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8962>
_______________________________________

From report at bugs.python.org  Thu Jun 10 19:19:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jun 2010 17:19:04 +0000
Subject: [issue8784] tarfile/Windows: Don't use mbcs as the default encoding
In-Reply-To: <1274491335.43.0.732437213128.issue8784@psf.upfronthosting.co.za>
Message-ID: <1276190344.13.0.674254471941.issue8784@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

My tests with 7-zip and WinRAR conviced me that it's not a good idea to use utf-8 *by default* on Windows. But since mbcs doesn't support surrogateescape error handler, we should restore the previous behaviour just for this encoding.

tarfile_mbcs_errors.patch creates a function choose_errors() which determine the best error handler depending on the encoding and the mode (read or write):
 - "strict" to write with mbcs
 - "replace" to read with mbcs
 - "surrogateescape" otherwise

Please, review my changes on the documentation :-)

On Windows, patched tarfile works exactly as Python 3.1.

----------
Added file: http://bugs.python.org/file17607/tarfile_mbcs_errors.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8784>
_______________________________________

From report at bugs.python.org  Thu Jun 10 19:27:26 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 10 Jun 2010 17:27:26 +0000
Subject: [issue8784] tarfile/Windows: Don't use mbcs as the default encoding
In-Reply-To: <1276190344.13.0.674254471941.issue8784@psf.upfronthosting.co.za>
Message-ID: <4C11207A.2060102@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:
> 
> My tests with 7-zip and WinRAR conviced me that it's not a good idea to use utf-8 *by default* on Windows. But since mbcs doesn't support surrogateescape error handler, we should restore the previous behaviour just for this encoding.
> 
> tarfile_mbcs_errors.patch creates a function choose_errors() which determine the best error handler depending on the encoding and the mode (read or write):
>  - "strict" to write with mbcs
>  - "replace" to read with mbcs
>  - "surrogateescape" otherwise

I think you should implement this in a more general way:
have the class test whether the codec supports "surrogateescape"
and then use it. Otherwise fall back to "strict" for writing
and "replace" for reading.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8784>
_______________________________________

From report at bugs.python.org  Thu Jun 10 20:40:58 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 10 Jun 2010 18:40:58 +0000
Subject: [issue8784] tarfile/Windows: Don't use mbcs as the default encoding
In-Reply-To: <4C101F12.7090102@egenix.com>
Message-ID: <4C1131B6.6080208@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> 7-zip encodes "?" (U+00e0) as 0x85 (1 byte), and "?" (U+00e9) as 0x82 (1 byte). I don't know this encoding.
>
> That's an old DOS code paged used in Europe: CP850

There is a good chance that they use it because it is the OEM code page 
on the system.

In any case, I think that both cp850 and cp1252 are inherently incorrect 
for tarfiles (despite these tools using them). tar is a POSIX thing, and 
these encodings have nothing to do with POSIX.

So using UTF-8 is a reasonable choice, IMO. The other reasonable choice 
would be ASCII.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8784>
_______________________________________

From report at bugs.python.org  Thu Jun 10 20:52:01 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 10 Jun 2010 18:52:01 +0000
Subject: [issue8784] tarfile/Windows: Don't use mbcs as the default encoding
In-Reply-To: <1274491335.43.0.732437213128.issue8784@psf.upfronthosting.co.za>
Message-ID: <1276195921.05.0.32250589087.issue8784@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Maybe I'm going out on a limb here, but I think we should again consider what tarfile users on Windows(!) actually use it for under which circumstances. The following list is probably not exhaustive, but IMHO covers 90%:

1. Download tar archives from a webpage (when no zip is supplied) for viewing or extracting.
2. Create backups for personal use.
3. Create source archives from a project for unix users who hate zipfiles.

I am convinced that the tarfile module is not very popular on Windows, because of a simple reason: tar archives are not. Windows users will always prefer zip archives and hence the zipfile module, because it's something they're familiar with.

The point I am trying to make is, that, first, we should not choose a default encoding based on what works best with WinRAR, 7-zip and such, because they all act very differently which makes it impossible. Second, we must not overemphasize the encoding issue to a point where portability is in danger. This means that in almost all real-life cases there are no encoding issues. In my whole tarfile maintaining career I cannot remember a single incident of a tar archive that I got from an external source that contained special characters. The only tar archives that contain special characters in my experience are backups. But: these backups are created and later restored on one and the same system. Again, no encoding issues.

Long story short, I still vote for utf-8, because it enables Windows users to create backups without losing special characters, and it's ASCII-"compatible" and should be able to read 99% of the files that you get from the internet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8784>
_______________________________________

From report at bugs.python.org  Thu Jun 10 21:02:01 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 10 Jun 2010 19:02:01 +0000
Subject: [issue8950] In getargs.c,
	make 'L' code raise TypeError for float arguments.
In-Reply-To: <1276033368.49.0.876712618605.issue8950@psf.upfronthosting.co.za>
Message-ID: <1276196521.78.0.298438823885.issue8950@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8950>
_______________________________________

From report at bugs.python.org  Thu Jun 10 21:07:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Jun 2010 19:07:19 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This test failure just happened to me on a py3k checkout:

test test_urllibnet failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/debug/Lib/test/test_urllibnet.py", line 191, in test_data_header
    time.strptime(datevalue, dateformat)
  File "/home/antoine/py3k/debug/Lib/_strptime.py", line 461, in _strptime_time
    return _strptime(data_string, format)[0]
  File "/home/antoine/py3k/debug/Lib/_strptime.py", line 332, in _strptime
    (data_string, format))
ValueError: time data 'Thu, 10 Jun 2010 19:03:39 GMT' does not match format '%a, %d %b %Y %H:%M:%S GMT'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/debug/Lib/test/test_urllibnet.py", line 193, in test_data_header
    self.fail('Date value not in %r format', dateformat)
TypeError: fail() takes at most 2 arguments (3 given)

----------
assignee: orsenthil
components: Library (Lib), Tests
messages: 107470
nosy: belopolsky, orsenthil, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_urllibnet failure
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Thu Jun 10 21:30:02 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 10 Jun 2010 19:30:02 +0000
Subject: [issue8924] Error in error message in logging
In-Reply-To: <1275850912.41.0.0811394159532.issue8924@psf.upfronthosting.co.za>
Message-ID: <1276198202.43.0.125475109141.issue8924@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

It seems like the logging message will be Unicode (as you have specified that it should be so) but the exception message will be string. Can you confirm whether this is the case? What type is the return value of Formatter.formatException for the specific exception you're getting, in your exact environment?

If it's not Unicode, can you see what happens if you use a subclassed Formatter whose formatException decodes the returned value from the base class formatException with the appropriate encoding, and return Unicode from your overridden formatException message?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8924>
_______________________________________

From report at bugs.python.org  Thu Jun 10 21:39:58 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Jun 2010 19:39:58 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276198798.69.0.838648499931.issue8963@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

How do I enable `network' resource?

I am getting

$ ./python.exe -m test.regrtest test_urllibnet
test_urllibnet
test_urllibnet skipped -- Use of the `network' resource not enabled
1 test skipped:
    test_urllibnet
Those skips are all expected on darwin.


Same on Linux ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Thu Jun 10 21:45:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Jun 2010 19:45:46 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276198798.69.0.838648499931.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276199141.3139.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> How do I enable `network' resource?

Use the "-unetwork" flag to regrtest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Thu Jun 10 21:48:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Jun 2010 19:48:03 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276199283.95.0.0209037245511.issue8963@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

$ ./python.exe -m test.regrtest -unetwork test_urllibnet
test_urllibnet
1 test OK.

Also the arguments to strptime from reported error message work fine:

>>> import time
>>> time.strptime('Thu, 10 Jun 2010 19:03:39 GMT', '%a, %d %b %Y %H:%M:%S GMT')
time.struct_time(tm_year=2010, tm_mon=6, tm_mday=10, tm_hour=19, tm_min=3, tm_sec=39, tm_wday=3, tm_yday=161, tm_isdst=-1)
>>> from datetime import *
>>> datetime.strptime('Thu, 10 Jun 2010 19:03:39 GMT', '%a, %d %b %Y %H:%M:%S GMT')
datetime.datetime(2010, 6, 10, 19, 3, 39)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Thu Jun 10 21:48:54 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Jun 2010 19:48:54 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276199334.98.0.0344997699436.issue8963@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

What is your locale?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Thu Jun 10 21:51:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Jun 2010 19:51:28 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276199334.98.0.0344997699436.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276199484.3139.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> What is your locale?

$ locale
LANG=fr_FR.utf8
LC_CTYPE="fr_FR.utf8"
LC_NUMERIC="fr_FR.utf8"
LC_TIME="fr_FR.utf8"
LC_COLLATE="fr_FR.utf8"
LC_MONETARY="fr_FR.utf8"
LC_MESSAGES="fr_FR.utf8"
LC_PAPER="fr_FR.utf8"
LC_NAME="fr_FR.utf8"
LC_ADDRESS="fr_FR.utf8"
LC_TELEPHONE="fr_FR.utf8"
LC_MEASUREMENT="fr_FR.utf8"
LC_IDENTIFICATION="fr_FR.utf8"
LC_ALL=

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Thu Jun 10 22:02:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Jun 2010 20:02:09 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276200129.98.0.272835458624.issue8963@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Strangely, it also works here from the prompt:

>>> import time
>>> time.strptime('Thu, 10 Jun 2010 19:03:39 GMT', '%a, %d %b %Y %H:%M:%S GMT')
time.struct_time(tm_year=2010, tm_mon=6, tm_mday=10, tm_hour=19, tm_min=3, tm_sec=39, tm_wday=3, tm_yday=161, tm_isdst=-1)
>>> import locale
>>> locale.getlocale(locale.LC_TIME)
(None, None)

Apparently, something sets the locale before running the test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Thu Jun 10 22:02:24 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Jun 2010 20:02:24 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276200144.91.0.125399459828.issue8963@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I still cannot reproduce the failure, but please, try the attached patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file17608/issue8963.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Thu Jun 10 22:06:14 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 10 Jun 2010 20:06:14 +0000
Subject: [issue8958] 2.7rc1 tarfile.py: `bltn_open(targetpath,
	"wb")` -> IOError: Is a directory
In-Reply-To: <1276118455.66.0.211402542637.issue8958@psf.upfronthosting.co.za>
Message-ID: <1276200374.61.0.736003480634.issue8958@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Unfortunately I do not have access to an OS X machine. Is this problem specific to 2.7rc1 or are other versions affected as well? I thought the OS X filesystem was case sensitive ...

----------
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8958>
_______________________________________

From report at bugs.python.org  Thu Jun 10 22:06:32 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 10 Jun 2010 20:06:32 +0000
Subject: [issue8958] 2.7rc1 tarfile.py: `bltn_open(targetpath,
	"wb")` -> IOError: Is a directory
In-Reply-To: <1276118455.66.0.211402542637.issue8958@psf.upfronthosting.co.za>
Message-ID: <1276200392.42.0.670982774168.issue8958@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
assignee:  -> lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8958>
_______________________________________

From report at bugs.python.org  Thu Jun 10 22:13:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Jun 2010 20:13:53 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276200833.94.0.372591710664.issue8963@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The culprit seems to be test_bad_address. If I disable this test, or replace the bad URL by a good one, everything works fine. It seems that failing to resolve the domain name changes the current locale...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Thu Jun 10 22:20:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Jun 2010 20:20:21 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276201221.36.0.622994994986.issue8963@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch is not sufficient, since other failures can then occur if test_strptime gets run after test_urllibnet:

======================================================================
ERROR: test_twelve_noon_midnight (test.test_strptime.Strptime12AMPMTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/debug/Lib/test/test_strptime.py", line 389, in test_twelve_noon_midnight
    eq(time.strptime('12 PM', '%I %p')[3], 12)
  File "/home/antoine/py3k/debug/Lib/_strptime.py", line 461, in _strptime_time
    return _strptime(data_string, format)[0]
  File "/home/antoine/py3k/debug/Lib/_strptime.py", line 335, in _strptime
    data_string[found.end():])
ValueError: unconverted data remains: PM

======================================================================
FAIL: test_pattern (test.test_strptime.TimeRETests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/debug/Lib/test/test_strptime.py", line 124, in test_pattern
    pattern_string)
AssertionError: did not find abbreviated weekday in pattern string '(?P<a>lun\.|mar\.|mer\.|jeu\.|ven\.|sam\.|dim\.)\s+(?P<A>mercredi|vendredi|dimanche|samedi|lundi|mardi|jeudi)\s+(?P<d>3[0-1]|[1-2]\d|0[1-9]|[1-9]| [1-9])'

======================================================================
FAIL: test_hour (test.test_strptime.StrptimeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/debug/Lib/test/test_strptime.py", line 266, in test_hour
    (strf_output, strp_output[3], self.time_tuple[3]))
AssertionError: testing of '%I %p' directive failed; '08 ' -> 8 != 20

----------------------------------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Thu Jun 10 22:22:28 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Jun 2010 20:22:28 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276201348.99.0.921364377528.issue8963@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

BTW, looking at test_bad_address(), I wonder why it puts extra dots in the url?  The comment above it suggests that the intent is to use a name within RFC 2606 .invalid TLD.  Not likely to be a problem in your case, but using made up TLD is not a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Thu Jun 10 22:25:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Jun 2010 20:25:16 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276201516.24.0.834234994767.issue8963@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> The patch is not sufficient, since other
> failures can then occur if test_strptime gets
> run after test_urllibnet

This looks like a bug in support.run_with_locale decorator.  

It is described as
#=======================================================================                                                                                                                                     
# Decorator for running a function in a different locale, correctly resetting                                                                                                                                
# it afterwards.

but apparently does not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Thu Jun 10 22:27:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Jun 2010 20:27:50 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276201670.09.0.903361171134.issue8963@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, so what it boils down to is the following behaviour:

>>> import locale, socket
>>> sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> locale.getlocale(locale.LC_TIME)
(None, None)
>>> sock.connect(("invalidhost", 80))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.gaierror: [Errno -2] Nom ou service inconnu
>>> locale.getlocale(locale.LC_TIME)
('fr_FR', 'UTF8')

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Thu Jun 10 22:28:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Jun 2010 20:28:13 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276201693.84.0.890540132529.issue8963@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Thu Jun 10 22:44:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Jun 2010 20:44:12 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276202652.21.0.90181455378.issue8963@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

In setipaddr() in socketmodule.c, the following line appears to change the current locale when DNS lookup fails:

    error = getaddrinfo(name, NULL, &hints, &res);

This is checked by making a call to setlocale(LC_TIME, NULL) before and after the aforementioned line.

This is with the following libc:
$ rpm -qv glibc
glibc-2.11.1-8mnb2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Thu Jun 10 23:10:36 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 10 Jun 2010 21:10:36 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276204236.25.0.83983441506.issue8963@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This looks like a glibc bug to me. I suspect an unauthorized redhat change; I hope Ulrich Drepper would have never accepted a glibc that causes getaddrinfo to implicitly call setlocale - see

http://sources.redhat.com/ml/libc-alpha/2004-03/msg00161.html

You might experiment with disabling IDN support in getaddrinfo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Thu Jun 10 23:11:35 2010
From: report at bugs.python.org (Frederic Torres)
Date: Thu, 10 Jun 2010 21:11:35 +0000
Subject: [issue8964] Method _sys_version() module Lib\platform.py does parse
	correctly IronPython 2.x version
In-Reply-To: <1276204295.1.0.731236969654.issue8964@psf.upfronthosting.co.za>
Message-ID: <1276204295.1.0.731236969654.issue8964@psf.upfronthosting.co.za>


New submission from Frederic Torres <fredericaltorres at gmail.com>:

Method _sys_version() module Lib\platform.py does parse correctly IronPython 2.x version

The format of sys.version now start with a version number and (
2.6.1 (IronPython 2.6.1 (2.6.10920.0) on .NET 4.0.30319.1)

File:     Lib\platform.py
Function: def _sys_version(sys_version=None):
Line:     1326

----------
components: Library (Lib)
messages: 107487
nosy: fredericaltorres, lemburg
priority: normal
severity: normal
status: open
title: Method _sys_version() module Lib\platform.py does parse correctly IronPython 2.x version
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8964>
_______________________________________

From report at bugs.python.org  Thu Jun 10 23:14:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jun 2010 21:14:11 +0000
Subject: [issue8784] tarfile/Windows: Don't use mbcs as the default encoding
In-Reply-To: <1274491335.43.0.732437213128.issue8784@psf.upfronthosting.co.za>
Message-ID: <1276204451.08.0.740302215732.issue8784@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> 2. Create backups for personal use.

What? Really? I'm sure that all Windows users will use ZIP or maybe RAR, but never the geek choice.

> 1. Download tar archives from a webpage (when no zip is supplied) for viewing or extracting.

Tarballs come from UNIX/BSD world which use UTF-8 by default since some years ago.

> 3. Create source archives from a project for unix users who hate zipfiles.

In this case, UTF-8 is also better.

--

Did I mentionned that 7-zip is only able to create TAR archive? I mean uncompressed archive. Who will use that? (not me ;-))

WinRAR is unable to create tarballs, even (uncompressed) .tar archive.

--

If the maintainer of the tarfile module agrees that UTF-8 is the best choice, I will commit my initial patch. I would prefer to commit tarfile_windows_utf8.patch because it changes 4 lines, whereas tarfile_mbcs_errors.patch changes... much more code :-)

tarfile_windows_utf8.patch is not complete: the documentation should also be updated:

.. data:: ENCODING

   The default character encoding i.e. the value from either
   :func:`sys.getfilesystemencoding` or :func:`sys.getdefaultencoding`.

=>

.. data:: ENCODING

   The default character encoding: ``'utf-8'`` on Windows,
   :func:`sys.getfilesystemencoding` otherwise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8784>
_______________________________________

From report at bugs.python.org  Thu Jun 10 23:15:26 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 10 Jun 2010 21:15:26 +0000
Subject: [issue8964] Method _sys_version() module Lib\platform.py does
	parse	correctly IronPython 2.x version
In-Reply-To: <1276204295.1.0.731236969654.issue8964@psf.upfronthosting.co.za>
Message-ID: <4C1155EA.809@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Frederic Torres wrote:
> 
> New submission from Frederic Torres <fredericaltorres at gmail.com>:
> 
> Method _sys_version() module Lib\platform.py does parse correctly IronPython 2.x version
> 
> The format of sys.version now start with a version number and (
> 2.6.1 (IronPython 2.6.1 (2.6.10920.0) on .NET 4.0.30319.1)
> 
> File:     Lib\platform.py
> Function: def _sys_version(sys_version=None):
> Line:     1326

I assume you meant: doesn't correctly parse the version number.

Could you provide a complete example formatted as Python string,
e.g. print repr(sys.version) ?!

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________
2010-07-19: EuroPython 2010, Birmingham, UK                38 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------
title: Method _sys_version() module Lib\platform.py does parse correctly IronPython 2.x version -> Method _sys_version() module Lib\platform.py does parse	correctly IronPython 2.x version

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8964>
_______________________________________

From report at bugs.python.org  Thu Jun 10 23:17:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Jun 2010 21:17:28 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276204648.96.0.43670779817.issue8963@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've reported the bug upstream at Mandriva:
https://qa.mandriva.com/show_bug.cgi?id=59736

It would be nice to know whether other distributions with a Redhat lineage are affected. Can someone with such a distribution the code in msg107484?

In the end, I'm not sure it's Python's task to workaround such bug.
However, the bug in error reporting should be fixed.

----------
assignee: orsenthil -> 
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Thu Jun 10 23:20:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jun 2010 21:20:39 +0000
Subject: [issue8784] tarfile/Windows: Don't use mbcs as the default encoding
In-Reply-To: <1274491335.43.0.732437213128.issue8784@psf.upfronthosting.co.za>
Message-ID: <1276204839.39.0.615183262485.issue8784@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Updated version of the utf-8 patch:
 - Use also UTF-8 for Windows CE
 - Update the documentation
 - Prepare the NEWS entry

----------
Added file: http://bugs.python.org/file17609/tarfile_windows_utf8-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8784>
_______________________________________

From report at bugs.python.org  Thu Jun 10 23:24:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Jun 2010 21:24:06 +0000
Subject: [issue8784] tarfile/Windows: Don't use mbcs as the default encoding
In-Reply-To: <1274491335.43.0.732437213128.issue8784@psf.upfronthosting.co.za>
Message-ID: <1276205046.82.0.76311087361.issue8784@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

FWIW, I agree with Lars: the main use of tar files under Windows is when they come from other systems. Windows users almost never generate tar files by themselves; they will generate zip, rar or 7z files instead.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8784>
_______________________________________

From report at bugs.python.org  Thu Jun 10 23:29:28 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 10 Jun 2010 21:29:28 +0000
Subject: [issue8958] 2.7rc1 tarfile.py: `bltn_open(targetpath,
	"wb")` -> IOError: Is a directory
In-Reply-To: <1276200374.61.0.736003480634.issue8958@psf.upfronthosting.co.za>
Message-ID: <5F483897-20C8-4065-A15A-061CD6A43F08@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On 2010-06-10, at 1:06 PM, Lars Gust?bel wrote:

> Is this problem specific to 2.7rc1

Yes.

> or are other versions affected as well?

Nope, at least ... I know that 2.6 doesn't have this problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8958>
_______________________________________

From report at bugs.python.org  Thu Jun 10 23:31:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jun 2010 21:31:15 +0000
Subject: [issue8958] 2.7rc1 tarfile.py: `bltn_open(targetpath,
	"wb")` -> IOError: Is a directory
In-Reply-To: <1276118455.66.0.211402542637.issue8958@psf.upfronthosting.co.za>
Message-ID: <1276205475.19.0.712759095775.issue8958@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/issue8958>
_______________________________________

From report at bugs.python.org  Thu Jun 10 23:37:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Jun 2010 21:37:39 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276205859.6.0.103092649585.issue8963@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It looks like your libc calls setlocale(LC_ALL, "") on error.  This may or may not be right and not python's problem in any case.  What is worth to investigate, however is why @run_with_locale decorator fails to restore the locale after it was modified by libc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Thu Jun 10 23:51:51 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 10 Jun 2010 21:51:51 +0000
Subject: [issue8961] compile Python-2.7rc1 on AIX 5.3 with xlc_r
In-Reply-To: <1276178256.7.0.316939316511.issue8961@psf.upfronthosting.co.za>
Message-ID: <1276206711.48.0.338712493081.issue8961@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

FYI, I cannot reproduce this on AIX 5.1:

bash-2.04$ i/bin/python
ActivePython 2.7.0c1.0 (ActiveState Software Inc.) based on
Python 2.7rc1 (r27rc1:81772, Jun  5 2010, 23:20:01) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> sysconfig.get_config_var("CONFIG_ARGS")
"'--prefix=/home/apy/tmp/issue8961/ActivePython-2.7.0c1.0-aix-powerpc64/i' '--without-cxx' '--disable-ipv6' 'CC=xlc_r'"
>>> ^D
bash-2.04$ i/bin/python -m platform
AIX-1-000C763E4C00-powerpc-64bit

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8961>
_______________________________________

From report at bugs.python.org  Fri Jun 11 00:15:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Jun 2010 22:15:23 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276208123.35.0.0941936508735.issue8963@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Antoine,

Would s/LC_TIME/LC_ALL/ in my patch fix your problem?  I could not find an affected system, but I simulated the problem by adding locale.setlocale(locale.LC_ALL, "") call in the test.

I think the patch is worth applying. It fixes the typo in the except clause and makes the test independent of the locale settings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Fri Jun 11 00:24:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Jun 2010 22:24:49 +0000
Subject: [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276208689.25.0.2988011918.issue8963@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Would s/LC_TIME/LC_ALL/ in my patch fix your problem?

As I explained, this wouldn't fix the later failures in test_strptime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8963>
_______________________________________

From report at bugs.python.org  Fri Jun 11 00:39:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Jun 2010 22:39:39 +0000
Subject: [issue8965] test_imp fails on OSX when LANG is set
In-Reply-To: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>
Message-ID: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

$ LANG=C ./python.exe -m test.regrtest test_imp
test_imp
test test_imp failed -- Traceback (most recent call last):
  File "Lib/test/test_imp.py", line 109, in test_issue5604
    self.assertEqual(fs_encoding, 'utf-8')
AssertionError: 'ascii' != 'utf-8'
- ascii+ utf-8

1 test failed:
    test_imp


Same with LC_ALL=C.  Passes on Linux.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 107498
nosy: belopolsky, ronaldoussoren
priority: normal
severity: normal
status: open
title: test_imp fails on OSX when LANG is set
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8965>
_______________________________________

From report at bugs.python.org  Fri Jun 11 01:03:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jun 2010 23:03:27 +0000
Subject: [issue8966] ctypes: remove implicit conversion between unicode and
	bytes
In-Reply-To: <1276211007.74.0.406425558952.issue8966@psf.upfronthosting.co.za>
Message-ID: <1276211007.74.0.406425558952.issue8966@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

ctypes doesn't have strict separation between bytes and characters, whereas Python3 splitted str/unicode of Python2 into bytes/str which a strict separation. The result is that sometimes it works (no error), sometimes it fails (the first time that the user inserts a non-ASCII character).

I wrote 3 patches:
 - ctypes_s_set.patch: fix s_set(), return an unicode string instead of a bytes string
 - ctypes_conversion.patch: remove ctypes.set_conversion_mode() and all code using it (remove the implicit conversions)
 - ctypes_tests.patch: fix all tests according the changes introduced by the two previous patches

ctypes_s_set.patch is trivial and fixes a real bug. ctypes_conversion.patch does basically remove code. ctypes_tests.patch is the biggest part because the test suite is mostly based on the implicit conversion.

Except the parts removing the calls to ctypes.set_conversion_mode() and the tests testing the implicit conversion, ctypes_tests.patch can be commited alone because it improves the test suite (use the right types).

----------
assignee: theller
components: Unicode, ctypes
files: ctypes_conversion.patch
keywords: patch
messages: 107499
nosy: haypo, theller
priority: normal
severity: normal
status: open
title: ctypes: remove implicit conversion between unicode and bytes
versions: Python 3.2
Added file: http://bugs.python.org/file17610/ctypes_conversion.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8966>
_______________________________________

From report at bugs.python.org  Fri Jun 11 01:03:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jun 2010 23:03:41 +0000
Subject: [issue8966] ctypes: remove implicit conversion between unicode and
	bytes
In-Reply-To: <1276211007.74.0.406425558952.issue8966@psf.upfronthosting.co.za>
Message-ID: <1276211021.41.0.490606368919.issue8966@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file17611/ctypes_conversion.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8966>
_______________________________________

From report at bugs.python.org  Fri Jun 11 01:03:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jun 2010 23:03:51 +0000
Subject: [issue8966] ctypes: remove implicit conversion between unicode and
	bytes
In-Reply-To: <1276211007.74.0.406425558952.issue8966@psf.upfronthosting.co.za>
Message-ID: <1276211031.89.0.277007762165.issue8966@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file17612/ctypes_s_set.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8966>
_______________________________________

From report at bugs.python.org  Fri Jun 11 01:03:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jun 2010 23:03:59 +0000
Subject: [issue8966] ctypes: remove implicit conversion between unicode and
	bytes
In-Reply-To: <1276211007.74.0.406425558952.issue8966@psf.upfronthosting.co.za>
Message-ID: <1276211039.89.0.810605598165.issue8966@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file17613/ctypes_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8966>
_______________________________________

From report at bugs.python.org  Fri Jun 11 01:04:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jun 2010 23:04:03 +0000
Subject: [issue8966] ctypes: remove implicit conversion between unicode and
	bytes
In-Reply-To: <1276211007.74.0.406425558952.issue8966@psf.upfronthosting.co.za>
Message-ID: <1276211043.71.0.990157612987.issue8966@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17610/ctypes_conversion.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8966>
_______________________________________

From report at bugs.python.org  Fri Jun 11 01:09:36 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Jun 2010 23:09:36 +0000
Subject: [issue8965] test_imp fails on OSX when LANG is set
In-Reply-To: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>
Message-ID: <1276211376.07.0.508020930228.issue8965@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Is this check needed on darwin?  Why not simply set fs_encoding = 'utf-8'?

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8965>
_______________________________________

From report at bugs.python.org  Fri Jun 11 01:16:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Jun 2010 23:16:42 +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: <1276211802.14.0.286753447801.issue1452@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
type:  -> feature request
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1452>
_______________________________________

From report at bugs.python.org  Fri Jun 11 01:27:40 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 10 Jun 2010 23:27:40 +0000
Subject: [issue8965] test_imp fails on OSX when LANG is set
In-Reply-To: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>
Message-ID: <1276212460.38.0.449959485871.issue8965@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I haven't looked at the actual test yet, but the filesystem encoding on OSX is UTF-8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8965>
_______________________________________

From report at bugs.python.org  Fri Jun 11 01:38:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Jun 2010 23:38:48 +0000
Subject: [issue3453] PyType_Ready doesn't ensure that all bases are ready
In-Reply-To: <1217171645.31.0.486361917431.issue3453@psf.upfronthosting.co.za>
Message-ID: <1276213128.43.0.430857867359.issue3453@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

My knowledge may be out of date, but I thought multiple inheritance was only supported at the python level.  If this is still the case, then no initialization check is needed. (You cannot get an uninitialized type at python level.)  An extra defensive assert is usually not a bad thing in the code, but in this particular case one would need a loop with checks and it does not seem justified.

-1

----------
nosy: +belopolsky
stage:  -> needs patch
type:  -> feature request
versions: +Python 3.2 -Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3453>
_______________________________________

From report at bugs.python.org  Fri Jun 11 01:43:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Jun 2010 23:43:20 +0000
Subject: [issue1516] make _ctypes work with non-gcc compilers
In-Reply-To: <1196297579.57.0.775741892495.issue1516@psf.upfronthosting.co.za>
Message-ID: <1276213400.32.0.0648956561704.issue1516@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
type:  -> feature request
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1516>
_______________________________________

From report at bugs.python.org  Fri Jun 11 01:53:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jun 2010 23:53:05 +0000
Subject: [issue8965] test_imp fails on OSX when LANG is set
In-Reply-To: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>
Message-ID: <1276213985.23.0.467416392837.issue8965@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oooh. That's my fault. I introduced this regression in issue #8610 (commit r81190). Can you try attached patch please?

The file system encoding is hardcoded to 'utf-8' on Mac OS X (it should not depend on the locale).

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file17614/initfsencoding_apple.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8965>
_______________________________________

From report at bugs.python.org  Fri Jun 11 02:01:24 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 00:01:24 +0000
Subject: [issue4113] Add custom __repr__ to functools.partial
In-Reply-To: <1223898315.71.0.950281538816.issue4113@psf.upfronthosting.co.za>
Message-ID: <1276214484.3.0.91208270055.issue4113@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I understand that the latest RFE in this issue is to provide a custom __repr__ to functools.partial.  Something along the lines of

class partial(functools.partial):
    def __repr__(self):
        return "functools.partial(%r, %s)" % (self.func, 
                      ', '.join(repr(a) for a in self.args)


>>> def f(x, y, z):
...   pass
>>> partial(f, 1, 2)
functools.partial(<function f at 0x10065b060>, 1, 2)

Looks like a reasonable proposal, but coding this in C is a chore. (The prototype above does not process keywords, so complete implementation is more involved.)

----------
keywords: +easy -patch
nosy: +belopolsky
stage:  -> needs patch
title: functools.partial(), no __name__; wrong __doc__ -> Add custom __repr__ to functools.partial

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4113>
_______________________________________

From report at bugs.python.org  Fri Jun 11 02:01:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 00:01:30 +0000
Subject: [issue4113] Add custom __repr__ to functools.partial
In-Reply-To: <1223898315.71.0.950281538816.issue4113@psf.upfronthosting.co.za>
Message-ID: <1276214490.36.0.782498549145.issue4113@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4113>
_______________________________________

From report at bugs.python.org  Fri Jun 11 02:09:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 00:09:15 +0000
Subject: [issue8967] Create PyErr_GetWindowsMessage() function
In-Reply-To: <1276214955.6.0.858876193041.issue8967@psf.upfronthosting.co.za>
Message-ID: <1276214955.6.0.858876193041.issue8967@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PyErr_SetExcFromWindowsErrWithFilenameObject() and PyErr_SetFromErrnoWithFilenameObject() have the same code to read the localized error message. The code can be factorized in a new function PyErr_GetWindowsMessage().

About the patch:
 - free s_buf just after the call to PyUnicode_FromUnicode(), don't wait until the end of the function
 - free s_buf if s_buf is not NULL and len==0. I suppose that this case is impossible, if len==0, s_buf is set to NULL or leaved unchanged (so it's also equal to NULL)

I wrote the function to raise an UnicodeDecodeError with a Windows error message.

----------
components: Interpreter Core, Unicode, Windows
files: pyerr_getwindowsmessage.patch
keywords: patch
messages: 107505
nosy: haypo
priority: normal
severity: normal
status: open
title: Create PyErr_GetWindowsMessage() function
versions: Python 3.2
Added file: http://bugs.python.org/file17615/pyerr_getwindowsmessage.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8967>
_______________________________________

From report at bugs.python.org  Fri Jun 11 02:11:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 00:11:03 +0000
Subject: [issue8965] test_imp fails on OSX when LANG is set
In-Reply-To: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>
Message-ID: <1276215063.75.0.328784696326.issue8965@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Victor,

Your patch works for me and makes sense even though I don't really know where Py_FileSystemDefaultEncoding is set on Darwin. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8965>
_______________________________________

From report at bugs.python.org  Fri Jun 11 02:16:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 00:16:26 +0000
Subject: [issue8965] test_imp fails on OSX when LANG is set
In-Reply-To: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>
Message-ID: <1276215386.41.0.164324469891.issue8965@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On the second thought, test_imp is not the right place to test this.  Can you add a sys module test for this issue?

----------
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8965>
_______________________________________

From report at bugs.python.org  Fri Jun 11 02:17:13 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 11 Jun 2010 00:17:13 +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: <1276215433.76.0.151174835837.issue5753@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Demo/embed/demo.c calls PySys_SetArgv(), which may be where
some people are copying their code from.  I've updated it to
use PySys_SetArgvEx() and added an explanatory comment in rev. 81881.

----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Fri Jun 11 02:27:43 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Fri, 11 Jun 2010 00:27:43 +0000
Subject: [issue8968] token type constants are not documented
In-Reply-To: <1276216063.7.0.11813766705.issue8968@psf.upfronthosting.co.za>
Message-ID: <1276216063.7.0.11813766705.issue8968@psf.upfronthosting.co.za>


New submission from Ilya Sandler <ilya.sandler at gmail.com>:

the token module defines constants for token types e.g

 NAME = 1
 NUMBER = 2
 STRING = 3
 NEWLINE = 4

etc.

These constants are very useful for any code which needs to tokenize python source, yet they are not listed in the documentation.


Is this a documentation bug?

----------
assignee: docs at python
components: Documentation
messages: 107509
nosy: docs at python, isandler
priority: normal
severity: normal
status: open
title: token type constants are not documented
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8968>
_______________________________________

From report at bugs.python.org  Fri Jun 11 02:30:22 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 00:30:22 +0000
Subject: [issue1402289] Allow mappings as globals (was: Fix dictionary
	subclass ...)
Message-ID: <1276216222.79.0.741164769612.issue1402289@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage:  -> patch review
type:  -> feature request
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1402289>
_______________________________________

From report at bugs.python.org  Fri Jun 11 02:33:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 00:33:08 +0000
Subject: [issue8969] Windows: use (mbcs in) strict mode to encode/decode
	filenames, and enable os.fsencode()
In-Reply-To: <1276216388.28.0.366593840574.issue8969@psf.upfronthosting.co.za>
Message-ID: <1276216388.28.0.366593840574.issue8969@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

mbcs encoding doesn't support surrogateescape (see #850997), and mbcs should only be used in strict mode to encode/decode filenames.

os.fsencode() should also be enabled on Windows. First I tried to disable this function on Windows to avoid the evil mbcs encoding, but mbcs encoding *is* used by some modules written in C (functions using PyUnicode_FSConverter(): encode the filename to bytes with mbcs encoding on Windows). Eg. _ssl module use PyUnicode_FSConverter() to get filenames because the underlying library, OpenSSL, requires bytes for the filenames (C type: char*). Enable os.fsencode() on Windows helps some tests (eg. fix test_ssl).

Use "strict" error handler, instead of "surrogateescape", to encode/decode filenames with mbcs encoding, does nothing yet because mbcs codec ignore the errors argument. These changes prepare the work on mbcs codec: see #850997.

Note: os.fsencode() was introduced by #8514.

----------
components: Interpreter Core, Library (Lib), Unicode, Windows
files: fsencode_mbcs.patch
keywords: patch
messages: 107510
nosy: haypo
priority: normal
severity: normal
status: open
title: Windows: use (mbcs in) strict mode to encode/decode filenames, and enable os.fsencode()
versions: Python 3.2
Added file: http://bugs.python.org/file17616/fsencode_mbcs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8969>
_______________________________________

From report at bugs.python.org  Fri Jun 11 02:33:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 00:33:51 +0000
Subject: [issue8969] Windows: use (mbcs in) strict mode to encode/decode
	filenames, and enable os.fsencode()
In-Reply-To: <1276216388.28.0.366593840574.issue8969@psf.upfronthosting.co.za>
Message-ID: <1276216431.87.0.928697475347.issue8969@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +lemburg, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8969>
_______________________________________

From report at bugs.python.org  Fri Jun 11 02:43:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 00:43:45 +0000
Subject: [issue8965] test_imp fails on OSX when LANG is set
In-Reply-To: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>
Message-ID: <1276217025.66.0.838420967524.issue8965@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch commited as r81883 (blocked in 3.1: r81884).

> Can you add a sys module test for this issue?

Ok, I added a test to test_sys: r81885 (blocked in 3.1: r81886).

> I don't really know where Py_FileSystemDefaultEncoding 
> is set on Darwin. :-)

In Python/bltinmodule.c.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8965>
_______________________________________

From report at bugs.python.org  Fri Jun 11 02:47:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 00:47:36 +0000
Subject: [issue8965] test_imp fails on OSX when LANG is set
In-Reply-To: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>
Message-ID: <1276217256.28.0.174701719484.issue8965@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Hum. To avoid regression, we should maybe have a test with the C locale. 

@belopolsky: Can you try test_sys.patch on Mac OS X?

----------
Added file: http://bugs.python.org/file17617/test_sys.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8965>
_______________________________________

From report at bugs.python.org  Fri Jun 11 02:54:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 00:54:18 +0000
Subject: [issue850997] mbcs encoding ignores errors
Message-ID: <1276217658.82.0.222857589843.issue850997@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I worked again on the patch. I opened new issues to prepare the new mbcs codec:
 - #8966: ctypes: remove implicit conversion between unicode and bytes
 - #8967: Create PyErr_GetWindowsMessage() function
 - #8969: Windows: use (mbcs in) strict mode to encode/decode filenames, and enable os.fsencode()

#8967 can be used to get the translated message of a mbcs encode error. PyErr_GetWindowsMessage() returns a PyUnicodeObject, whereas make_translate_exception() and PyUnicodeTranslateError_SetReason() expect a "char*". Another patch is requied: translate_reason_unicode.patch (attached to this issue, not tested). But I don't think that the message is very important for now :-)

#8784 (tarfile/Windows: Don't use mbcs as the default encoding) is still open.

----------
Added file: http://bugs.python.org/file17618/translate_reason_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue850997>
_______________________________________

From report at bugs.python.org  Fri Jun 11 03:03:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 01:03:18 +0000
Subject: [issue8965] test_imp fails on OSX when LANG is set
In-Reply-To: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>
Message-ID: <1276218198.84.0.613763592486.issue8965@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Nope.
$ ./python.exe -m test.regrtest test_sys
test test_sys failed -- Traceback (most recent call last):
  File "Lib/test/test_sys.py", line 877, in test_getfilesystemencoding
    self.assertEqual(fs_encoding, 'utf-8')
AssertionError: b'utf-8\n' != 'utf-8'

Should be easy to fix, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8965>
_______________________________________

From report at bugs.python.org  Fri Jun 11 03:08:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 01:08:03 +0000
Subject: [issue8965] test_imp fails on OSX when LANG is set
In-Reply-To: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>
Message-ID: <1276218483.23.0.616879179663.issue8965@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17619/issue8965-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8965>
_______________________________________

From report at bugs.python.org  Fri Jun 11 03:08:27 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 11 Jun 2010 01:08:27 +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: <1276218507.73.0.825822189654.issue5753@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Since the function was also added to 2.6, the 2.6 What's New should mention it; added in rev81887.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Fri Jun 11 03:13:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 01:13:45 +0000
Subject: [issue8965] test_imp fails on OSX when LANG is set
In-Reply-To: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>
Message-ID: <1276218825.02.0.0736501792149.issue8965@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17620/issue8965-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8965>
_______________________________________

From report at bugs.python.org  Fri Jun 11 03:13:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 01:13:55 +0000
Subject: [issue8965] test_imp fails on OSX when LANG is set
In-Reply-To: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>
Message-ID: <1276218835.89.0.146450924629.issue8965@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17619/issue8965-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8965>
_______________________________________

From report at bugs.python.org  Fri Jun 11 03:18:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 01:18:19 +0000
Subject: [issue8965] test_imp fails on OSX when LANG is set
In-Reply-To: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>
Message-ID: <1276219099.96.0.990386590454.issue8965@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Sorry for extra traffic.  I thought my patch introduced an indentation error, but it looks like you truly don't check sys.getfilesystemencoding() output if not on darwin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8965>
_______________________________________

From report at bugs.python.org  Fri Jun 11 03:22:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 01:22:56 +0000
Subject: [issue8965] test_imp fails on OSX when LANG is set
In-Reply-To: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>
Message-ID: <1276219376.32.0.901712112002.issue8965@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17621/issue8965-test-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8965>
_______________________________________

From report at bugs.python.org  Fri Jun 11 03:28:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 01:28:53 +0000
Subject: [issue850997] mbcs encoding ignores errors
Message-ID: <1276219733.04.0.968271940863.issue850997@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New version of the patch:
 - decode_mbcs() calls raise_translate_exception() to set the error (in the previous patch, I'm not sure that the error was set)
 - include #8784 patch (tarfile uses utf-8 as the default encoding)
 - ctypes: use mbcs is strict mode instead of ignore mode. This is just a workaround, the real fix is to remove the implicit conversion between bytes and characters: see #8966

The patch requires #8969 patch (use mbcs in strict mode to encode/decode filenames).

----------
Added file: http://bugs.python.org/file17622/mbcs_errors-py3k-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue850997>
_______________________________________

From report at bugs.python.org  Fri Jun 11 03:45:46 2010
From: report at bugs.python.org (Mark Nottingham)
Date: Fri, 11 Jun 2010 01:45:46 +0000
Subject: [issue8885] markerbase declaration errors aren't recoverable
In-Reply-To: <1275563651.6.0.351540013915.issue8885@psf.upfronthosting.co.za>
Message-ID: <1276220746.31.0.662114041909.issue8885@psf.upfronthosting.co.za>


Mark Nottingham <mnot at mnot.net> added the comment:

I'm using it from HTMLParser; try to parse a document with the DTD given when error is something like:

    def error(self, msg):
        self.errors += 1

and it will loop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8885>
_______________________________________

From report at bugs.python.org  Fri Jun 11 03:49:00 2010
From: report at bugs.python.org (Mark Nottingham)
Date: Fri, 11 Jun 2010 01:49:00 +0000
Subject: [issue8885] markerbase declaration errors aren't recoverable
In-Reply-To: <1275563651.6.0.351540013915.issue8885@psf.upfronthosting.co.za>
Message-ID: <1276220940.01.0.0690465961305.issue8885@psf.upfronthosting.co.za>


Mark Nottingham <mnot at mnot.net> added the comment:

Attaching test case.

----------
Added file: http://bugs.python.org/file17623/testcase_8885.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8885>
_______________________________________

From report at bugs.python.org  Fri Jun 11 04:21:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Jun 2010 02:21:48 +0000
Subject: [issue8870] --user-access-control=force produces invalid installer on
	Vista
In-Reply-To: <1275417481.6.0.247175279763.issue8870@psf.upfronthosting.co.za>
Message-ID: <1276222908.97.0.635513914565.issue8870@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
superseder:  -> friendly errors for UAC misbehavior in windows installers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8870>
_______________________________________

From report at bugs.python.org  Fri Jun 11 04:37:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Jun 2010 02:37:56 +0000
Subject: [issue8903] Add module level now() and today() functions to datetime
	module
In-Reply-To: <1275720507.31.0.185559003971.issue8903@psf.upfronthosting.co.za>
Message-ID: <1276223876.5.0.119131670429.issue8903@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I actually agree with Anatoly here.  I find it much more intuitive to do

  import datetime

   timestamp = datetime.now()

than to do 

   timestamp = datetime.datetime.now()

I always have to remember that 'now' is a class method, often after getting a "datetime module has no attribute 'now'" message.  In most standard library modules a function like that would be, well, a function.  I can't imagine code where I'd find it more convenient to get 'now' from the class, and if I saw code like

    timestamp = othertimestamp.now()

I'd run screaming.

Personally I think the class methods would be better off deprecated in favor of module level functions.

However, all that said, the datetime API is what it is, and I'm not sure it is worth going through a deprecation cycle for this.  (Though othertimestamp.now() really does give me the heebie jeebies.)

----------
nosy: +r.david.murray
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8903>
_______________________________________

From report at bugs.python.org  Fri Jun 11 04:44:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 02:44:13 +0000
Subject: [issue3129] struct allows repeat spec. without a format specifier
In-Reply-To: <1213694469.69.0.0950890622628.issue3129@psf.upfronthosting.co.za>
Message-ID: <1276224253.01.0.019574896515.issue3129@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Looks reasonable to me as well.  Code patch applies cleanly, but tests don't.  I'll get it ready for commit.

----------
assignee:  -> belopolsky
nosy: +belopolsky
resolution:  -> accepted
versions:  -Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3129>
_______________________________________

From report at bugs.python.org  Fri Jun 11 05:06:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 03:06:27 +0000
Subject: [issue3129] struct allows repeat spec. without a format specifier
In-Reply-To: <1213694469.69.0.0950890622628.issue3129@psf.upfronthosting.co.za>
Message-ID: <1276225587.59.0.659271794993.issue3129@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching an updated patch, but it fails one of the old tests.  Need to investigate this some more.

----------
resolution: accepted -> 
Added file: http://bugs.python.org/file17624/issue3129.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3129>
_______________________________________

From report at bugs.python.org  Fri Jun 11 05:21:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 03:21:59 +0000
Subject: [issue3129] struct allows repeat spec. without a format specifier
In-Reply-To: <1213694469.69.0.0950890622628.issue3129@psf.upfronthosting.co.za>
Message-ID: <1276226519.35.0.446708615504.issue3129@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch works and passes the tests.  The failing test was clearly wrong.  I am still not sure that it is right to raise TypeError rather than struct.error on invalid offset in pack_into, but this is a separate issue.

----------
Added file: http://bugs.python.org/file17625/issue3129.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3129>
_______________________________________

From report at bugs.python.org  Fri Jun 11 05:22:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 03:22:06 +0000
Subject: [issue3129] struct allows repeat spec. without a format specifier
In-Reply-To: <1213694469.69.0.0950890622628.issue3129@psf.upfronthosting.co.za>
Message-ID: <1276226526.36.0.00416789585157.issue3129@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17624/issue3129.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3129>
_______________________________________

From report at bugs.python.org  Fri Jun 11 06:01:01 2010
From: report at bugs.python.org (Michael Curran)
Date: Fri, 11 Jun 2010 04:01:01 +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: <1276228861.24.0.997420058265.issue8959@psf.upfronthosting.co.za>


Michael Curran <mick at nvaccess.org> added the comment:

Issue does not occure using Python 3.1.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8959>
_______________________________________

From report at bugs.python.org  Fri Jun 11 06:02:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 04:02:57 +0000
Subject: [issue8903] Add module level now() and today() functions to datetime
	module
In-Reply-To: <1276223876.5.0.119131670429.issue8903@psf.upfronthosting.co.za>
Message-ID: <AANLkTikJf3xRdpP6IqefM9O4p03Eh0Ij6xwUR54mEKlj@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Jun 10, 2010 at 10:37 PM, R. David Murray
<report at bugs.python.org> wrote:
>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> I actually agree with Anatoly here. ?I find it much more intuitive to do
>
> ?import datetime
>
> ? timestamp = datetime.now()
>
> than to do
>
> ? timestamp = datetime.datetime.now()
>

Given the unfortunate name clash between the class and the module, I
never do "import datetime" and instead doe "from datetime import
datetime, date".  I find it very convenient  that importing datetime
class brings in all related functions and I don't need to import
factory functions separately.

Also, ISTM that the datetime module was designed to allow easy
extension by subclassing.  The factory methods are written so that
they work for subclasses:

...   pass
>>> Date.today()
Date(2010, 6, 10)

Writing a separate module level today() for the subclass would be quite awkward.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8903>
_______________________________________

From report at bugs.python.org  Fri Jun 11 06:23:25 2010
From: report at bugs.python.org (=?utf-8?b?VGFtw6FzIEd1bMOhY3Np?=)
Date: Fri, 11 Jun 2010 04:23:25 +0000
Subject: [issue8961] compile Python-2.7rc1 on AIX 5.3 with xlc_r
In-Reply-To: <1276178256.7.0.316939316511.issue8961@psf.upfronthosting.co.za>
Message-ID: <1276230205.44.0.65219434614.issue8961@psf.upfronthosting.co.za>


Tam?s Gul?csi <gt-dev at gthomas.homelinux.org> added the comment:

srid,

You must be right, but the question is: How can I compile Python-2.7rc1 on AIX 5.3? I'd never said that this is a Python fault...

I downloaded and extracted a fresh tarball, but the result is the same with the given ./configure call. So the problem is with the call: LDFLAGS='$FW/lib' just keeps '$' in it, it should be LDFLAGS="$FW/lib".

Sorry for the false alarm, although the error message was quite far from the cause.

Thanks for everybody,
Tam?s Gul?csi

make fails when trying to compile the modules with the freshly linked ./python - I've attached a list of sysconfig._CONFIG_VARS.

Tam?s Gul?csi

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8961>
_______________________________________

From report at bugs.python.org  Fri Jun 11 06:23:40 2010
From: report at bugs.python.org (=?utf-8?b?VGFtw6FzIEd1bMOhY3Np?=)
Date: Fri, 11 Jun 2010 04:23:40 +0000
Subject: [issue8961] compile Python-2.7rc1 on AIX 5.3 with xlc_r
In-Reply-To: <1276178256.7.0.316939316511.issue8961@psf.upfronthosting.co.za>
Message-ID: <1276230220.63.0.467610678009.issue8961@psf.upfronthosting.co.za>


Changes by Tam?s Gul?csi <gt-dev at gthomas.homelinux.org>:


----------
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8961>
_______________________________________

From report at bugs.python.org  Fri Jun 11 06:59:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 04:59:47 +0000
Subject: [issue8968] token type constants are not documented
In-Reply-To: <1276216063.7.0.11813766705.issue8968@psf.upfronthosting.co.za>
Message-ID: <1276232387.19.0.73185328496.issue8968@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It is. Constants should be documented in the regular doc, not only by introspection or reading the source. See the doc for tokenize: ?All constants from the token module are also exported from tokenize, as are two additional token type values?.

Thanks for the report. Would you mind writing a patch?

----------
nosy: +merwok
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/issue8968>
_______________________________________

From report at bugs.python.org  Fri Jun 11 07:48:44 2010
From: report at bugs.python.org (Michael Curran)
Date: Fri, 11 Jun 2010 05:48:44 +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: <1276235324.16.0.0487815303822.issue8959@psf.upfronthosting.co.za>


Michael Curran <mick at nvaccess.org> added the comment:

The issue does not occure with Python 2.7 beta 1, but does occure in Python 2.7 beta 2.

So, with this in mind, its probably more likely that it may have been caused by the following change:
"- On Windows, ctypes does no longer check the stack before and after calling a
  foreign function.  This allows to use the unmodified libffi library."

I had previously thought it could have been the libffi upgrade, but this seems to have  happened in Beta 1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8959>
_______________________________________

From report at bugs.python.org  Fri Jun 11 08:00:20 2010
From: report at bugs.python.org (Tal Einat)
Date: Fri, 11 Jun 2010 06:00:20 +0000
Subject: [issue8820] IDLE not launching correctly
In-Reply-To: <1274842084.45.0.257196773636.issue8820@psf.upfronthosting.co.za>
Message-ID: <1276236020.52.0.0577239019318.issue8820@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

Joseph, please mention which version of Python you are trying this with. If 2.6.4, please try with 2.6.5 to see if it still happens.

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8820>
_______________________________________

From report at bugs.python.org  Fri Jun 11 08:35:25 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 11 Jun 2010 06:35:25 +0000
Subject: [issue8903] Add module level now() and today() functions to datetime
	module
In-Reply-To: <1275720507.31.0.185559003971.issue8903@psf.upfronthosting.co.za>
Message-ID: <1276238125.4.0.382056752839.issue8903@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, I concur with the rejection.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8903>
_______________________________________

From report at bugs.python.org  Fri Jun 11 08:44:45 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 11 Jun 2010 06:44:45 +0000
Subject: [issue8903] Add module level now() and today() functions to datetime
	module
In-Reply-To: <1275720507.31.0.185559003971.issue8903@psf.upfronthosting.co.za>
Message-ID: <1276238685.31.0.348601078753.issue8903@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8903>
_______________________________________

From report at bugs.python.org  Fri Jun 11 09:21:37 2010
From: report at bugs.python.org (Rick Johnson)
Date: Fri, 11 Jun 2010 07:21:37 +0000
Subject: [issue8970] Tkinter Litmus Test
In-Reply-To: <1276240896.62.0.886214435094.issue8970@psf.upfronthosting.co.za>
Message-ID: <1276240896.62.0.886214435094.issue8970@psf.upfronthosting.co.za>


New submission from Rick Johnson <rantingrick at gmail.com>:

There has been much discussion in the past and recently on c.l.p about how many python programmers *actually* use Tkinter. Recently i have been involved in a lengthy discussion on c.l.p about whether or not we should remove Tkinter, replace Tkinter, or fix Tkinter. 

However i feel a decision this important cannot be made from pydev, c.l.p, or anywhere. I believe the only proper way to proceed is to get a *real* vote from *real* python programmers out in the trenches. 

But how do we do that you may ask? Well thats a good question. Not every Python programmer lives on c.l.p, or any *one* place. The only way to truly reach everyone is thru Python itself in form of a Warning message. 

So i propose that an import warning be added to the next possible releases of Python 3.x and Python 3.x. This warning will be triggered upon importing Tkinter and should also be shown when starting IDLE. The message should read loosely as follows...

"""
-------------------------------------------------
 ModuleRemovalWarning: Tkinter (and dependencies)
-------------------------------------------------
The Tkinter module (Python's GUI module) is currently being considered for removal from the python stdlib FOREVER. We are providing this warning so that you can give the python devlopment team (and the wider community) your input on the subject. If you feel that Tkinter should or should not be removed we strongly incurage you to voice your opinion. You can do by casting your vote at "www.savetkinter.com". Whether your a complete noobie or a seasoned Pythonista we need to hear everyone. Voting will end on MM-DD-YYYY, so make sure your vote is counted!
"""

----------
components: IDLE, Tkinter
messages: 107531
nosy: rantingrick
priority: normal
severity: normal
status: open
title: Tkinter Litmus Test
type: feature request
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8970>
_______________________________________

From report at bugs.python.org  Fri Jun 11 09:27:43 2010
From: report at bugs.python.org (Rick Johnson)
Date: Fri, 11 Jun 2010 07:27:43 +0000
Subject: [issue8971] Tkinter Litmus Test
In-Reply-To: <1276241262.66.0.609835750644.issue8971@psf.upfronthosting.co.za>
Message-ID: <1276241262.66.0.609835750644.issue8971@psf.upfronthosting.co.za>


New submission from Rick Johnson <rantingrick at gmail.com>:

There has been much discussion in the past and recently on c.l.p about how many python programmers *actually* use Tkinter. Recently i have been involved in a lengthy discussion on c.l.p about whether or not we should remove Tkinter, replace Tkinter, or fix Tkinter. 

However i feel a decision this important cannot be made from pydev, c.l.p, or anywhere. I believe the only proper way to proceed is to get a *real* vote from *real* python programmers out in the trenches. 

But how do we do that you may ask? Well thats a good question. Not every Python programmer lives on c.l.p, or any *one* place. The only way to truly reach everyone is through Python itself in form of a Warning message. 

So i propose that an import warning be added to the next possible releases of Python 2.x and Python 3.x. This warning will be triggered upon importing Tkinter and should also be shown when starting IDLE. The message should read loosely as follows...

"""
-------------------------------------------------
 ModuleRemovalWarning: Tkinter (and dependencies)
-------------------------------------------------
The Tkinter module (Python's GUI module) is currently being considered for removal from the python stdlib FOREVER. We are providing this warning so that you can give the python development team (and the wider community) your feedback on the subject. If you feel that Tkinter should or should not be removed we strongly encourage you to voice your opinion. You can do by casting your vote at "www.savetkinter.com". We need to hear everyone whether your a complete newbie or a seasoned Pythonista.  Voting will end on MM-DD-YYYY  so make sure your vote is counted!
"""

----------
components: IDLE, Tkinter
messages: 107532
nosy: rantingrick
priority: normal
severity: normal
status: open
title: Tkinter Litmus Test
type: feature request
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8971>
_______________________________________

From report at bugs.python.org  Fri Jun 11 09:32:20 2010
From: report at bugs.python.org (Rick Johnson)
Date: Fri, 11 Jun 2010 07:32:20 +0000
Subject: [issue8970] Tkinter Litmus Test
In-Reply-To: <1276240896.62.0.886214435094.issue8970@psf.upfronthosting.co.za>
Message-ID: <1276241540.79.0.822912102858.issue8970@psf.upfronthosting.co.za>


Changes by Rick Johnson <rantingrick at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8970>
_______________________________________

From report at bugs.python.org  Fri Jun 11 09:51:31 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 11 Jun 2010 07:51:31 +0000
Subject: [issue8954] wininst regression: errors when building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1276242691.42.0.576088569804.issue8954@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

$ python setup.py build bdist_wininst
running build
running build_py
running bdist_wininst
installing to build/bdist.linux-i686/wininst
running install_lib
creating build/bdist.linux-i686/wininst
creating build/bdist.linux-i686/wininst/PURELIB
copying build/lib.linux-i686-2.6/wget.py -> build/bdist.linux-i686/wininst/PURELIB
running install_egg_info
Writing build/bdist.linux-i686/wininst/PURELIB/wget-0.6.egg-info
creating '/tmp/tmpQQZI5O.zip' and adding '.' to it
adding 'PURELIB/wget-0.6.egg-info'
adding 'PURELIB/wget.py'
creating dist
Warning: Can't read registry to find the necessary compiler setting
Make sure that Python modules _winreg, win32api or win32con are installed.
removing 'build/bdist.linux-i686/wininst' (and everything under it)
$ ls dist
wget-0.6.linux-i686.exe

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8954>
_______________________________________

From report at bugs.python.org  Fri Jun 11 09:52:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 07:52:07 +0000
Subject: [issue8970] Tkinter Litmus Test
In-Reply-To: <1276240896.62.0.886214435094.issue8970@psf.upfronthosting.co.za>
Message-ID: <1276242727.63.0.501152276386.issue8970@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> duplicate
superseder:  -> Tkinter Litmus Test

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8970>
_______________________________________

From report at bugs.python.org  Fri Jun 11 10:22:52 2010
From: report at bugs.python.org (Peter Landgren)
Date: Fri, 11 Jun 2010 08:22:52 +0000
Subject: [issue8924] Error in error message in logging
In-Reply-To: <1275850912.41.0.0811394159532.issue8924@psf.upfronthosting.co.za>
Message-ID: <1276244572.41.0.637828593498.issue8924@psf.upfronthosting.co.za>


Peter Landgren <peter.talken at telia.com> added the comment:

Answer to your first question:
- The variable s is of type 'unicode'
- The variable record.exc_text, which is what Formatter.formatException returns, is of type 'str'

For your second question; I'm not a python expert, so I can't follow you there. I don't know what to do to test this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8924>
_______________________________________

From report at bugs.python.org  Fri Jun 11 10:36:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 08:36:28 +0000
Subject: [issue8954] wininst regression: errors when building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1276245388.6.0.907340070213.issue8954@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The error comes from the msvccompiler module, which shouldn?t get used on non-Windows platforms unless I?m mistaken. Reading the module, I?m not sure at all this command was meant to be run on not-Windows OSes.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8954>
_______________________________________

From report at bugs.python.org  Fri Jun 11 10:48:01 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 11 Jun 2010 08:48:01 +0000
Subject: [issue8954] wininst regression: errors when building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1276246081.12.0.034793310042.issue8954@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

It did run ok on non-Windows OSes with previous Python versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8954>
_______________________________________

From report at bugs.python.org  Fri Jun 11 10:54:31 2010
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Fri, 11 Jun 2010 08:54:31 +0000
Subject: [issue2892] improve cElementTree iterparse error handling
In-Reply-To: <1210940435.5.0.243679200602.issue2892@psf.upfronthosting.co.za>
Message-ID: <1276246471.53.0.74986551959.issue2892@psf.upfronthosting.co.za>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

Here is a small test case that demonstrates the problem, expected behavior and actual behavior:

{{{
for ev in xml.etree.cElementTree.iterparse(StringIO('<x></x>rubbish'), events=('start', 'end')):
    print ev
}}}

The above code should first print the two events (start and end), and then raise the exception.  In Python 2.7 it runs like this:

{{{
>>> for ev in xml.etree.cElementTree.iterparse(StringIO('<x></x>rubbish'), events=('start', 'end')):
...   print ev
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 84, in next
cElementTree.ParseError: junk after document element: line 1, column 7
}}}

Expected behavior, obtained with my patch, is that it runs like this:

{{{
>>> for ev in my_iterparse(StringIO('<x></x>rubbish'), events=('start', 'end')):
...  print ev
... 
('start', <Element 'x' at 0xb771cba8>)
('end', <Element 'x' at 0xb771cba8>)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 26, in __iter__
cElementTree.ParseError: junk after document element: line 1, column 7
}}}

The difference is, of course, only visible when printing events.  A side-effect-free operation, such as building a list using list(iterparse(...)) would behave exactly the same before and after the change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2892>
_______________________________________

From report at bugs.python.org  Fri Jun 11 12:48:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 10:48:03 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1276253283.63.0.265763717596.issue8362@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I am willing to maintain the maintainers file for 2.x with due diligence for the coming years. I think it has proven useful, and would like to see it in 2.6 up to 3.2 (all current four branches, since it?s arguably a documentation issue). Do I need to find a unique committer willing to work with me for this to be accepted?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Fri Jun 11 12:51:53 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Jun 2010 10:51:53 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1276253513.16.0.319751883292.issue8188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Committed the Decimal-to-Fraction comparisons in r81893.  All numeric types should now compare nicely with each other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Fri Jun 11 12:52:59 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 11 Jun 2010 10:52:59 +0000
Subject: [issue8958] 2.7rc1 tarfile.py: `bltn_open(targetpath,
	"wb")` -> IOError: Is a directory
In-Reply-To: <1276118455.66.0.211402542637.issue8958@psf.upfronthosting.co.za>
Message-ID: <1276253579.62.0.521555756926.issue8958@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I found the problem. As of r76780 the default for the TarFile.errorlevel argument changed from 0 (suppress errors and write them to the debug log instead) to 1 (raise exceptions for fatal extraction errors). This change was not backported to the 2.6 branch back then (it was blocked in r76781).

This means, that Python 2.6 does not succeed either, but the error is simply suppressed.

Ergo, this is no regression but a simple filesystem issue.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8958>
_______________________________________

From report at bugs.python.org  Fri Jun 11 14:22:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Jun 2010 12:22:45 +0000
Subject: [issue8971] Tkinter Litmus Test
In-Reply-To: <1276241262.66.0.609835750644.issue8971@psf.upfronthosting.co.za>
Message-ID: <1276258965.82.0.997245502054.issue8971@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Everyone who uses IDLE uses TKInter, and a lot of people use IDLE.

In any case, any such proposal should be discussed on python-ideas first, followed by python-dev if you actually get a consensus about it.

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8971>
_______________________________________

From report at bugs.python.org  Fri Jun 11 14:38:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Jun 2010 12:38:18 +0000
Subject: [issue8947] Provide  as_integer_ratio() method to Decimal
In-Reply-To: <1276030268.17.0.98739433208.issue8947@psf.upfronthosting.co.za>
Message-ID: <1276259898.17.0.886338891003.issue8947@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file17626/issue8947.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8947>
_______________________________________

From report at bugs.python.org  Fri Jun 11 14:56:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Jun 2010 12:56:38 +0000
Subject: [issue8947] Provide  as_integer_ratio() method to Decimal
In-Reply-To: <1276030268.17.0.98739433208.issue8947@psf.upfronthosting.co.za>
Message-ID: <1276260998.68.0.705826474514.issue8947@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Updated patch, taking into account comments from merwok and exarkun on #python-dev:

 - remove doctests for infinity and nan, replace with a sentence
   explaining what happens for such inputs.
 - replace 'snAN' with saner spelling 'snan'.

----------
Added file: http://bugs.python.org/file17627/issue8947_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8947>
_______________________________________

From report at bugs.python.org  Fri Jun 11 15:11:08 2010
From: report at bugs.python.org (shypike)
Date: Fri, 11 Jun 2010 13:11:08 +0000
Subject: [issue8972] subprocess.list2cmdline doesn't quote the & character
In-Reply-To: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>
Message-ID: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>


New submission from shypike <shypike at sabnzbd.org>:

subprocess.py/list2cmdline should also put double quotes around strings that contain ampersands (&), but no spaces.
If not, the Windows command processor will split the command into two separate parts. In short, '&' needs the same treatment as '|'.

----------
components: Windows
messages: 107544
nosy: shypike
priority: normal
severity: normal
status: open
title: subprocess.list2cmdline doesn't quote the & character
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8972>
_______________________________________

From report at bugs.python.org  Fri Jun 11 15:32:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Jun 2010 13:32:59 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276263179.23.0.820790642889.issue5094@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm not sure if I missed this in the earlier discussion:  is there a reason to prevent subclassing of timezone?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Fri Jun 11 16:23:08 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Jun 2010 14:23:08 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276266188.13.0.874761314411.issue5094@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Some comments from playing with this patch (without having looked at the implementation):

- As noted above, the 'timezone' class can't be subclassed.  Is this deliberate?  I notice that Brett said "let users subclass as needed to add DST support" in msg107008.

- If I try to do  timezone(timedelta(hours=24)), I get an error message:
"ValueError: offset must be a timedelta between timedelta(1) and -timedelta(1)." and I have to think for a bit to remember that 'timedelta(1)' means 'timedelta(days=1)'.  Any chance of making this more explicit:  e.g. "between timedelta(hours=-24) and timedelta(hours=24)"?

- The existing docs say, at one point: "if utcoffset does not return None,
dst() should not return None either."  And yet it seems that this is exactly what happens for timezone instances:  utcoffset doesn't return None, but dst does.  Was there a reason for the explicit restriction in the docs, and are we sure that that reason is no longer valid?

- I find it strange that mytimezone.utcoffset(1+3j) works;  similarly for tzname and dst.  Perhaps it should be checked at least that the argument is a datetime.  Similarly for tzname and dst.

- And it also seems clunky that an argument *has* to be supplied for utcoffset, tzname and dst, only to be ignored.  Would it be possible to make the argument optional?

- Any chance of a nice __str__ implementation for timezone instances?  (And/or possibly a nice __repr__ as well)?

- The docs for tzname are misleading:  they claim that the default name has the form "UTCsHHMM".  This isn't true for UTC+0, whose name seems to be just "UTC".  It actually wouldn't seem unreasonable to have this print as "UTC+0000", just for consistency (and for ease of parsing for anyone on the receiving end of such a string).  Or the docs could be fixed.

- I'm very confused about utcoffset:  why can't I supply a UTC datetime (i.e. an aware datetime with tzinfo = timezone.utc) to this?  I suspect I'm misunderstanding something here...

- In the docs, replace "timezeone" with "timezone"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Fri Jun 11 16:30:33 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Jun 2010 14:30:33 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276266633.59.0.973504285798.issue5094@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One more: there's a footnote marked in the docs (line 36 of datetime.rst), but no corresponding footnote as far as I can see.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Fri Jun 11 16:39:12 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Jun 2010 14:39:12 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276267152.45.0.987073831205.issue5094@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

And another minor doc issue:  the docs still say:

"The datetime module does not supply any concrete subclasses of tzinfo."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Fri Jun 11 16:43:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Jun 2010 14:43:32 +0000
Subject: [issue6641] strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276267412.96.0.49853193961.issue6641@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It's a little awkward to review this patch independently of the issue 5094 patch.  Can we work on issue 5094 first, and then come back to this one?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Fri Jun 11 16:55:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Jun 2010 14:55:38 +0000
Subject: [issue3129] struct allows repeat spec. without a format specifier
In-Reply-To: <1213694469.69.0.0950890622628.issue3129@psf.upfronthosting.co.za>
Message-ID: <1276268138.35.0.261316890245.issue3129@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the patch; I'll take a look.

----------
assignee: belopolsky -> mark.dickinson
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3129>
_______________________________________

From report at bugs.python.org  Fri Jun 11 16:58:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 14:58:50 +0000
Subject: [issue1697943] msgfmt cannot cope with BOM
Message-ID: <1276268330.22.0.732307303437.issue1697943@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1697943>
_______________________________________

From report at bugs.python.org  Fri Jun 11 17:11:29 2010
From: report at bugs.python.org (Tal Einat)
Date: Fri, 11 Jun 2010 15:11:29 +0000
Subject: [issue8515] idle "Run Module" (F5) does not set __file__ variable
In-Reply-To: <1272071890.53.0.295001627395.issue8515@psf.upfronthosting.co.za>
Message-ID: <1276269089.89.0.608423270885.issue8515@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

I believe IDLE runs modules via execfile(), so I would expect the behavior to be similar, and execfile() does not set __file__. Doing "Run Module" is also IMO equivalent to doing execfile(), so this behavior retains consistency.

However, I would expect __file__ to be set when running IDLE -r <script>, but I get "name '__file__' is not defined" (with Python 2.6.2). This is inconsistent and should be fixed.

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8515>
_______________________________________

From report at bugs.python.org  Fri Jun 11 17:14:50 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 15:14:50 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1276266188.13.0.874761314411.issue5094@psf.upfronthosting.co.za>
Message-ID: <AANLkTikZ9tEcGN7EZLDmnUvwh4MTo6hW5UfP0rAif-Bc@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Jun 11, 2010 at 10:23 AM, Mark Dickinson <report at bugs.python.org> wrote:
..
> Some comments from playing with this patch (without having looked at the implementation):
>
thank you very much for your comments.  As we are fine-tuning the
timezone class, do you think it would be helpful to go back to Brett's
suggestion and add datetime.py with just from _datetime import * and
keep parallel Python and C implementations of timezone class only
until full datetime.py is available?

I was deliberate in a sense that I thought about it, but there was no
substantial discussion.  Original patch did not allow subclassing of
the UTC class and I thought it was right.  (See msg106415 and
msg106422.) subclassing FixedOffsetTimeZone makes more sense, but I
was hoping to keep timezone complete and eventually stop supporting
tzinfo API (not allow passing datetime in the methods.)  More on this
below.  I would very much prefer not to open the subclassing debate.
If you support subclassing, I will add a flag. My only objection is
that it is much easier to add this functionality in the future than to
remove it if it gets abused.  Can we postpone this decision until real
life use case comes in?  (Subclass to change dst() in itself is not a
use case.  Why do you need legacy timetuple interface to work is the
first question.)

> - If I try to do ?timezone(timedelta(hours=24)), I get an error message:
> "ValueError: offset must be a timedelta between timedelta(1) and -timedelta(1)." and I have to think for a bit to
> remember that 'timedelta(1)' means 'timedelta(days=1)'. ?Any chance of making this more explicit: ?e.g. "between > timedelta(hours=-24) and timedelta(hours=24)"?
>

Please make a call and I'll implement it.  The competing spellings are:

1. timedelta(hours=24)
2. 24 hours (I rejected this because it may be confused with an int)
3. timedelta(days=1)
4. in the range [-timedelta(hours=23, minutes=59), timedelta(hours=23,
minutes=59)]

Yes, there was a reason, but I don't think it is a good one.  The
default implementation of fromutc() does not work if utcoffset()
returns timedelta but dst() returns None.  The dst() value used to
detect DST ambiguities.  Remember, fromutc() despite the name is
defined to operate on local times and some local times are ambiguous
and some are invalid.  The default implementation attempts to detect
that.  This is the issue that I am trying to avoid in my design.

The test is easy to add.  My longer term plan is to disallow passing
argument to constant methods, so adding check is somewhat wasteful.
Will do.

> - And it also seems clunky that an argument *has* to be supplied for utcoffset, tzname and dst, only to be i
> gnored. ?Would it be possible to make the argument optional?

Yes.  this was my transition plan.  Make it optional.  Modify datetime
methods to first try to get offset/name/dst without passing time
argument and fall back to passing self.  Remove optional argument from
timezone methods.

Yes.  I want parseable __repr__ as well.  I've been torn between
'datetime.timezone(datetime.timedelta(..)[, ..])'  and
'timezone(timedelta(..)[, ..])'. Opinions welcome.  Similarly, should
str(timezone.utc) be '+0000' or 'UTC' or '+00:00'?

You are reading my mind.  I planned to tear out conditional logic that
supports plain 'UTC', but apparently forgot.  Will do.

> - I'm very confused about utcoffset: ?why can't I supply a UTC datetime (i.e. an aware datetime with
> tzinfo = timezone.utc) to this? ?I suspect I'm misunderstanding something here...

You are not alone! :-)  My understanding is that utcoffset was
designed around the notion that if you add a day to 12 noon the day
before DST change, you should still get 12 noon the next day.
Supporting this requires deriving local timezone from local time which
is impossible for some datetime values.  Most business applications
can ignore this because nobody schedules meetings between 1 and 2 am
and those who do are smart enough to catch an exception and ask the
user to clarify what time he/she means.

Good catch.  Thanks for the review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Fri Jun 11 17:21:28 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Jun 2010 15:21:28 +0000
Subject: [issue3129] struct allows repeat spec. without a format specifier
In-Reply-To: <1213694469.69.0.0950890622628.issue3129@psf.upfronthosting.co.za>
Message-ID: <1276269688.24.0.347490537394.issue3129@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Patch looks great!   Please apply (with suitable Misc/NEWS entry).  Since the bug is fairly harmless, I think it's fine just to apply this to py3k, and not to backport to 2.x or to 3.1.

I also noticed some dependence on undefined behaviour in prepare_s, but I'll fix that separately.

BTW, please do add me to the nosy on any struct issues you encounter;  I'm currently acting as maintainer of this module (for my sins).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3129>
_______________________________________

From report at bugs.python.org  Fri Jun 11 17:21:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Jun 2010 15:21:56 +0000
Subject: [issue3129] struct allows repeat spec. without a format specifier
In-Reply-To: <1213694469.69.0.0950890622628.issue3129@psf.upfronthosting.co.za>
Message-ID: <1276269716.01.0.0120005292851.issue3129@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee: mark.dickinson -> belopolsky
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3129>
_______________________________________

From report at bugs.python.org  Fri Jun 11 17:23:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 15:23:44 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276269824.75.0.787420010269.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I have to stop replying to emails.  There is no reason behind roundup remove ">" comments logic.   Reposting my message:

"""
On Fri, Jun 11, 2010 at 10:23 AM, Mark Dickinson <report at bugs.python.org> wrote:
..
> Some comments from playing with this patch (without having looked at the implementation):
>
thank you very much for your comments.  As we are fine-tuning the
timezone class, do you think it would be helpful to go back to Brett's
suggestion and add datetime.py with just from _datetime import * and
keep parallel Python and C implementations of timezone class only
until full datetime.py is available?

> - As noted above, the 'timezone' class can't be subclassed.  Is this deliberate?
>  I notice that Brett said "let users subclass as needed to add DST support" in msg107008.
>
I was deliberate in a sense that I thought about it, but there was no
substantial discussion.  Original patch did not allow subclassing of
the UTC class and I thought it was right.  (See msg106415 and
msg106422.) subclassing FixedOffsetTimeZone makes more sense, but I
was hoping to keep timezone complete and eventually stop supporting
tzinfo API (not allow passing datetime in the methods.)  More on this
below.  I would very much prefer not to open the subclassing debate.
If you support subclassing, I will add a flag. My only objection is
that it is much easier to add this functionality in the future than to
remove it if it gets abused.  Can we postpone this decision until real
life use case comes in?  (Subclass to change dst() in itself is not a
use case.  Why do you need legacy timetuple interface to work is the
first question.)


> - If I try to do  timezone(timedelta(hours=24)), I get an error message:
> "ValueError: offset must be a timedelta between timedelta(1) and -timedelta(1)." and I have to think for a bit to
> remember that 'timedelta(1)' means 'timedelta(days=1)'.  Any chance of making this more explicit:  e.g. "between > timedelta(hours=-24) and timedelta(hours=24)"?
>

Please make a call and I'll implement it.  The competing spellings are:

1. timedelta(hours=24)
2. 24 hours (I rejected this because it may be confused with an int)
3. timedelta(days=1)
4. in the range [-timedelta(hours=23, minutes=59), timedelta(hours=23,
minutes=59)]


> - The existing docs say, at one point: "if utcoffset does not return None,
> dst() should not return None either."  And yet it seems that this is exactly what happens for timezone instances: > utcoffset doesn't return None, but dst does.
>  Was there a reason for the explicit restriction in the docs, and are we sure that that reason is no longer valid?
>
Yes, there was a reason, but I don't think it is a good one.  The
default implementation of fromutc() does not work if utcoffset()
returns timedelta but dst() returns None.  The dst() value used to
detect DST ambiguities.  Remember, fromutc() despite the name is
defined to operate on local times and some local times are ambiguous
and some are invalid.  The default implementation attempts to detect
that.  This is the issue that I am trying to avoid in my design.


> - I find it strange that mytimezone.utcoffset(1+3j) works;  similarly
> for tzname and dst.  Perhaps it should be
> checked at least that the argument is a datetime.  Similarly for
> tzname and dst.
>
The test is easy to add.  My longer term plan is to disallow passing
argument to constant methods, so adding check is somewhat wasteful.
Will do.

> - And it also seems clunky that an argument *has* to be supplied for
> utcoffset, tzname and dst, only to be ignored.
>  Would it be possible to make the argument optional?

Yes.  this was my transition plan.  Make it optional.  Modify datetime
methods to first try to get offset/name/dst without passing time
argument and fall back to passing self.  Remove optional argument from
timezone methods.

I can make the arg optional now.
>
> - Any chance of a nice __str__ implementation for timezone instances?
>  (And/or possibly a nice __repr__ as well)?
>
Yes.  I want parseable __repr__ as well.  I've been torn between
'datetime.timezone(datetime.timedelta(..)[, ..])'  and
'timezone(timedelta(..)[, ..])'. Opinions welcome.  Similarly, should
str(timezone.utc) be '+0000' or 'UTC' or '+00:00'?

> - The docs for tzname are misleading:  they claim that the default name has the form "UTCsHHMM".  This isn't
> true for UTC+0, whose name seems to be just "UTC".  It actually wouldn't seem unreasonable to have this print
> as "UTC+0000", just for consistency (and for ease of parsing for anyone on the receiving end of such a string).
> Or the docs could be fixed.
>
You are reading my mind.  I planned to tear out conditional logic that
supports plain 'UTC', but apparently forgot.  Will do.

> - I'm very confused about utcoffset:  why can't I supply a UTC datetime (i.e. an aware datetime with
> tzinfo = timezone.utc) to this?  I suspect I'm misunderstanding something here...

You are not alone! :-)  My understanding is that utcoffset was
designed around the notion that if you add a day to 12 noon the day
before DST change, you should still get 12 noon the next day.
Supporting this requires deriving local timezone from local time which
is impossible for some datetime values.  Most business applications
can ignore this because nobody schedules meetings between 1 and 2 am
and those who do are smart enough to catch an exception and ask the
user to clarify what time he/she means.

> - In the docs, replace "timezeone" with "timezone"
>
Good catch.  Thanks for the review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Fri Jun 11 17:27:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 15:27:16 +0000
Subject: [issue6641] strptime doesn't support %z format ?
In-Reply-To: <1276267412.96.0.49853193961.issue6641@psf.upfronthosting.co.za>
Message-ID: <AANLkTimUAnQHpG5Dc-IBOx1uDNuHdSbAxg-ZPz2rqZSi@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Jun 11, 2010 at 10:43 AM, Mark Dickinson <report at bugs.python.org> wrote:
..
> It's a little awkward to review this patch independently of the issue 5094 patch.
> ?Can we work on issue 5094 first, and then come back to this one?

Sure.  Unfortunately, I think I fixed a few timezone doc warts here
and did not update 5094.  I will fix that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Fri Jun 11 17:32:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 15:32:38 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Module level pack, unpack etc. methods have similar functionality with Struct instance methods, but docs are different.  The immediate issue is the lack of signature in the module level methods' docstrings.


$ ./python.exe -m pydoc struct.Struct.pack
Help on method_descriptor in struct.Struct:

struct.Struct.pack = pack(...)
    S.pack(v1, v2, ...) -> bytes
    
    Return a bytes containing values v1, v2, ... packed according to this
    Struct's format. See struct.__doc__ for more on format strings.

and

$ ./python.exe -m pydoc struct.pack
Help on built-in function pack in struct:

struct.pack = pack(...)
    Return bytes containing values v1, v2, ... packed according to fmt.

----------
components: Extension Modules
messages: 107556
nosy: belopolsky, mark.dickinson
priority: normal
severity: normal
status: open
title: Inconsistent docstrings in struct module
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Fri Jun 11 17:41:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 15:41:39 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276270899.91.0.734910039533.issue8973@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Two more bits:

1. "See struct.__doc__", while technically correct, is not user friendly.  If you copy struct.__doc__ to >>> prompt, you get an ugly repr of a multiline string.  I suggest s/struct.__doc__/help(struct)/.

2.  For some reason struct.Struct does not show up in help(struct).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Fri Jun 11 17:42:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Jun 2010 15:42:55 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276270975.74.0.917338855927.issue8973@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the reports;  I'll look at this a little later.

----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Fri Jun 11 18:26:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 16:26:47 +0000
Subject: [issue5464] msgfmt.py does not work with plural form
In-Reply-To: <1236635230.35.0.0644981096799.issue5464@psf.upfronthosting.co.za>
Message-ID: <1276273607.35.0.888269740254.issue5464@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5464>
_______________________________________

From report at bugs.python.org  Fri Jun 11 18:36:43 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 16:36:43 +0000
Subject: [issue8502] proposal: encourage xgettext rather than pygettext.py in
	gettext docs
In-Reply-To: <1271985007.3.0.675755685137.issue8502@psf.upfronthosting.co.za>
Message-ID: <1276274203.47.0.962189345438.issue8502@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Does the fixing of #5464 solve your problem?

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8502>
_______________________________________

From report at bugs.python.org  Fri Jun 11 18:44:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 16:44:11 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1276274651.45.0.255084158104.issue2504@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The patch needs to be updated for the 3.x trunk (py3k branch), since the last 2.x version is already rc.

Everyone, thanks for expressing interest for the development of Python, but posting ?me too? messages does not further the discussion, and actually takes time from already busy people. Use cases, patches, reviews and the occasional bump (one is enough) are helpful. :)

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Fri Jun 11 19:02:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 17:02:24 +0000
Subject: [issue4391] optparse: use proper gettext plurals forms
In-Reply-To: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
Message-ID: <1276275744.95.0.963364395642.issue4391@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your patch. I have some remarks:
1) please produce a patch from the top level of a Python checkout (cf. http://www.python.org/dev/patches/);
2) wrap lines under 80 characters;
3) bug with %-formatting: the singular message takes one arg, the plural two (optparse bug, not your patch?s bug, but the patch should fix it too);
4) ?usage? has been used for decades in command line parsing, it?s fine.

I?m adding Armin to the nosy list since he?s listed in py3k/Misc/maintainers.rst

----------
nosy: +aronacher, merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4391>
_______________________________________

From report at bugs.python.org  Fri Jun 11 19:05:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 17:05:22 +0000
Subject: [issue1288056] pygettext - provide comments to help translators
Message-ID: <1276275922.17.0.772008653057.issue1288056@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Translator comments seem to me nicer than contexts (http://bugs.python.org/issue2504), but I?m not sure which one is recommended when they overlap.

I?m -1 on the same line restriction. Python style is to put comments on the previous line.

The 2.x line does not accept new features, so your patch needs to be ported to 3.x (branch name py3k).

FWIW, Babel uses a different style of comments, on the preceding line: http://babel.edgewall.org/wiki/Documentation/messages.html#translator-comments

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1288056>
_______________________________________

From report at bugs.python.org  Fri Jun 11 19:16:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 17:16:55 +0000
Subject: [issue8974] svnmerge errors in msgfmt.py
In-Reply-To: <1276276615.62.0.0556230549588.issue8974@psf.upfronthosting.co.za>
Message-ID: <1276276615.62.0.0556230549588.issue8974@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

svnmerge for r81698 introduced incorrect print(sys.stderr, ...) calls. Attached patch fixes it. Apply with patch -p1.

----------
assignee: loewis
components: Demos and Tools
files: strange-print.diff
keywords: patch
messages: 107563
nosy: loewis, merwok
priority: normal
severity: normal
status: open
title: svnmerge errors in msgfmt.py
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file17628/strange-print.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8974>
_______________________________________

From report at bugs.python.org  Fri Jun 11 19:34:49 2010
From: report at bugs.python.org (Popa Claudiu)
Date: Fri, 11 Jun 2010 17:34:49 +0000
Subject: [issue8975] Bug in cookiejar
In-Reply-To: <1276277689.33.0.403419112347.issue8975@psf.upfronthosting.co.za>
Message-ID: <1276277689.33.0.403419112347.issue8975@psf.upfronthosting.co.za>


New submission from Popa Claudiu <pcmanticore at gmail.com>:

Hello. This is my first report, sorry if I won't do it right.
I found a bug in cookielib, which looks like this(a traceback):

"""C:\Python31\lib\http\cookiejar.py:1586: UserWarning: http.cookiejar bug!
Traceback (most recent call last):
  File "C:\Python31\lib\http\cookiejar.py", line 1584, in make_cookies
    parse_ns_headers(ns_hdrs), request)
  File "C:\Python31\lib\http\cookiejar.py", line 1541, in _cookies_from_attrs_se
t
    cookie = self._cookie_from_cookie_tuple(tup, request)
  File "C:\Python31\lib\http\cookiejar.py", line 1460, in _cookie_from_cookie_tu
ple
    version = int(version)
ValueError: invalid literal for int() with base 10: '1.0'

  _warn_unhandled_exception()"""

----------
components: Library (Lib)
messages: 107564
nosy: Popa.Claudiu
priority: normal
severity: normal
status: open
title: Bug in cookiejar
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8975>
_______________________________________

From report at bugs.python.org  Fri Jun 11 19:37:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 17:37:58 +0000
Subject: [issue8975] Bug in cookiejar
In-Reply-To: <1276277689.33.0.403419112347.issue8975@psf.upfronthosting.co.za>
Message-ID: <1276277878.31.0.79426359913.issue8975@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your report. Can you copy the code provoking the bug?

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8975>
_______________________________________

From report at bugs.python.org  Fri Jun 11 19:40:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 17:40:04 +0000
Subject: [issue8971] Tkinter Litmus Test
In-Reply-To: <1276241262.66.0.609835750644.issue8971@psf.upfronthosting.co.za>
Message-ID: <1276278004.28.0.591145130761.issue8971@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8971>
_______________________________________

From report at bugs.python.org  Fri Jun 11 19:40:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 17:40:15 +0000
Subject: [issue8971] Tkinter Litmus Test
In-Reply-To: <1276241262.66.0.609835750644.issue8971@psf.upfronthosting.co.za>
Message-ID: <1276278015.92.0.835704581597.issue8971@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8971>
_______________________________________

From report at bugs.python.org  Fri Jun 11 19:40:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 17:40:30 +0000
Subject: [issue8971] Tkinter Litmus Test
In-Reply-To: <1276241262.66.0.609835750644.issue8971@psf.upfronthosting.co.za>
Message-ID: <1276278030.49.0.737115080124.issue8971@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8971>
_______________________________________

From report at bugs.python.org  Fri Jun 11 19:45:38 2010
From: report at bugs.python.org (Popa Claudiu)
Date: Fri, 11 Jun 2010 17:45:38 +0000
Subject: [issue8975] Bug in cookiejar
In-Reply-To: <1276277689.33.0.403419112347.issue8975@psf.upfronthosting.co.za>
Message-ID: <1276278338.95.0.209396558643.issue8975@psf.upfronthosting.co.za>


Popa Claudiu <pcmanticore at gmail.com> added the comment:

"""                CHttp.__init__(self,1,proxy = shared.setts.currentGoogleProxy)
                self.timeout = shared.setts.cGglHttpTimeout

                self.proxy = globShare.currentGoogleProxy[globShare.currentGoogleIndex]
                if self.proxy:
                        proxy_support = urllib.request.ProxyHandler({'http':self.proxy,'https':self.proxy,'ftp':self.proxy})
                else:
                        proxy_support = urllib.request.ProxyHandler({})
                #socket.setdefaulttimeout(30)

                        #self._cp = urllib.request.HTTPCookieProcessor(http.cookiejar.CookieJar())

                self._cj = http.cookiejar.MozillaCookieJar()
                self._opener1 = urllib.request.build_opener(proxy_support,self._cp)
..... openedUrl = self._opener1.open(req)"""

The script was a crawler that searches for pdf's on internet. One thread printed the untreated exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8975>
_______________________________________

From report at bugs.python.org  Fri Jun 11 19:46:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 17:46:58 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1276278418.71.0.417098731777.issue8362@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file16853/maintainers.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Fri Jun 11 19:47:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 17:47:02 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1276278422.41.0.0337279147333.issue8362@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file16854/maintainers.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Fri Jun 11 19:47:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 17:47:12 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1276278432.01.0.582613392394.issue8362@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file17629/maintainers.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Fri Jun 11 19:47:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 17:47:54 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1276278474.16.0.90748594745.issue8362@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file17630/maintainers.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Fri Jun 11 19:48:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 17:48:37 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1276278517.53.0.124896921197.issue8362@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Updating the files. haypo, your move! :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Fri Jun 11 19:51:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 17:51:48 +0000
Subject: [issue8975] Bug in cookiejar
In-Reply-To: <1276278338.95.0.209396558643.issue8975@psf.upfronthosting.co.za>
Message-ID: <4C12778F.20207@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Could you provide a minimal usable script? We can?t run your excerpt to
reproduce the bug, and reproducing is the first step to debugging. I
think we?ll also need the site address, or the cookie header, or the
cookies file that provoke the bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8975>
_______________________________________

From report at bugs.python.org  Fri Jun 11 20:48:50 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 18:48:50 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276282130.79.0.539298542865.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a new patch, issue5094e.diff which addresses most of Mark's comments.  I left out repr() because two opinions were voiced on IRC with respect to datetime. prefix.  I would like to give it some more thought even though I am leaning towards compatibility with existing reprs.

I did not make td argument optional and did not allow timezone o be subclassed because these seem to be mutually exclusive options.  (If td is optional in base class, it must be optional in subclasses per Liskov's principle severely limiting utility of subclasses.)  Let's address this separately.

----------
Added file: http://bugs.python.org/file17631/issue5094e.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Fri Jun 11 21:04:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 19:04:55 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1276283095.76.0.00380027156505.issue6608@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Downgrading further.  If anyone has interest in supplying a patch, please step in.  Otherwise I plan to add a note to documentation and leave the code as is.

----------
priority: critical -> low
title: asctime causing python to crash -> asctime does not check its input
type: crash -> behavior
versions:  -Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Fri Jun 11 21:06:57 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Jun 2010 19:06:57 +0000
Subject: [issue3129] struct allows repeat spec. without a format specifier
In-Reply-To: <1213694469.69.0.0950890622628.issue3129@psf.upfronthosting.co.za>
Message-ID: <1276283217.71.0.467407872612.issue3129@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

On second thoughts, I think I *would* like to see this backported to 2.7.  Not to the maintenance branches, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3129>
_______________________________________

From report at bugs.python.org  Fri Jun 11 21:18:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Jun 2010 19:18:21 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1276283901.23.0.154743513016.issue6608@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm... it's still a crash, though. I really think this should be fixed. Crashing on invalid input is bad.

----------
type: behavior -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Fri Jun 11 21:21:30 2010
From: report at bugs.python.org (Chris Blazick)
Date: Fri, 11 Jun 2010 19:21:30 +0000
Subject: [issue8976] subprocess module causes segmentation fault
In-Reply-To: <1276284090.76.0.563218303469.issue8976@psf.upfronthosting.co.za>
Message-ID: <1276284090.76.0.563218303469.issue8976@psf.upfronthosting.co.za>


New submission from Chris Blazick <blazingvw at gmail.com>:

platform: Linux x86_64 (CentOS)
kernel: 2.6.18-128.1.10.el5.centos.plus
python version: 2.4.3
PyQt versin: 4.7.3

subprocess is generating a segmentation fault.

I am running a proprietary quicktime generating script inside my own (Qt) script using the subprocess module.  I am piping both stdout and stderr into my script.  I have tried reading these two with .communicate() and with the <Popen>.stdout / <Popen>.stderr properties.  Both end up generating the following error:

*** glibc detected *** /usr/bin/python: corrupted double-linked list: 0x00000000161c5c50 ***
Segmentation fault

running my script, and using os.system() to run the proprietary script works just fine

The (C++ compiled) proprietary script does not appear to have any problems crashing under normal circumstances, and I am assuming if there was a problem with the proprietary script, it wouldn't cascade to crashing my own script

----------
components: Extension Modules
messages: 107573
nosy: Chris.Blazick
priority: normal
severity: normal
status: open
title: subprocess module causes segmentation fault
type: crash
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8976>
_______________________________________

From report at bugs.python.org  Fri Jun 11 21:22:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Jun 2010 19:22:43 +0000
Subject: [issue2892] improve cElementTree iterparse error handling
In-Reply-To: <1210940435.5.0.243679200602.issue2892@psf.upfronthosting.co.za>
Message-ID: <1276284163.95.0.153841588884.issue2892@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2892>
_______________________________________

From report at bugs.python.org  Fri Jun 11 21:26:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 19:26:17 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1276284377.4.0.306174837004.issue8362@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I added Misc/maintainers.rst in 2.7 (r81899). But I don't want to maintain it, so merwork, will have to send me your patches ;-)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Fri Jun 11 21:29:44 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Fri, 11 Jun 2010 19:29:44 +0000
Subject: [issue2892] improve cElementTree iterparse error handling
In-Reply-To: <1210940435.5.0.243679200602.issue2892@psf.upfronthosting.co.za>
Message-ID: <1276284584.89.0.612911946282.issue2892@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

Note that this was fixed in upstream 1.3 (and verified by the selftests), but the fix and test was apparently lost when that code was merged into 2.7.  Since 2.7 is supposed to ship with 1.3, this is a regression, not a feature request.

(But 2.7 is in rc, and I'm on vacation, so I guess it's a bit too late to do anything about that.  I'll leave the final decision to flox and the python-dev crowd.)

----------
assignee: effbot -> flox
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2892>
_______________________________________

From report at bugs.python.org  Fri Jun 11 21:29:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 19:29:58 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1276284598.27.0.244141700144.issue8362@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

We?ve agreed on that :) Thanks.

----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Fri Jun 11 21:54:37 2010
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 11 Jun 2010 19:54:37 +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: <1276286077.64.0.282644670725.issue8959@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

The commit that breaks the examples is revision 80761.

Tested on WinXP 32 bit.

Someone should test on Win 64bit too ;-).

----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8959>
_______________________________________

From report at bugs.python.org  Fri Jun 11 22:07:09 2010
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 11 Jun 2010 20:07:09 +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: <1276286829.41.0.301720327444.issue8959@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Problem in py3k branch also.

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8959>
_______________________________________

From report at bugs.python.org  Fri Jun 11 22:12:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 20:12:30 +0000
Subject: [issue8949] PyArg_Parse*(): "z" should not accept bytes
In-Reply-To: <1276032203.54.0.364398342729.issue8949@psf.upfronthosting.co.za>
Message-ID: <1276287150.27.0.398158320639.issue8949@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Some examples of functions using "s" format:
 * str.encode(encoding, errors), bytes.decode(encoding, errors): both arguments have to be unicode strings
 * compile(source, filename, mode, ...): filename and mode have to be unicode strings
 * crypt.crypt(word, salt): both arguments have to be unicode strings

I think that crypt() should also accept bytes, but not str.encode() nor bytes.decode().

Some examples of functions using "z" format:
 * _locale.bindtextdomain(domain, dirname): dirname uses "z" format and so accepts str, bytes or buffer compatible object. It should use PyUnicode_FSConverter() instead. But I agree that bytes is welcomed here.
 * readline.(write_history_file|read_init_file|read_history_file) functions do use "z" to parse a filename. PyUnicode_FSConverter() would also be better, but in this case "z" is better than "s" :-)

I don't know why "s" and "z" are different about bytes, but it will be difficult to change it without changing a lot ot code (all functions using these formats). I tried to reject types different than str for "z": most tests of the test suite fail. I tried to accept bytes for "s" format: "unicode".encode(b'abc') does segfault.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8949>
_______________________________________

From report at bugs.python.org  Fri Jun 11 22:21:55 2010
From: report at bugs.python.org (Bruce Frederiksen)
Date: Fri, 11 Jun 2010 20:21:55 +0000
Subject: [issue8515] idle "Run Module" (F5) does not set __file__ variable
In-Reply-To: <1276269089.89.0.608423270885.issue8515@psf.upfronthosting.co.za>
Message-ID: <AANLkTikb8c9ikffDj59clvwcuP1_V-69Eco8cmWAFezu@mail.gmail.com>


Bruce Frederiksen <dangyogi at gmail.com> added the comment:

No, IDLE compiles the module (with the 'compile' built-in using the 'exec'
option) and then does an 'exec' on the code (in PyShell.py).  It has several
lines of code that it runs before this exec to prepare the environment that
the code is run in.  It appears to be an oversight that the __file__
variable is not being set as a part of this preparation code to match the
behavior of the python CLI.  The patch that I included only changes one line
of this preparation code to also set the __file__ variable and that fixes
the problem.  If you examine the IDLE code in the immediate vicinity of my
patch you will see this.

I have several use cases where I'm relying on the __file__ variable in my
module so that it can find other non .py files that it needs in the same
directory that it's in.  This works under all combinations of uses from the
CLI, but fails in IDLE using Run Module.

The language reference
manual<http://docs.python.org/reference/datamodel.html?highlight=__file__>states
under "Module":

Predefined (writable) attributes: __name__ is the module???s name; __doc__ is
> the module???s documentation string, or None if unavailable; __file__ is the
> pathname of the file from which the module was loaded, if it was loaded from
> a file. The __file__ attribute is not present for C modules that are
> statically linked into the interpreter; for extension modules loaded
> dynamically from a shared library, it is the pathname of the shared library
> file.
>

The python CLI honors this definition in all cases, but IDLE/Run Module does
not.

On Fri, Jun 11, 2010 at 11:11 AM, Tal Einat <report at bugs.python.org> wrote:

>
> Tal Einat <taleinat at users.sourceforge.net> added the comment:
>
> I believe IDLE runs modules via execfile(), so I would expect the behavior
> to be similar, and execfile() does not set __file__. Doing "Run Module" is
> also IMO equivalent to doing execfile(), so this behavior retains
> consistency.
>
> However, I would expect __file__ to be set when running IDLE -r <script>,
> but I get "name '__file__' is not defined" (with Python 2.6.2). This is
> inconsistent and should be fixed.
>
> ----------
> nosy: +taleinat
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8515>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file17632/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8515>
_______________________________________
-------------- next part --------------
No, IDLE compiles the module (with the &#39;compile&#39; built-in using the &#39;exec&#39; option) and then does an &#39;exec&#39; on the code (in PyShell.py).?? It has several lines of code that it runs before this exec to prepare the environment that the code is run in.?? It appears to be an oversight that the __file__ variable is not being set as a part of this preparation code to match the behavior of the python CLI.?? The patch that I included only changes one line of this preparation code to also set the __file__ variable and that fixes the problem.?? If you examine the IDLE code in the immediate vicinity of my patch you will see this.<br>
<br>I have several use cases where I&#39;m relying on the __file__ variable in my module so that it can find other non .py files that it needs in the same directory that it&#39;s in.?? This works under all combinations of uses from the CLI, but fails in IDLE using Run Module.<br>
<br>The <a href="http://docs.python.org/reference/datamodel.html?highlight=__file__">language reference manual</a> states under &quot;Module&quot;:<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
Predefined (writable) attributes: <tt class="xref docutils literal"><span class="pre">__name__</span></tt> is the module???s name;
<tt class="xref docutils literal"><span class="pre">__doc__</span></tt> 
is the module???s documentation string, or <tt class="xref docutils 
literal"><span class="pre">None</span></tt> if
unavailable; <tt class="xref docutils literal"><span class="pre"><span class="highlight">__file__</span></span></tt> is the pathname of the 
file from which the module
was loaded, if it was loaded from a file. The <tt class="xref docutils 
literal"><span class="pre"><span class="highlight">__file__</span></span></tt>
 attribute is not
present for C modules that are statically linked into the interpreter; 
for
extension modules loaded dynamically from a shared library, it is the 
pathname
of the shared library file.<br></blockquote><br>The python CLI honors this definition in all cases, but IDLE/Run Module does not.<br><br><div class="gmail_quote">On Fri, Jun 11, 2010 at 11:11 AM, Tal Einat <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>
Tal Einat &lt;<a href="mailto:taleinat at users.sourceforge.net">taleinat at users.sourceforge.net</a>&gt; added the comment:<br>
<br>
I believe IDLE runs modules via execfile(), so I would expect the behavior to be similar, and execfile() does not set __file__. Doing &quot;Run Module&quot; is also IMO equivalent to doing execfile(), so this behavior retains consistency.<br>

<br>
However, I would expect __file__ to be set when running IDLE -r &lt;script&gt;, but I get &quot;name &#39;__file__&#39; is not defined&quot; (with Python 2.6.2). This is inconsistent and should be fixed.<br>
<br>
----------<br>
nosy: +taleinat<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/issue8515" target="_blank">http://bugs.python.org/issue8515</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Fri Jun 11 22:26:43 2010
From: report at bugs.python.org (Demur Rumed)
Date: Fri, 11 Jun 2010 20:26:43 +0000
Subject: [issue8977] Globalize lonely augmented assignment
In-Reply-To: <1276288000.72.0.276261442461.issue8977@psf.upfronthosting.co.za>
Message-ID: <1276288000.72.0.276261442461.issue8977@psf.upfronthosting.co.za>


New submission from Demur Rumed <junkmute at hotmail.com>:

A=[1,2,3]
def f(x):
    A+=x,

This throws an error. The solution: state "global a". I find it odd that augmented assignment should be viewed the same as assignment in descerning local variables. This patch repairs such to maintain a as a variable of the global namespace

Some might find the following an issue

def f(x):
    if x:
        A+=4,
    else:
        A=[3]
    print("f",x,A)
def g(x):
    if not x:
        A=[3]
    else:
        A+=4,
    print("g",x,A)

In f, A is a global variable. In g, A is a local variable. Thus g(1) throws UnboundLocalError while f(1) appends 4 to A

----------
components: Interpreter Core
files: symtable.diff
keywords: patch
messages: 107581
nosy: serprex
priority: normal
severity: normal
status: open
title: Globalize lonely augmented assignment
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file17633/symtable.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8977>
_______________________________________

From report at bugs.python.org  Fri Jun 11 22:33:05 2010
From: report at bugs.python.org (Demur Rumed)
Date: Fri, 11 Jun 2010 20:33:05 +0000
Subject: [issue8977] Globalize lonely augmented assignment
In-Reply-To: <1276288000.72.0.276261442461.issue8977@psf.upfronthosting.co.za>
Message-ID: <1276288385.47.0.743282437413.issue8977@psf.upfronthosting.co.za>


Demur Rumed <junkmute at hotmail.com> added the comment:

A note on the patch, ste->ste_tmpname... lines, along with changes to Lambda_kind, were not added by me. The additional newlines prior to symtable_visit_stmt's declaration are accidental, apologies. I'll avoid patching a snapshot and then pull the old version from hg after realizing I need the old version to run diff on next time

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8977>
_______________________________________

From report at bugs.python.org  Fri Jun 11 22:33:33 2010
From: report at bugs.python.org (Demur Rumed)
Date: Fri, 11 Jun 2010 20:33:33 +0000
Subject: [issue8977] Globalize lonely augmented assignment
In-Reply-To: <1276288000.72.0.276261442461.issue8977@psf.upfronthosting.co.za>
Message-ID: <1276288413.5.0.762841535404.issue8977@psf.upfronthosting.co.za>


Changes by Demur Rumed <junkmute at hotmail.com>:


----------
type: feature request -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8977>
_______________________________________

From report at bugs.python.org  Fri Jun 11 22:47:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 20:47:21 +0000
Subject: [issue8949] PyArg_Parse*(): "z" should not accept bytes
In-Reply-To: <1276032203.54.0.364398342729.issue8949@psf.upfronthosting.co.za>
Message-ID: <1276289241.72.0.797797970154.issue8949@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I tried to reject types different than str for "z": 
> most tests of the test suite fail

Wait, what? No. I modified the wrong line of code :-) The whole test suite pass without any error if "z" doesn't accept bytes anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8949>
_______________________________________

From report at bugs.python.org  Fri Jun 11 22:59:04 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Jun 2010 20:59:04 +0000
Subject: [issue8977] Globalize lonely augmented assignment
In-Reply-To: <1276288000.72.0.276261442461.issue8977@psf.upfronthosting.co.za>
Message-ID: <1276289944.27.0.0906676597543.issue8977@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This seems evil to me, when you consider the effect of this patch on immutable types:

>>> A = 3
>>> def f():
...     A += 5
... 
>>> f()
>>> A
8

I find the possibility that a function can implicitly (i.e., without any 'global' declarations) mutate my global module constants... disturbing.

Anyway, such a fundamental change would need proper discussion;  the right place for that is the python-ideas mailing list rather than the tracker:

http://mail.python.org/mailman/listinfo/python-ideas

Note also that there's a moratorium on core language changes in effect at the moment, so the earliest this could change is Python 3.3.

I'm going to close this issue for now;  if the idea gets a good reception on python-ideas it can be reopened.

----------
nosy: +mark.dickinson
resolution:  -> rejected
status: open -> closed
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8977>
_______________________________________

From report at bugs.python.org  Fri Jun 11 23:07:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Jun 2010 21:07:08 +0000
Subject: [issue8976] subprocess module causes segmentation fault
In-Reply-To: <1276284090.76.0.563218303469.issue8976@psf.upfronthosting.co.za>
Message-ID: <1276290428.67.0.54778222058.issue8976@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, without a non-proprietary way to reproduce the failure it is going to be a little hard to debug.  You could try debugging it with gdb.

----------
nosy: +r.david.murray
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8976>
_______________________________________

From report at bugs.python.org  Fri Jun 11 23:07:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 21:07:52 +0000
Subject: [issue8515] idle "Run Module" (F5) does not set __file__ variable
In-Reply-To: <1272071890.53.0.295001627395.issue8515@psf.upfronthosting.co.za>
Message-ID: <1276290472.66.0.395614571785.issue8515@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file17632/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8515>
_______________________________________

From report at bugs.python.org  Fri Jun 11 23:48:26 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 11 Jun 2010 21:48:26 +0000
Subject: [issue8977] Globalize lonely augmented assignment
In-Reply-To: <1276288000.72.0.276261442461.issue8977@psf.upfronthosting.co.za>
Message-ID: <1276292906.9.0.814467295116.issue8977@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

It's not that much more evil than this:

A = []

def f(x):
  A.append(x)

print(A)  # []
f(4)
print(A)  # [4]

I've always thought this is a borderline case.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8977>
_______________________________________

From report at bugs.python.org  Fri Jun 11 23:48:53 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 11 Jun 2010 21:48:53 +0000
Subject: [issue8978] "tarfile.ReadError: file could not be opened
	successfully" if compiled without zlib
In-Reply-To: <1276292933.37.0.137444086026.issue8978@psf.upfronthosting.co.za>
Message-ID: <1276292933.37.0.137444086026.issue8978@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

When Python is compiled without zlib support, the error message is not very helpful when trying to untar an archive.

>>> tarfile.open('sample.tar.gz')
tarfile.ReadError: file could not be opened successfully

It happens when you run "python distribute_setup.py", for example.
 ( http://s3.pixane.com/pip_distribute.png )

----------
components: Extension Modules
messages: 107587
nosy: flox
priority: low
severity: normal
status: open
title: "tarfile.ReadError: file could not be opened successfully" if compiled without zlib
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8978>
_______________________________________

From report at bugs.python.org  Fri Jun 11 23:53:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Jun 2010 21:53:08 +0000
Subject: [issue8941] utf-32be codec failing on UCS-2 python build for
	32-bit	value
In-Reply-To: <1276013724.21.0.174818104611.issue8941@psf.upfronthosting.co.za>
Message-ID: <1276293188.0.0.962811970232.issue8941@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r81907 (trunk), r81908 (py3k), r81909 (2.6), r81910 (3.1).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8941>
_______________________________________

From report at bugs.python.org  Fri Jun 11 23:53:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 21:53:17 +0000
Subject: [issue8978] "tarfile.ReadError: file could not be opened
	successfully" if compiled without zlib
In-Reply-To: <1276292933.37.0.137444086026.issue8978@psf.upfronthosting.co.za>
Message-ID: <1276293197.86.0.22207555425.issue8978@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Which message do you suggest?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8978>
_______________________________________

From report at bugs.python.org  Fri Jun 11 23:53:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 21:53:40 +0000
Subject: [issue8966] ctypes: remove implicit conversion between unicode and
	bytes
In-Reply-To: <1276211007.74.0.406425558952.issue8966@psf.upfronthosting.co.za>
Message-ID: <1276293220.83.0.98771297062.issue8966@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited ctypes_s_set.patch in Python 3.2 (r81911) because it does fix a real bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8966>
_______________________________________

From report at bugs.python.org  Fri Jun 11 23:55:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Jun 2010 21:55:23 +0000
Subject: [issue8978] "tarfile.ReadError: file could not be opened
	successfully" if compiled without zlib
In-Reply-To: <1276292933.37.0.137444086026.issue8978@psf.upfronthosting.co.za>
Message-ID: <1276293323.57.0.500912250367.issue8978@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8978>
_______________________________________

From report at bugs.python.org  Fri Jun 11 23:58:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 21:58:36 +0000
Subject: [issue8966] ctypes: remove implicit conversion between unicode and
	bytes
In-Reply-To: <1276211007.74.0.406425558952.issue8966@psf.upfronthosting.co.za>
Message-ID: <1276293516.62.0.481703103585.issue8966@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Update ctypes_tests.patch against last changes: ctypes_tests-2.patch.

----------
Added file: http://bugs.python.org/file17634/ctypes_tests-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8966>
_______________________________________

From report at bugs.python.org  Fri Jun 11 23:58:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 21:58:42 +0000
Subject: [issue8966] ctypes: remove implicit conversion between unicode and
	bytes
In-Reply-To: <1276211007.74.0.406425558952.issue8966@psf.upfronthosting.co.za>
Message-ID: <1276293522.42.0.0301787627346.issue8966@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17613/ctypes_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8966>
_______________________________________

From report at bugs.python.org  Sat Jun 12 00:00:19 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 11 Jun 2010 22:00:19 +0000
Subject: [issue8978] "tarfile.ReadError: file could not be opened
	successfully" if compiled without zlib
In-Reply-To: <1276292933.37.0.137444086026.issue8978@psf.upfronthosting.co.za>
Message-ID: <1276293619.42.0.736180522336.issue8978@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

something like :
  raise CompressionError("zlib module is not available")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8978>
_______________________________________

From report at bugs.python.org  Sat Jun 12 00:03:07 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 11 Jun 2010 22:03:07 +0000
Subject: [issue8978] "tarfile.ReadError: file could not be opened
	successfully" if compiled without zlib
In-Reply-To: <1276292933.37.0.137444086026.issue8978@psf.upfronthosting.co.za>
Message-ID: <1276293787.82.0.800317360491.issue8978@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
components: +Library (Lib) -Extension Modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8978>
_______________________________________

From report at bugs.python.org  Sat Jun 12 00:03:53 2010
From: report at bugs.python.org (Tal Einat)
Date: Fri, 11 Jun 2010 22:03:53 +0000
Subject: [issue8515] idle "Run Module" (F5) does not set __file__ variable
In-Reply-To: <1272071890.53.0.295001627395.issue8515@psf.upfronthosting.co.za>
Message-ID: <1276293833.09.0.546023506283.issue8515@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

Why doesn't execfile() set __file__? I would be surprised if this is due to an oversight by the Python devs. In both execfile and IDLE's "Run Module" I can't think of a reason not to set __file__, but perhaps this was intentional? Googling a bit hasn't brought up much.

I am currently of the opinion that both IDLE and execfile() should set __file__ (with execfile() perhaps requiring more thinking about edge-cases, since it can be passes locals and globals dictionaries).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8515>
_______________________________________

From report at bugs.python.org  Sat Jun 12 00:08:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Jun 2010 22:08:36 +0000
Subject: [issue8977] Globalize lonely augmented assignment
In-Reply-To: <1276288000.72.0.276261442461.issue8977@psf.upfronthosting.co.za>
Message-ID: <1276294116.97.0.472977888645.issue8977@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

True.  I guess there's a mismatch either way around:  currently,
"A += [4]" and "A.append(4)" behave differently for (e.g.,) a list A.  With the proposed change, "n += 3" and "n = n + 3" behave differently for a integer n.  I'm not sure why I find the latter idea more disturbing than the former.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8977>
_______________________________________

From report at bugs.python.org  Sat Jun 12 00:19:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 22:19:08 +0000
Subject: [issue8965] test_imp fails on OSX when LANG is set
In-Reply-To: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>
Message-ID: <1276294748.74.0.566886485151.issue8965@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited issue8965-test-1.diff (r81916) with a minor changes: .strip() => .rstrip() and use @unittest.skipUnless().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8965>
_______________________________________

From report at bugs.python.org  Sat Jun 12 00:35:26 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 11 Jun 2010 22:35:26 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1276295726.46.0.326715688596.issue6608@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

How about checking the preconditions before calling asctime()? If the check fails, then we can raise an exception without crashing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Sat Jun 12 00:55:28 2010
From: report at bugs.python.org (jhg)
Date: Fri, 11 Jun 2010 22:55:28 +0000
Subject: [issue8502] proposal: encourage xgettext rather than pygettext.py in
	gettext docs
In-Reply-To: <1271985007.3.0.675755685137.issue8502@psf.upfronthosting.co.za>
Message-ID: <1276296928.45.0.242599865348.issue8502@psf.upfronthosting.co.za>


jhg <jhg at upb.de> added the comment:

It looks like msgfmt.py now parses 'msgid_plural' but pygettext.py does not produce these. It is still oblivious to plurals as produced by ngettext(). My originally proposed change to the documentation was to point people to the GNU xgettext/msgfmt tools rather than the pygettext.py/msgfmt.py pair because of this limitation.

This has not changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8502>
_______________________________________

From report at bugs.python.org  Sat Jun 12 00:57:45 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 11 Jun 2010 22:57:45 +0000
Subject: [issue8924] Error in error message in logging
In-Reply-To: <1275850912.41.0.0811394159532.issue8924@psf.upfronthosting.co.za>
Message-ID: <1276297065.08.0.0444560200947.issue8924@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into trunk and release26-maint.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8924>
_______________________________________

From report at bugs.python.org  Sat Jun 12 00:57:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 22:57:51 +0000
Subject: [issue8502] proposal: encourage xgettext rather than pygettext.py in
	gettext docs
In-Reply-To: <1271985007.3.0.675755685137.issue8502@psf.upfronthosting.co.za>
Message-ID: <1276297071.38.0.853943988072.issue8502@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

What about the more ambitious approach, fixing pygettext?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8502>
_______________________________________

From report at bugs.python.org  Sat Jun 12 01:00:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 23:00:12 +0000
Subject: [issue8949] PyArg_Parse*(): "z" should not accept bytes
In-Reply-To: <1276032203.54.0.364398342729.issue8949@psf.upfronthosting.co.za>
Message-ID: <1276297212.27.0.561445333922.issue8949@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I patched readline (r81918) and locale (r81914) modules to use PyUnicode_FSConverter(). They don't use "z" format anymore to parse a filename.

I checked last functions using "z" format (not "z#" or "z*", only "z") and I think that it's ok ("z" can be patched to reject bytes). You can get the full list using:

grep -n 'PyArg_Parse[^(]*([^"]*"[^";:]*z[^#*]' */*.c

--

About the difference between s/z and s*/s#/z*/z#: I don't understand why they are different, but I think that it's too late to change that. Too much functions (and third party modules?) suppose that s*/s#/z*/z# supports buffer compatible objects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8949>
_______________________________________

From report at bugs.python.org  Sat Jun 12 01:00:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 23:00:51 +0000
Subject: [issue8924] Error in error message in logging
In-Reply-To: <1275850912.41.0.0811394159532.issue8924@psf.upfronthosting.co.za>
Message-ID: <1276297251.2.0.239022494699.issue8924@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Suggestion: To help people involved in the discussion or landing here from a Web search, you can write ?fixed in rNNN? to make Roundup produce a link link this one: r81919 Thanks!

----------
nosy: +merwok
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8924>
_______________________________________

From report at bugs.python.org  Sat Jun 12 01:06:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 23:06:50 +0000
Subject: [issue8965] test_imp fails on OSX when LANG is set
In-Reply-To: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>
Message-ID: <1276297610.96.0.92005421833.issue8965@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

One more patch to check sys.getfilesystemencoding() on any OS (r81920).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8965>
_______________________________________

From report at bugs.python.org  Sat Jun 12 01:07:13 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 11 Jun 2010 23:07:13 +0000
Subject: [issue8977] Globalize lonely augmented assignment
In-Reply-To: <1276288000.72.0.276261442461.issue8977@psf.upfronthosting.co.za>
Message-ID: <1276297633.53.0.611672338863.issue8977@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Because the latter (n += 1) is more fundamental, since it uses integers (arguably the most fundamental type).

This is why we've never done it before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8977>
_______________________________________

From report at bugs.python.org  Sat Jun 12 01:12:50 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 11 Jun 2010 23:12:50 +0000
Subject: [issue8976] subprocess module causes segmentation fault
In-Reply-To: <1276284090.76.0.563218303469.issue8976@psf.upfronthosting.co.za>
Message-ID: <1276297970.1.0.386787104585.issue8976@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

> python version: 2.4.3

I'd suggest to try this with Python 2.6 or later. 2.4 and 2.5 are in
security-fix only mode.

----------
nosy: +skrah
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8976>
_______________________________________

From report at bugs.python.org  Sat Jun 12 01:13:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 23:13:20 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1276298000.34.0.636996134337.issue6608@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

That's what CERT recommends.  Their code can be reused as is:

int validate_tm(struct tm* time) {
  /* 
   * The range of valid values of the tm_sec member is [0, 60] 
   * inclusive (to allow for leap seconds).
   */
  if (time->tm_sec < 0 || time->tm_sec > 60) return 0;
  if (time->tm_min < 0 || time->tm_min >= 60) return 0;
  if (time->tm_hour < 0 || time->tm_hour >= 24) return 0;
  if (time->tm_mday <= 0 || time->tm_mday > 31) return 0;
  if (time->tm_mon < 0 || time->tm_mon >= 12) return 0;
  /* While other years are legit, they may overflow asctime()'s buffer */
  if (time->tm_year < -999 || time->tm_year > 9999) return 0;
  if (time->tm_wday < 0 || time->tm_wday >= 7) return 0;
  if (time->tm_yday < 0 || time->tm_yday >= 366) return 0;
  return 1;
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Sat Jun 12 01:16:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 23:16:01 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1276298161.09.0.188929645863.issue6608@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/issue6608>
_______________________________________

From report at bugs.python.org  Sat Jun 12 01:34:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 23:34:35 +0000
Subject: [issue8939] Use C type names (PyUnicode etc;) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276299275.01.0.86341177596.issue8939@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited a first part of the patch: r81923 (3.2), r81924 (3.1).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8939>
_______________________________________

From report at bugs.python.org  Sat Jun 12 01:37:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 23:37:51 +0000
Subject: [issue8939] Use C type names (PyUnicode etc;) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276299471.66.0.980607607084.issue8939@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"PyUnicodeObject*" is not the best choice for the description of the function, and I don't really like "PyUnicode". Can't we use C types in the function prototype and Python types in the description?

Example:
-------
s (PyUnicodeObject* or None) [char *]
Convert a null-terminated C string to a Python unicode object using 'utf-8' encoding. If the C string pointer is NULL, None is used.
-----
PyUnicodeObject will be a link to the C type, and unicode a link to the  Python type.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8939>
_______________________________________

From report at bugs.python.org  Sat Jun 12 01:39:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 23:39:25 +0000
Subject: [issue8951] PyArg_Parse*(): factorize code of 's' and 'z' formats,
	and 'u' and 'Z' formats
In-Reply-To: <1276035065.31.0.617634960026.issue8951@psf.upfronthosting.co.za>
Message-ID: <1276299565.98.0.356232467772.issue8951@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +PyArg_Parse*(): "z" should not accept bytes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8951>
_______________________________________

From report at bugs.python.org  Sat Jun 12 01:49:01 2010
From: report at bugs.python.org (akira)
Date: Fri, 11 Jun 2010 23:49:01 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276300141.88.0.0104010680902.issue5094@psf.upfronthosting.co.za>


akira <4kir4.1i at gmail.com> added the comment:

Minor notes:

msg107186:
   1. The constructor now accepts only whole number of minutes in [-23:59, 23:59] range.

rfc 3339 provides the following example:

   1937-01-01T12:00:27.87+00:20

   This represents the same instant of time as noon, January 1, 1937,
   Netherlands time.  Standard time in the Netherlands was exactly 19
   minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through
   1937-06-30.  This time zone cannot be represented exactly using the
   HH:MM format, and this timestamp uses the closest representable UTC
   offset.

The presence of fractions of seconds in time zone is an exception so
it might not be worth to support it but it exists.


msg107552:
   Similarly, should str(timezone.utc) be '+0000' or 'UTC' or '+00:00'?

Excerpts in favor for '+00:00' from rfc 3339:

   Attempts to label local offsets with alphabetic
   strings have resulted in poor interoperability in the past [IMAIL],
   [HOST-REQ].  As a result, RFC2822 [IMAIL-UPDATE] has made numeric
   offsets mandatory.

   If the time in UTC is known, but the offset to local time is unknown,
   this can be represented with an offset of "-00:00".  This differs
   semantically from an offset of "Z" or "+00:00", which imply that UTC
   is the preferred reference point for the specified time.

----------
nosy: +akira

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Sat Jun 12 01:49:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 23:49:40 +0000
Subject: [issue8784] tarfile/Windows: Don't use mbcs as the default encoding
In-Reply-To: <1274491335.43.0.732437213128.issue8784@psf.upfronthosting.co.za>
Message-ID: <1276300180.86.0.0641397892599.issue8784@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ok. I commited the patch to set the default encoding to utf-8 on Windows: r81925.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8784>
_______________________________________

From report at bugs.python.org  Sat Jun 12 01:49:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 23:49:47 +0000
Subject: [issue8784] tarfile/Windows: Don't use mbcs as the default encoding
In-Reply-To: <1274491335.43.0.732437213128.issue8784@psf.upfronthosting.co.za>
Message-ID: <1276300187.82.0.598413946434.issue8784@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/issue8784>
_______________________________________

From report at bugs.python.org  Sat Jun 12 01:57:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 23:57:27 +0000
Subject: [issue8969] Windows: use (mbcs in) strict mode to encode/decode
	filenames, and enable os.fsencode()
In-Reply-To: <1276216388.28.0.366593840574.issue8969@psf.upfronthosting.co.za>
Message-ID: <1276300647.86.0.466685147938.issue8969@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch commited as r81927 (3.2).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8969>
_______________________________________

From report at bugs.python.org  Sat Jun 12 02:02:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 12 Jun 2010 00:02:00 +0000
Subject: [issue850997] mbcs encoding ignores errors
Message-ID: <1276300920.01.0.0622409400114.issue850997@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Tim: are you interested in testing this patch?

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue850997>
_______________________________________

From report at bugs.python.org  Sat Jun 12 02:06:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 12 Jun 2010 00:06:54 +0000
Subject: [issue850997] mbcs encoding ignores errors
Message-ID: <1276301214.61.0.814580789369.issue850997@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Update the patch (I commited the patch on tarfile module): version 3.

----------
Added file: http://bugs.python.org/file17635/mbcs_errors-py3k-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue850997>
_______________________________________

From report at bugs.python.org  Sat Jun 12 02:07:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 12 Jun 2010 00:07:02 +0000
Subject: [issue850997] mbcs encoding ignores errors
Message-ID: <1276301222.85.0.368480329405.issue850997@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17456/mbcs_errors-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue850997>
_______________________________________

From report at bugs.python.org  Sat Jun 12 02:07:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 12 Jun 2010 00:07:08 +0000
Subject: [issue850997] mbcs encoding ignores errors
Message-ID: <1276301228.55.0.557258896296.issue850997@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17622/mbcs_errors-py3k-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue850997>
_______________________________________

From report at bugs.python.org  Sat Jun 12 02:18:40 2010
From: report at bugs.python.org (Michael Curran)
Date: Sat, 12 Jun 2010 00:18:40 +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: <1276301920.96.0.478273541189.issue8959@psf.upfronthosting.co.za>


Michael Curran <mick at nvaccess.org> added the comment:

Tested on Windows 7 x64, with Python 2.7 rc1 [amd64]: both examples work fine.
So it seems the issue is specific to x86.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8959>
_______________________________________

From report at bugs.python.org  Sat Jun 12 02:20:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 12 Jun 2010 00:20:21 +0000
Subject: [issue7739] time.strftime may hung while trying to open
	/etc/localtime but does not release GIL
In-Reply-To: <1263893036.59.0.158350465414.issue7739@psf.upfronthosting.co.za>
Message-ID: <1276302021.71.0.813470708645.issue7739@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I understand your last comment as wanting to keep the GIL while calling
> tzset(), but release it around the strftime() call.

Yes

> You still want to apply your patch, right?

http://sourceware.org/bugzilla/show_bug.cgi?id=4350 describes a crash. This issue is not a crash but a concurrency problem. I don't know if my patch fixes the initial problem: dorontal didn't try it and he doesn't explain us how to reproduce it.

I also not sure that releasing the GIL may not introduce a new concurrency issue: it might crash if a thread calls strftime() and another thread calls setenv("TZ", "...") (if I understood correctly the GNU libc bug 4350).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7739>
_______________________________________

From report at bugs.python.org  Sat Jun 12 02:22:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 12 Jun 2010 00:22:41 +0000
Subject: [issue5115] Extend subprocess.kill to be able to kill process groups
In-Reply-To: <1233370260.58.0.70597374825.issue5115@psf.upfronthosting.co.za>
Message-ID: <1276302161.52.0.353534808856.issue5115@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

erickt: can you fix your patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5115>
_______________________________________

From report at bugs.python.org  Sat Jun 12 02:39:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 12 Jun 2010 00:39:01 +0000
Subject: [issue8592] 'y' does not check for embedded NUL bytes
In-Reply-To: <1272737075.21.0.258918022173.issue8592@psf.upfronthosting.co.za>
Message-ID: <1276303141.02.0.386087862076.issue8592@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Attached patch fixes the initial problem: raise an error if the byte strings embeds a NUL-byte.

----------
keywords: +patch
Added file: http://bugs.python.org/file17636/y_format.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8592>
_______________________________________

From report at bugs.python.org  Sat Jun 12 02:43:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 12 Jun 2010 00:43:21 +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: <1276303401.26.0.924008182777.issue8845@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Reopen the issue: the test fails on Sparc.

http://www.python.org/dev/buildbot/builders/sparc%20Ubuntu%203.x/builds/222

======================================================================
FAIL: CheckInTransaction (sqlite3.test.dbapi.ConnectionTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/3.x.klose-ubuntu-sparc/build/Lib/sqlite3/test/dbapi.py", line 152, in CheckInTransaction
    self.assertEqual(cx.in_transaction, True)
AssertionError: False != True

----------
nosy: +haypo
resolution: accepted -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Sat Jun 12 02:49:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 12 Jun 2010 00:49:44 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1276303784.16.0.106495165225.issue8142@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Reopen the issue: libffi compilation fails on "x86 FreeBSD 3.x" buildbot.

http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%203.x/builds/349/steps/compile/logs/stdio

gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.2-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.2-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -IInclude -I./Include -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I. -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/sysv.S -o build/temp.freebsd-6.4-RELEASE-i386-3.2-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/sysv.o
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/sysv.S: Assembler messages:
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/sysv.S:360: Error: junk at end of line, first unrecognized character is `@'
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/sysv.S:387: Error: junk at end of line, first unrecognized character is `@'
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/sysv.S:423: Error: junk at end of line, first unrecognized character is `@'

----------
nosy: +haypo
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Sat Jun 12 02:51:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 12 Jun 2010 00:51:47 +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: <1276303907.48.0.170249893908.issue8845@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Same error on builder "PPC Leopard 3.x".

http://www.python.org/dev/buildbot/builders/PPC%20Leopard%203.x/builds/87/steps/test/logs/stdio

test_sqlite
test test_sqlite failed -- Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/sqlite3/test/dbapi.py", line 152, in CheckInTransaction
    self.assertEqual(cx.in_transaction, True)
AssertionError: False != True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Sat Jun 12 03:04:24 2010
From: report at bugs.python.org (Bryan Ward)
Date: Sat, 12 Jun 2010 01:04:24 +0000
Subject: [issue8979] OptParse __getitem__
In-Reply-To: <1276304664.09.0.271886619191.issue8979@psf.upfronthosting.co.za>
Message-ID: <1276304664.09.0.271886619191.issue8979@psf.upfronthosting.co.za>


New submission from Bryan Ward <bward1 at gmail.com>:

It would be convenient to be able to access the resultant options from optparse using the syntax

options['some_option']

instead of options.some_option

Or additionally it would be nice to have a way to produce a dictionary of the options.  This would be nice to have to do something to the effect of

dictOptions = options.to_dict()

obj = SomeObject(**dictOptions)

----------
components: Extension Modules
messages: 107620
nosy: bcward
priority: normal
severity: normal
status: open
title: OptParse __getitem__
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8979>
_______________________________________

From report at bugs.python.org  Sat Jun 12 03:45:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 01:45:23 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1276307123.03.0.617119936851.issue5845@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Sat Jun 12 04:00:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 02:00:02 +0000
Subject: =?utf-8?b?W2lzc3VlODg4N10g4oCccHlkb2Mgc3Ry4oCdIHdvcmtzIGJ1dCBub3Qg4oCc?=
	=?utf-8?q?pydoc_str=2Etranslate=E2=80=9D?=
In-Reply-To: <1275565374.87.0.956319261544.issue8887@psf.upfronthosting.co.za>
Message-ID: <1276308002.76.0.301961254786.issue8887@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Note that

>>> help(str.translate)
Help on method_descriptor:

translate(...)
    S.translate(table) -> str
    
    Return a copy of the string S, where all characters have been mapped
..

but
>>> help('str.translate')
no Python documentation found for 'str.translate'

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8887>
_______________________________________

From report at bugs.python.org  Sat Jun 12 04:44:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 02:44:13 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276310653.64.0.651030561418.issue8912@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Sat Jun 12 05:24:52 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 03:24:52 +0000
Subject: [issue8947] Provide  as_integer_ratio() method to Decimal
In-Reply-To: <1276030268.17.0.98739433208.issue8947@psf.upfronthosting.co.za>
Message-ID: <1276313092.61.0.614862569214.issue8947@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Nice implementation.  I wonder if the /5 loop can be eliminated by noting that /5 is *2 followed by decimal shift. (Probably not without fast decimal arithmetics.)

A few documentation nits:

1. In Decimal methods there is no consistency in referring to self.  I see  "given Decimal", "the number", and "the argument" in three entries around as_integer_ratio().

2. Is there a reason that docstring is more detailed than manual entry?  I think the manual should describe exceptions.

3. Is there a reason to use different language for float.as_integer_ratio() and Decimal.as_integer_ratio()?

I know, ""A foolish consistency is the hobgoblin of little minds..." - feel free to ignore my observations.

A tiny code nit: to me it would be clearer to start with d2 = d5 = -self._exp after the "# Find d2, d5 ..." comment.  For a moment I was puzzled why you promise d2 and d5, but then process d5 only.

Also, by the time of the "if not self" check, special case has been eliminated, so you can simply check self._int == 0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8947>
_______________________________________

From report at bugs.python.org  Sat Jun 12 05:31:28 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 12 Jun 2010 03:31:28 +0000
Subject: [issue8980] distutils.tests.test_register.RegisterTestCase.test_strict
	fails
In-Reply-To: <1276313488.44.0.388606421429.issue8980@psf.upfronthosting.co.za>
Message-ID: <1276313488.44.0.388606421429.issue8980@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

$ python3.2 -m distutils.tests.test_register
.......E
======================================================================
ERROR: test_strict (__main__.RegisterTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.2/distutils/tests/test_register.py", line 227, in test_strict
    inputs = RawInputs('1', 'tarek', 'y')
NameError: global name 'RawInputs' is not defined

----------------------------------------------------------------------
Ran 8 tests in 0.242s

FAILED (errors=1)

After replacing RawInputs with Inputs:
$ python3.2 -m distutils.tests.test_register
.......E
======================================================================
ERROR: test_strict (__main__.RegisterTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.2/distutils/tests/test_register.py", line 231, in test_strict
    cmd.run()
  File "/usr/lib64/python3.2/distutils/command/register.py", line 53, in run
    self.run_command(cmd_name)
  File "/usr/lib64/python3.2/distutils/cmd.py", line 315, in run_command
    self.distribution.run_command(command)
  File "/usr/lib64/python3.2/distutils/dist.py", line 965, in run_command
    cmd_obj.run()
  File "/usr/lib64/python3.2/distutils/command/check.py", line 72, in run
    raise DistutilsSetupError('The docutils package is needed.')
distutils.errors.DistutilsSetupError: The docutils package is needed.

----------------------------------------------------------------------
Ran 8 tests in 0.245s

FAILED (errors=1)

After fixing import, the test interactively asks for username.

----------
assignee: tarek
components: Distutils, Tests
files: distutils.patch
keywords: patch
messages: 107623
nosy: Arfrever, tarek
priority: normal
severity: normal
status: open
title: distutils.tests.test_register.RegisterTestCase.test_strict fails
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17637/distutils.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8980>
_______________________________________

From report at bugs.python.org  Sat Jun 12 05:37:19 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 12 Jun 2010 03:37:19 +0000
Subject: [issue8980] distutils.tests.test_register.RegisterTestCase.test_strict
	fails
In-Reply-To: <1276313488.44.0.388606421429.issue8980@psf.upfronthosting.co.za>
Message-ID: <1276313839.95.0.848451609046.issue8980@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I noticed that register_module.raw_input also should be renamed to register_module.input. The test passes with the new patch.

----------
Added file: http://bugs.python.org/file17638/distutils.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8980>
_______________________________________

From report at bugs.python.org  Sat Jun 12 05:37:43 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 12 Jun 2010 03:37:43 +0000
Subject: [issue8980] distutils.tests.test_register.RegisterTestCase.test_strict
	fails
In-Reply-To: <1276313488.44.0.388606421429.issue8980@psf.upfronthosting.co.za>
Message-ID: <1276313863.76.0.582103592125.issue8980@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Removed file: http://bugs.python.org/file17637/distutils.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8980>
_______________________________________

From report at bugs.python.org  Sat Jun 12 06:21:48 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 12 Jun 2010 04:21:48 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1276316508.41.0.765476251548.issue8142@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
nosy:  -ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Sat Jun 12 06:26:52 2010
From: report at bugs.python.org (jhg)
Date: Sat, 12 Jun 2010 04:26:52 +0000
Subject: [issue8502] proposal: encourage xgettext rather than pygettext.py in
	gettext docs
In-Reply-To: <1271985007.3.0.675755685137.issue8502@psf.upfronthosting.co.za>
Message-ID: <1276316812.21.0.999944929026.issue8502@psf.upfronthosting.co.za>


jhg <jhg at upb.de> added the comment:

Since the GNU tools work fine I had no reason to look into pygettext.py.
Now I did it anyway...

I added ngettext to the default keywords.
Any function that is keyworded and supplied more than 2 keywords is treated like ngettext.
Also simple constructs like _("foo" + 10*"bar") are now possible.

Patch attached.

----------
Added file: http://bugs.python.org/file17639/pygettext.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8502>
_______________________________________

From report at bugs.python.org  Sat Jun 12 06:32:50 2010
From: report at bugs.python.org (jhg)
Date: Sat, 12 Jun 2010 04:32:50 +0000
Subject: [issue8502] proposal: encourage xgettext rather than pygettext.py in
	gettext docs
In-Reply-To: <1271985007.3.0.675755685137.issue8502@psf.upfronthosting.co.za>
Message-ID: <1276317170.16.0.741400250056.issue8502@psf.upfronthosting.co.za>


jhg <jhg at upb.de> added the comment:

A simple test case for the earlier changes.

run pygettext.py and msgfmt.py and move the .mo file to 
./locale/de/LC_MESSAGES/helloworld.mo 
to see that it prints the localized strings.

----------
Added file: http://bugs.python.org/file17640/helloworld.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8502>
_______________________________________

From report at bugs.python.org  Sat Jun 12 06:48:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 04:48:48 +0000
Subject: [issue8981] _struct.__version__ should be string, not bytes
In-Reply-To: <1276318126.69.0.859042236864.issue8981@psf.upfronthosting.co.za>
Message-ID: <1276318126.69.0.859042236864.issue8981@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

>>> import _struct
>>> _struct.__version__
b'0.3'

I would rather simply remove this since it is no longer exposed in struct.

Yes, it does cause problems in real life code: I have applications that keep track of versions of modules that they use and expect __version__ to be string if defined.

Same problem in _curses, but I have never used that module - just grepped the sources.

----------
components: Extension Modules
keywords: easy
messages: 107627
nosy: belopolsky, mark.dickinson
priority: normal
severity: normal
status: open
title: _struct.__version__ should be string, not bytes
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8981>
_______________________________________

From report at bugs.python.org  Sat Jun 12 07:08:01 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 05:08:01 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276319281.99.0.591539527794.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

There is a separate issue #5288 asking to support sub-minute offsets.  This is not hard, but the C code still has a few interfaces left from the time when offset was an integer # of minutes.  I am +1 to fix that, but not as a part of this issue.

On str(tz), I definitely want an invariant str(tz) == tz.tzname(None).  I am open to changes to tzname(), but we are very close to bikesheding here.  Let's settle for 'UTC?HH:MM'.  This seems to be the most common spelling for numeric timezones in various tables on the web.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Sat Jun 12 07:31:03 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Sat, 12 Jun 2010 05:31:03 +0000
Subject: [issue8968] token type constants are not documented
In-Reply-To: <1276216063.7.0.11813766705.issue8968@psf.upfronthosting.co.za>
Message-ID: <1276320663.65.0.674162619023.issue8968@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

I'm attaching a documentation patch.

Do note that there is also a bit of code-level inconsistency: a few tokens (COMMENT, NL) are defined in tokenize module which is strange and inconvenient.

Should that be fixed too? (by moving token definitions into token module)

----------
keywords: +patch
Added file: http://bugs.python.org/file17641/token.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8968>
_______________________________________

From report at bugs.python.org  Sat Jun 12 08:04:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 06:04:47 +0000
Subject: [issue5907] repr of time.struct_time type does not eval
In-Reply-To: <1241281843.36.0.110450032545.issue5907@psf.upfronthosting.co.za>
Message-ID: <1276322687.32.0.771110009145.issue5907@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy: +belopolsky
versions: +Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5907>
_______________________________________

From report at bugs.python.org  Sat Jun 12 08:05:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 06:05:57 +0000
Subject: [issue4086] support %z format in time.strftime and _strptime?
In-Reply-To: <1223551646.15.0.164355592546.issue4086@psf.upfronthosting.co.za>
Message-ID: <1276322757.37.0.989466725745.issue4086@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
dependencies: +No obvious and correct way to get the time zone offset
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4086>
_______________________________________

From report at bugs.python.org  Sat Jun 12 08:11:24 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 06:11:24 +0000
Subject: [issue1520662] support all of strftime(3)
Message-ID: <1276323084.88.0.170411919604.issue1520662@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file13373/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1520662>
_______________________________________

From report at bugs.python.org  Sat Jun 12 08:26:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 06:26:29 +0000
Subject: [issue5207] extend strftime/strptime format for RFC3339 and RFC2822
In-Reply-To: <1234285622.79.0.0309055191852.issue5207@psf.upfronthosting.co.za>
Message-ID: <1276323989.08.0.971226466731.issue5207@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

%O is used by POSIX spec to indicate alternative locale format.

Gnu date uses %:z 

       %:z    +hh:mm numeric timezone (e.g., -04:00)

	      %::z +hh:mm:ss numeric time zone (e.g., -04:00:00) %:::z numeric
	      time  zone  with : to necessary precision (e.g., -04, +05:30)

----------
assignee:  -> belopolsky
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5207>
_______________________________________

From report at bugs.python.org  Sat Jun 12 08:37:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 06:37:14 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1276324634.3.0.258189643055.issue6280@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Mark, reassigning this to you for commit review.

----------
assignee: belopolsky -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Sat Jun 12 08:38:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Jun 2010 06:38:48 +0000
Subject: [issue8968] token type constants are not documented
In-Reply-To: <1276216063.7.0.11813766705.issue8968@psf.upfronthosting.co.za>
Message-ID: <1276324728.98.0.515941323591.issue8968@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Five comments:

* I would list them all in one directive, like this:

.. data:: FOO
          BAR
          BAZ

  which makes the display more compact.

* There is no description in that directive.  Best move part of the
  description above them in it.

* NL and COMMENT are defined in tokenize because they are neither 
  defined nor used by the Python tokenizer.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8968>
_______________________________________

From report at bugs.python.org  Sat Jun 12 08:39:22 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Jun 2010 06:39:22 +0000
Subject: [issue8904] quick example how to fix docs
In-Reply-To: <1275733848.36.0.713191812865.issue8904@psf.upfronthosting.co.za>
Message-ID: <1276324762.88.0.077563515253.issue8904@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Hmm, I thought the Doc/README covered this?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8904>
_______________________________________

From report at bugs.python.org  Sat Jun 12 08:45:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 06:45:02 +0000
Subject: [issue7463] PyDateTime_IMPORT() causes compiler warnings
In-Reply-To: <1260352911.97.0.550126067946.issue7463@psf.upfronthosting.co.za>
Message-ID: <1276325102.8.0.35000171629.issue7463@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7463>
_______________________________________

From report at bugs.python.org  Sat Jun 12 08:46:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Jun 2010 06:46:48 +0000
Subject: [issue8960] 2.6 README
In-Reply-To: <1276174173.81.0.364137552022.issue8960@psf.upfronthosting.co.za>
Message-ID: <1276325208.53.0.795811003538.issue8960@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in 2.7 r81933, 2.6 r81934.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8960>
_______________________________________

From report at bugs.python.org  Sat Jun 12 10:38:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 08:38:49 +0000
Subject: [issue8979] OptParse __getitem__
In-Reply-To: <1276304664.09.0.271886619191.issue8979@psf.upfronthosting.co.za>
Message-ID: <1276331929.28.0.505693127586.issue8979@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your report and your ideas for Python :)
Some remarks:

1) New features have to target 3.2;  2.6 is the current stable version (only security and documentation fixes) and 2.7 is to be released really soon (end of the 2.x line);

2) Can you explain why options['thing'] would be more convenient than options.thing?

3) You can get a dict today with vars(options). (By the way, please open two reports for two requests in the futures.)

4) optparse is superseded by argparse, I don?t know if new features will be added to optparse.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8979>
_______________________________________

From report at bugs.python.org  Sat Jun 12 11:09:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 09:09:23 +0000
Subject: [issue8980] distutils.tests.test_register.RegisterTestCase.test_strict
	fails
In-Reply-To: <1276313488.44.0.388606421429.issue8980@psf.upfronthosting.co.za>
Message-ID: <1276333763.11.0.28692673501.issue8980@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I can?t reproduce with current svn checkout.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8980>
_______________________________________

From report at bugs.python.org  Sat Jun 12 11:24:23 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 09:24:23 +0000
Subject: [issue8981] _struct.__version__ should be string, not bytes
In-Reply-To: <1276318126.69.0.859042236864.issue8981@psf.upfronthosting.co.za>
Message-ID: <1276334663.58.0.129213387517.issue8981@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, I agree that _struct.__version__ can die.  Removed in r81937.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8981>
_______________________________________

From report at bugs.python.org  Sat Jun 12 11:27:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 09:27:13 +0000
Subject: [issue1492704] distinct error type from shutil.move()
Message-ID: <1276334833.58.0.163485731144.issue1492704@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: anthonybaxter -> tarek
nosy: +merwok, tarek
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Sat Jun 12 11:31:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 09:31:01 +0000
Subject: [issue1076515] shutil.move clobbers read-only files.
Message-ID: <1276335061.0.0.689306768972.issue1076515@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is this bug still relevant?

----------
assignee:  -> tarek
nosy: +merwok, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1076515>
_______________________________________

From report at bugs.python.org  Sat Jun 12 11:32:15 2010
From: report at bugs.python.org (Tal Einat)
Date: Sat, 12 Jun 2010 09:32:15 +0000
Subject: [issue8904] quick example how to fix docs
In-Reply-To: <1275733848.36.0.713191812865.issue8904@psf.upfronthosting.co.za>
Message-ID: <1276335135.43.0.330341078032.issue8904@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

Apparently so. Those instructions are thorough and to the point, just what I was looking for.

Adding a mention of this somewhere obvious, such as the links I mentioned earlier, would be very helpful (this would have save me 30 minutes of futile searching).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8904>
_______________________________________

From report at bugs.python.org  Sat Jun 12 11:34:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 09:34:32 +0000
Subject: [issue3129] struct allows repeat spec. without a format specifier
In-Reply-To: <1213694469.69.0.0950890622628.issue3129@psf.upfronthosting.co.za>
Message-ID: <1276335272.68.0.0327184392137.issue3129@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

py3k patch committed (by Alexander) in r81895.  Closing this;  I would ideally like to see this change go into trunk too, but it's not essential and we're too close to the 2.7 release.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3129>
_______________________________________

From report at bugs.python.org  Sat Jun 12 11:43:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 09:43:10 +0000
Subject: [issue2236] Distutils' mkpath implementation ignoring the "mode"
	parameter
In-Reply-To: <1204664208.81.0.312695054648.issue2236@psf.upfronthosting.co.za>
Message-ID: <1276335790.82.0.399734211961.issue2236@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Confirmed in trunk (2.7rc2), py3k (3.2), irrelevant for distutils2. Is it too late for 2.7?

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2236>
_______________________________________

From report at bugs.python.org  Sat Jun 12 11:47:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Jun 2010 09:47:25 +0000
Subject: [issue8904] quick example how to fix docs
In-Reply-To: <1275733848.36.0.713191812865.issue8904@psf.upfronthosting.co.za>
Message-ID: <1276336045.92.0.824171376242.issue8904@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Agreed.  Added a "building" section to Documenting Python in r81393, will port to the other branches.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8904>
_______________________________________

From report at bugs.python.org  Sat Jun 12 12:33:12 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sat, 12 Jun 2010 10:33:12 +0000
Subject: [issue8978] "tarfile.ReadError: file could not be opened
	successfully" if compiled without zlib
In-Reply-To: <1276292933.37.0.137444086026.issue8978@psf.upfronthosting.co.za>
Message-ID: <1276338792.46.0.358387918153.issue8978@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

If you pass an explicit mode, the error message is more or less what you want:

>>> tarfile.open("uga.tgz", mode="r:gz")
[...]
tarfile.CompressionError: gzip module is not available

The way mode="r" detects which compression format is used is to open the file with each open method (i.e. taropen, gzopen, bz2open) until one of them succeeds. If none of them matches it is impossible to say what the reason was.

As this would require more than just a simple one-line change, 2.7 is out of the question. But I see what I can do for 3.2.

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8978>
_______________________________________

From report at bugs.python.org  Sat Jun 12 13:46:49 2010
From: report at bugs.python.org (Christian Boos)
Date: Sat, 12 Jun 2010 11:46:49 +0000
Subject: [issue7470] logger.StreamHandler emit encoding fallback is wrong
In-Reply-To: <1260450875.81.0.20769448713.issue7470@psf.upfronthosting.co.za>
Message-ID: <1276343209.93.0.712362836926.issue7470@psf.upfronthosting.co.za>


Christian Boos <cboos at neuf.fr> added the comment:

Hello Vinay, 

I recently installed Python 2.6.5, and I see this buglet is also present there. When I reported the issue, I said 2.6 worked and IIRC it must have been 2.6 or 2.6.1. 

I don't know if it's worth to backport the fix for 2.6.6, but just in case, I wanted to let you know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7470>
_______________________________________

From report at bugs.python.org  Sat Jun 12 13:50:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 11:50:19 +0000
Subject: [issue7470] logger.StreamHandler emit encoding fallback is wrong
In-Reply-To: <1260450875.81.0.20769448713.issue7470@psf.upfronthosting.co.za>
Message-ID: <1276343419.46.0.387968673373.issue7470@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Only security fixes and documentation fixes are allowed to go into stable branches.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7470>
_______________________________________

From report at bugs.python.org  Sat Jun 12 14:38:25 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 12 Jun 2010 12:38:25 +0000
Subject: [issue8972] subprocess.list2cmdline doesn't quote the & character
In-Reply-To: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>
Message-ID: <1276346305.84.0.0684135064061.issue8972@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

Thanks for reporting this issue.  Can you attach a patch which adds a unit test covering this behavior and fixing the quoting rules?  It would be very helpful in resolving this ticket.  If implementing the whole thing is too much work, if you could just provide a failing unit test that would still be greatly helpful.

Thanks again.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8972>
_______________________________________

From report at bugs.python.org  Sat Jun 12 14:42:15 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 12 Jun 2010 12:42:15 +0000
Subject: [issue8980] distutils.tests.test_register.RegisterTestCase.test_strict
	fails
In-Reply-To: <1276313488.44.0.388606421429.issue8980@psf.upfronthosting.co.za>
Message-ID: <1276346535.37.0.152265622134.issue8980@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

You would have to install docutils.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8980>
_______________________________________

From report at bugs.python.org  Sat Jun 12 14:42:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 12:42:33 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1276346553.04.0.48485217378.issue8572@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords:  -easy
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8572>
_______________________________________

From report at bugs.python.org  Sat Jun 12 15:00:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 13:00:25 +0000
Subject: [issue8980] distutils.tests.test_register.RegisterTestCase.test_strict
	fails
In-Reply-To: <1276313488.44.0.388606421429.issue8980@psf.upfronthosting.co.za>
Message-ID: <1276347625.83.0.794400689575.issue8980@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

After converting docutils through 2to3 *sigh* and making it visible to 3.2, I get only one failure: NameError: global name 'RawInputs' is not defined

The DistutilsSetupError (?The docutils package is needed.?) also happens with 2.7, although ?pydoc2.7 docutils? tells me it?s installed fine. Should we make that two bugs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8980>
_______________________________________

From report at bugs.python.org  Sat Jun 12 15:06:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 13:06:21 +0000
Subject: [issue3075] make minidom.toxml() encoding argument useful
In-Reply-To: <1213121523.99.0.8342553488.issue3075@psf.upfronthosting.co.za>
Message-ID: <1276347981.2.0.00487678325358.issue3075@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is this still relevant for 3.2?

----------
nosy: +merwok
versions: +Python 3.3 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3075>
_______________________________________

From report at bugs.python.org  Sat Jun 12 15:06:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 13:06:34 +0000
Subject: [issue3075] make minidom.toxml() encoding argument useful
In-Reply-To: <1213121523.99.0.8342553488.issue3075@psf.upfronthosting.co.za>
Message-ID: <1276347994.61.0.653491576193.issue3075@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3075>
_______________________________________

From report at bugs.python.org  Sat Jun 12 15:09:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 13:09:48 +0000
Subject: [issue459007] Document sys.path on Windows
Message-ID: <1276348188.19.0.107760074923.issue459007@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: georg.brandl -> docs at python
nosy: +docs at python
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue459007>
_______________________________________

From report at bugs.python.org  Sat Jun 12 15:09:54 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 12 Jun 2010 13:09:54 +0000
Subject: [issue8980] distutils.tests.test_register.RegisterTestCase.test_strict
	fails
In-Reply-To: <1276313488.44.0.388606421429.issue8980@psf.upfronthosting.co.za>
Message-ID: <1276348194.42.0.201727560525.issue8980@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

'python3.2 setup.py build' automatically uses 2to3. You should use docutils trunk. docutils-0.6 has many bugs in support for Python 3.

I have docutils installed (using Portage, Gentoo's package manager) for Python 2.6, 2.7, 3.1 and 3.2 and all tests from distutils.tests.test_register pass for me with Python 2.6 and 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8980>
_______________________________________

From report at bugs.python.org  Sat Jun 12 15:14:26 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 12 Jun 2010 13:14:26 +0000
Subject: [issue8202] sys.argv[0] and python -m package
In-Reply-To: <1269289306.17.0.0782561601798.issue8202@psf.upfronthosting.co.za>
Message-ID: <1276348466.59.0.887348965003.issue8202@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Grr, in doing the Py3k forward port I found the hack based on the "-c" entry that I remembered (I had mentioned it *right there* in a comment in main.c, so I don't know how I missed it when first updating 2.7 - I suspect I got lost in the ifdef maze inside SetArgV and managed to convince myself it wasn't a problem).

Anyway, it turns out PySys_SetArgV() uses the "sys.argv[0] == '-c'" check to skip over checking the file system for a file by that name. By reusing that same value, the -m code was able to also skip that check without needing to add any additional checks in the sysmodule code.

With the change I made to the 2.x branch, 2.7 now reacts differently if someone creates a "-m" file in the launch directory:

:~/devel/python$ python -i -m runpy
No module specified for execution
>>> sys.path[0]
''
:~/devel/python$ ./python -i -m runpy
No module specified for execution
>>> sys.path[0]
''
>>> 
:~/devel/python$ cat > -m
dd
:~/devel/python$ cat < -m
dd
:~/devel/python$ python -i -m runpy
No module specified for execution
>>> sys.path[0]
''
:~/devel/python$ ./python -i -m runpy
No module specified for execution
>>> sys.path[0]
'/home/ncoghlan/devel/python'
>>> 

System python is 2.6, local Python is SVN head. Note that the version from SVN changes behaviour after I create the oddly named file, while the system Python is unaffected.

My inclination is to fix this properly for 3.2 (including some extra command line tests to ensure that files named "-c" and "-m" don't confuse the sys.path configuration), but revert the change completely for 2.7.

Added Benjamin for an opinion, since 2.7 is in RC mode already.

----------
nosy: +benjamin.peterson
resolution: accepted -> 
stage: committed/rejected -> commit review
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8202>
_______________________________________

From report at bugs.python.org  Sat Jun 12 15:22:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 13:22:31 +0000
Subject: [issue8980] distutils.tests.test_register.RegisterTestCase.test_strict
	fails
In-Reply-To: <1276348194.42.0.201727560525.issue8980@psf.upfronthosting.co.za>
Message-ID: <4C138A13.8090005@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Since I already had docutils for my system 2.6 version, I just copied it
all and converted it for 3.2. I prefer not to use software that?s not
available through my system package manager, but that?s hardly relevant
here :)

So, if the io import is fixed, I guess the only remaining issue is the
docutils import. What about raising SkipTest instead of returning?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8980>
_______________________________________

From report at bugs.python.org  Sat Jun 12 15:22:55 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Jun 2010 13:22:55 +0000
Subject: [issue8972] subprocess.list2cmdline doesn't quote the & character
In-Reply-To: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>
Message-ID: <1276348975.04.0.914978427367.issue8972@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> unit test needed
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8972>
_______________________________________

From report at bugs.python.org  Sat Jun 12 15:31:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 13:31:59 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1276349519.68.0.13380448222.issue8572@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8572>
_______________________________________

From report at bugs.python.org  Sat Jun 12 15:33:31 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 12 Jun 2010 13:33:31 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1276349611.72.0.25116272929.issue8572@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8572>
_______________________________________

From report at bugs.python.org  Sat Jun 12 15:44:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 12 Jun 2010 13:44:29 +0000
Subject: [issue8982] argparse docs cross reference Namespace as a class but
	the Namespace class is not documented
In-Reply-To: <1276350269.78.0.816004374409.issue8982@psf.upfronthosting.co.za>
Message-ID: <1276350269.78.0.816004374409.issue8982@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

I wanted to find out if Namespace supported lookup by subscripting (args['someopt']), but the docs are silent on what Namespace is.  (The answer, by the way, appears to be "no"; there is a feature request for this in issue 8979).

----------
assignee: bethard
components: Documentation
messages: 107653
nosy: bethard, docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: argparse docs cross reference Namespace as a class but the Namespace class is not documented
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8982>
_______________________________________

From report at bugs.python.org  Sat Jun 12 15:45:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 12 Jun 2010 13:45:53 +0000
Subject: [issue8979] OptParse __getitem__
In-Reply-To: <1276304664.09.0.271886619191.issue8979@psf.upfronthosting.co.za>
Message-ID: <1276350353.35.0.448579099003.issue8979@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/issue8979>
_______________________________________

From report at bugs.python.org  Sat Jun 12 15:48:49 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 12 Jun 2010 13:48:49 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1276350529.0.0.555177126295.issue7490@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

And done for 3.2 in r81944 (that checkin included a correction to the docs example which I backported to 2.7 in r81945)

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Sat Jun 12 16:34:02 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 14:34:02 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276353242.88.0.0213096692415.issue8973@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch.  Alexander, do you want to check it for sanity?

----------
keywords: +patch
Added file: http://bugs.python.org/file17642/issue8973.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Sat Jun 12 16:34:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 14:34:31 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276353271.89.0.695299585912.issue8973@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

N.B. The patch doesn't fix the missing struct.Struct documentation issue;  I'll look at that separately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Sat Jun 12 16:39:15 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 14:39:15 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276353555.22.0.869896902821.issue8973@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Added file: http://bugs.python.org/file17643/issue8973.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Sat Jun 12 16:39:20 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 14:39:20 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276353560.72.0.476260362633.issue8973@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file17642/issue8973.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Sat Jun 12 16:45:12 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 14:45:12 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276353912.88.0.315184492246.issue8973@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The docstrings need to be rewrapped to 72 characters;  I'll do this once the wording is settled.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Sat Jun 12 17:18:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 15:18:05 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276355885.38.0.0934862181781.issue8973@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

calcsize() still does not have signature in docstring.

A nit: maybe follow calcsize() lead and say "format string fmt" rather than just "fmt".

One more __doc__ mention: in Struct docstring,


 |  __init__(...)
 |      x.__init__(...) initializes x; see x.__class__.__doc__ for signature

I think this is inherited, but quite confusing here because help(Struct) does not have signature.   Maybe just add signature to help(Struct).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Sat Jun 12 17:22:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 15:22:17 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276356137.64.0.351123368404.issue8973@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r81947 fixes the missing struct.Struct entry in struct.help.  (pydoc was relying on the inspect module to correctly guess the module for struct.Struct, and inspect was getting it wrong.  Adding __all__ to the struct module saves inspect from having to guess.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Sat Jun 12 17:22:49 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 15:22:49 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276356169.57.0.900228275562.issue8973@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I also accidentally included the docstring changes in r81947;  those were reverted in r81948.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Sat Jun 12 17:26:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 15:26:34 +0000
Subject: [issue8983] Docstrings should refer to help(name), not name.__doc__
In-Reply-To: <1276356394.26.0.0946047114478.issue8983@psf.upfronthosting.co.za>
Message-ID: <1276356394.26.0.0946047114478.issue8983@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Inspired by issue issue8973, I did


$ grep -in "see.*\.__doc__" Modules/*.c

Surprisingly, there were not as many results as I feared.

As I explained in the referenced issue,  "See name.__doc__", while technically correct, is not user friendly.  If you copy name.__doc__ to >>> prompt, you get an ugly repr of a multiline string.  I suggest s/name.__doc__/help(struct)/.

Here are the grep results

Modules/_threadmodule.c:904:Create a new lock object.  See LockType.__doc__ for information about locks.");
Modules/pwdmodule.c:103:See pwd.__doc__ for more on password database entries.");
Modules/pwdmodule.c:124:See pwd.__doc__ for more on password database entries.");
Modules/pwdmodule.c:155:See pwd.__doc__ for more on password database entries.");
Modules/spwdmodule.c:111:See spwd.__doc__ for more on shadow password database entries.");
Modules/spwdmodule.c:143:See spwd.__doc__ for more on shadow password database entries.");

----------
assignee: docs at python
components: Documentation
messages: 107661
nosy: belopolsky, docs at python, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Docstrings should refer to help(name), not name.__doc__
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8983>
_______________________________________

From report at bugs.python.org  Sat Jun 12 17:32:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 15:32:06 +0000
Subject: [issue8983] Docstrings should refer to help(name), not name.__doc__
In-Reply-To: <1276356394.26.0.0946047114478.issue8983@psf.upfronthosting.co.za>
Message-ID: <1276356726.02.0.452933667692.issue8983@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

A couple more:

$ grep -in "see.*\.__doc__" Lib/*.py
Lib/doctest.py:1782:    See doctest.__doc__ for an overview.
Lib/inspect.py:162:    See isfunction.__doc__ for attributes listing."""

an a really problematic

Objects/typeobject.c:5529:           "see x.__class__.__doc__ for signature",

This  affects every class' help and is very confusing when class doecstring does not show the constructor signature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8983>
_______________________________________

From report at bugs.python.org  Sat Jun 12 17:44:23 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 15:44:23 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276357463.35.0.0072309023463.issue8973@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Committed patch (with additional changes suggested by Alexander) in r81949.  Only the __init__ doc issue remains.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Sat Jun 12 17:51:22 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 15:51:22 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276357882.83.0.985730804408.issue8973@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

See issue #8983 for the the __init__ doc discussion since it is not specific to the struct module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Sat Jun 12 17:53:45 2010
From: report at bugs.python.org (Demur Rumed)
Date: Sat, 12 Jun 2010 15:53:45 +0000
Subject: [issue8977] Globalize lonely augmented assignment
In-Reply-To: <1276288000.72.0.276261442461.issue8977@psf.upfronthosting.co.za>
Message-ID: <1276358025.26.0.453205783766.issue8977@psf.upfronthosting.co.za>


Demur Rumed <junkmute at hotmail.com> added the comment:

I've modified the patch to be less aggressive, as suggested by Nick at http://mail.python.org/pipermail/python-ideas/2010-June/007428.html

As an aside, runtests.sh should have executable permissions

----------
Added file: http://bugs.python.org/file17644/diff.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8977>
_______________________________________

From report at bugs.python.org  Sat Jun 12 17:53:51 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 15:53:51 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276358031.46.0.179102717455.issue8973@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Apart from the pydoc __init__ issue, the Struct class documentation should probably be expanded a bit.  At the moment, it's just:

PyDoc_STRVAR(s__doc__, "Compiled struct object");

Alexander, interested in producing a patch?

----------
assignee: mark.dickinson -> belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Sat Jun 12 18:10:44 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Jun 2010 16:10:44 +0000
Subject: [issue8983] Docstrings should refer to help(name), not name.__doc__
In-Reply-To: <1276356394.26.0.0946047114478.issue8983@psf.upfronthosting.co.za>
Message-ID: <1276359044.02.0.984965472387.issue8983@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I agree, help(obj) is the better advice.  Would you prepare a patch?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8983>
_______________________________________

From report at bugs.python.org  Sat Jun 12 18:14:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 16:14:03 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276359243.42.0.497069487211.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I have made my mind on subclassing timezone issue.  I believe subclassing should not be allowed and here is the reason:

The new datetime.timezone class is a very specific implementation of tzinfo interface.  It guarantees that utcoffset(dt) and friends return the same value for all times.  Applications should be able to rely on this and a simple isinstance(tz, timezone) should be enough to deduce that tz is a fixed offset tzinfo instance.  (Of course careful applications can check type(tz) == timezone instead, but making isinstance(tz, timezone) subtly wrong is not a good idea.)

There is also very little to be gained from subclassing timezone.  It defines only 4 methods and each is entirely trivial.  Any non-trivial tzinfo implementation will need to override all 4 of them anyways.  It is much safer to derive from tzinfo directly and possible reuse timezone through containment (for example to format offsets in a standard way.)

The only immediate application of subclassing is to add dst() method returning a fixed offset rather than None.  This is trivial to implement through containment and if such class becomes popular, I would prefer to add this functionality to timezone class itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Sat Jun 12 18:15:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 16:15:29 +0000
Subject: [issue8983] Docstrings should refer to help(name), not name.__doc__
In-Reply-To: <1276356394.26.0.0946047114478.issue8983@psf.upfronthosting.co.za>
Message-ID: <1276359329.55.0.396762875267.issue8983@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Will do.

----------
assignee: docs at python -> belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8983>
_______________________________________

From report at bugs.python.org  Sat Jun 12 18:44:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 16:44:18 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276361058.11.0.231695631007.issue5094@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I agree it seems fine to disallow subclassing of timezone.  (And if we decide, in the light of new information, that that was wrong, then it's easy to allow subclassing later;  harder to disallow it.)

+1 for 'UTC?HH:MM' for both tzname and __str__, too.

I'll take a look at the newest patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Sat Jun 12 18:53:26 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 16:53:26 +0000
Subject: [issue8977] Globalize lonely augmented assignment
In-Reply-To: <1276288000.72.0.276261442461.issue8977@psf.upfronthosting.co.za>
Message-ID: <1276361606.92.0.143637246705.issue8977@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> As an aside, runtests.sh should have executable permissions.

Doesn't it already?  On my system (without having ever messed with any permissions as far as I can recall), I have:

newton:py3k dickinsm$ ls -l runtests.sh 
-rwxr-xr-x  1 dickinsm  staff  2168 28 Aug  2009 runtests.sh
newton:py3k dickinsm$ svn pl runtests.sh
Properties on 'runtests.sh':
  svn:executable
  svn:eol-style

And I get the same with a fresh hg checkout from http://code.python.org/hg/branches/py3k

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8977>
_______________________________________

From report at bugs.python.org  Sat Jun 12 18:58:12 2010
From: report at bugs.python.org (shypike)
Date: Sat, 12 Jun 2010 16:58:12 +0000
Subject: [issue8972] subprocess.list2cmdline doesn't quote the & character
In-Reply-To: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>
Message-ID: <1276361892.95.0.530876383726.issue8972@psf.upfronthosting.co.za>


shypike <shypike at sabnzbd.org> added the comment:

Added patch file for subprocess.py and test_subprocess.py.

----------
keywords: +patch
Added file: http://bugs.python.org/file17645/list2cmdline_ampersand_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8972>
_______________________________________

From report at bugs.python.org  Sat Jun 12 19:06:51 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 17:06:51 +0000
Subject: [issue7261] Document 2.x -> 3.x round changes in "What's New"
	documents.
In-Reply-To: <1257330793.87.0.85024867948.issue7261@psf.upfronthosting.co.za>
Message-ID: <1276362411.59.0.384940377861.issue7261@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file17646/issue7261.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7261>
_______________________________________

From report at bugs.python.org  Sat Jun 12 19:07:05 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 12 Jun 2010 17:07:05 +0000
Subject: [issue3129] struct allows repeat spec. without a format specifier
In-Reply-To: <1213694469.69.0.0950890622628.issue3129@psf.upfronthosting.co.za>
Message-ID: <1276362425.42.0.870402839737.issue3129@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If you think of this as this as a bug fix, it could go into 2.7.1. If you think of it as an ambiguity elimination that should only go into a new version, fine with me. My main concern is getting 3.2 as clear, clear, and consistent as possible. Thanks for finishing this issue and taking a small step in that direction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3129>
_______________________________________

From report at bugs.python.org  Sat Jun 12 19:07:13 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 17:07:13 +0000
Subject: [issue7261] Document 2.x -> 3.x round changes in "What's New"
	documents.
In-Reply-To: <1257330793.87.0.85024867948.issue7261@psf.upfronthosting.co.za>
Message-ID: <1276362433.6.0.0433204459799.issue7261@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7261>
_______________________________________

From report at bugs.python.org  Sat Jun 12 19:11:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 17:11:23 +0000
Subject: [issue3129] struct allows repeat spec. without a format specifier
In-Reply-To: <1213694469.69.0.0950890622628.issue3129@psf.upfronthosting.co.za>
Message-ID: <1276362683.61.0.571366267768.issue3129@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This is borderline enough that I am not comfortable making a call.  If anyone speaks in support of backporting I'll do it.  For 2.7 or 2.7.1.

----------
status: closed -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3129>
_______________________________________

From report at bugs.python.org  Sat Jun 12 19:28:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 17:28:10 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276363690.3.0.373967003628.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> +1 for 'UTC?HH:MM' for both tzname and __str__, too.

It looks like I subconsciently allocated enough characters for this in the string buffer, so now this is a single character change.  I'll do it with other changes (if any) before commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Sat Jun 12 19:49:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Jun 2010 17:49:46 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1276364986.84.0.162548611932.issue8857@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Testing the patch under a Windows XP Qemu virtual machine gives the following error. Works fine under 64-bit Linux.

======================================================================
ERROR: testGetaddrinfo (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Z:\cpython\__svn__\lib\test\test_socket.py", line 568, in testGetaddrinf
o
    socket.getaddrinfo('::1', 80)
gaierror: [Errno 11001] getaddrinfo failed

----------------------------------------------------------------------
Ran 99 tests in 14.851s

FAILED (errors=1)
test test_socket failed -- Traceback (most recent call last):
  File "Z:\cpython\__svn__\lib\test\test_socket.py", line 568, in testGetaddrinf
o
    socket.getaddrinfo('::1', 80)
gaierror: [Errno 11001] getaddrinfo failed

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Sat Jun 12 19:57:26 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 17:57:26 +0000
Subject: [issue3129] struct allows repeat spec. without a format specifier
In-Reply-To: <1213694469.69.0.0950890622628.issue3129@psf.upfronthosting.co.za>
Message-ID: <1276365446.01.0.707869427415.issue3129@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I don't think it's a good idea to make a change like this in a bugfix release, since it could break existing code (though admittedly code that probably isn't doing anything useful).

It's not a huge thing:  both the risk and the gain from making the change are small, but IMO the risk for a bugfix release outweighs the gain.

So I don't think 2.7.1 is an option.  2.7 is an option, but I'm trying to be disciplined given that we're already in release candidate stage.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3129>
_______________________________________

From report at bugs.python.org  Sat Jun 12 20:15:39 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 12 Jun 2010 18:15:39 +0000
Subject: [issue8972] subprocess.list2cmdline doesn't quote the & character
In-Reply-To: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>
Message-ID: <1276366539.69.0.580164436448.issue8972@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

Thanks.

I'm not sure this is a correct change.  And in fact, I would say that the current quoting of | is also incorrect.

& and | (and ^ and perhaps several others) have special meaning to cmd.exe.  list2cmdline is documented as applying the quoting rules which the "MS C runtime" uses: cmd.exe and the C runtime are different and have different rules.

It seems to me that whoever added the | handling to list2cmdline was confused about the purpose of this function, or failed to properly document the function.

It would make more sense to document list2cmdline as applying cmd.exe-style quoting rules, if those are the rules it is actually going to implement.

A better option, though, would probably be to implement the cmd.exe quoting rules in a different function from the MS C runtime rules.

This all might benefit from a sanity check from someone who's actually worked with the subprocess module before, though (ie, not me).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8972>
_______________________________________

From report at bugs.python.org  Sat Jun 12 20:16:19 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 12 Jun 2010 18:16:19 +0000
Subject: [issue8972] subprocess.list2cmdline doesn't quote the & character
In-Reply-To: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>
Message-ID: <1276366579.41.0.0794626664481.issue8972@psf.upfronthosting.co.za>


Changes by Jean-Paul Calderone <exarkun at twistedmatrix.com>:


----------
components: +Library (Lib)
stage: unit test needed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8972>
_______________________________________

From report at bugs.python.org  Sat Jun 12 20:25:16 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 12 Jun 2010 18:25:16 +0000
Subject: [issue8972] subprocess.list2cmdline doesn't quote the & character
In-Reply-To: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>
Message-ID: <1276367116.69.0.444884568555.issue8972@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/issue8972>
_______________________________________

From report at bugs.python.org  Sat Jun 12 20:25:51 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 12 Jun 2010 18:25:51 +0000
Subject: [issue8972] subprocess.list2cmdline doesn't quote the & character
In-Reply-To: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>
Message-ID: <1276367151.87.0.350015544164.issue8972@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

http://www.autohotkey.net/~deleyd/parameters/parameters.htm#WINCRULES is a helpful reference, by the way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8972>
_______________________________________

From report at bugs.python.org  Sat Jun 12 20:27:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 18:27:06 +0000
Subject: [issue8983] Docstrings should refer to help(name), not name.__doc__
In-Reply-To: <1276356394.26.0.0946047114478.issue8983@psf.upfronthosting.co.za>
Message-ID: <1276367226.63.0.784666291018.issue8983@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attaching issue8983.diff patch.  I am a bit unsure about __init__ docstring change:

1. Are cases when help(type(x)) differs from help(x) important enough to distinguish in docstring?


2. Do we need a default docstring on __init__ at all?  If so, should we keep a reference to class doc which may not be correct?  See issue8973.

3. Why __init__ has a default docstring but __new__ and __del__ don't?

4. There are some other inconsistencies in type docstrings.  E.g., "__subclasschck__ -> check if an class is a subclass" (misspelling and and missing ()).

----------
keywords: +patch
stage: needs patch -> commit review
versions: +Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17647/issue8983.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8983>
_______________________________________

From report at bugs.python.org  Sat Jun 12 20:53:22 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 18:53:22 +0000
Subject: [issue8469] struct - please make sizes explicit
In-Reply-To: <1271766650.13.0.432849451622.issue8469@psf.upfronthosting.co.za>
Message-ID: <1276368802.09.0.431903070453.issue8469@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've added sizes to the table, reordered some of the sections, and made a couple of other tweaks (like renaming the 'Objects' section to 'Classes') in r81957 (trunk) and r81955-81956 (py3k).

I'll backport these changes to release26-maint and release31-maint;  leaving open for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8469>
_______________________________________

From report at bugs.python.org  Sat Jun 12 21:04:28 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 19:04:28 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276369468.47.0.999668391549.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attaching issue5094f.diff which implements 'UTC?HH:MM' and adds unit tests for more error cases.

----------
Added file: http://bugs.python.org/file17648/issue5094f.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Sat Jun 12 21:18:29 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 12 Jun 2010 19:18:29 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1276370309.88.0.43942011967.issue8857@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Does that mean has_ipv6() is broken maybe?
I've just tested it against a Windows XP sp3 without IPv6 installed (socket.has_ipv6 returns True thought) and it doesn't fail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Sat Jun 12 21:20:57 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 19:20:57 +0000
Subject: [issue8469] struct - please make sizes explicit
In-Reply-To: <1271766650.13.0.432849451622.issue8469@psf.upfronthosting.co.za>
Message-ID: <1276370457.42.0.234831811798.issue8469@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Merged to maintenance branches in r81959 (release26-maint) and r81960 (release31-maint).  Closing.

----------
resolution:  -> fixed
stage:  -> 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/issue8469>
_______________________________________

From report at bugs.python.org  Sat Jun 12 21:25:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 19:25:03 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276370703.16.0.906187219677.issue8973@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

How does issue8973-Struct.diff look?

----------
Added file: http://bugs.python.org/file17649/issue8973-Struct.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Sat Jun 12 21:30:26 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 19:30:26 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276371026.55.0.62953250305.issue8973@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Looks fine.  I'd probably call the argument 'fmt' rather than 'format', for consistency.  Please commit, with or without the 'format' -> 'fmt' change, as you choose.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Sat Jun 12 21:38:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 19:38:11 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276371491.61.0.322618660818.issue8973@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r81961.   Yes, I used "format" for consistency with the manual, but on the second thought consistency within help() is more important.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Sat Jun 12 21:42:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 19:42:03 +0000
Subject: [issue8973] Inconsistent docstrings in struct module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276371723.26.0.18633990075.issue8973@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8973>
_______________________________________

From report at bugs.python.org  Sat Jun 12 21:54:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 19:54:59 +0000
Subject: [issue8983] Docstrings should refer to help(name), not name.__doc__
In-Reply-To: <1276356394.26.0.0946047114478.issue8983@psf.upfronthosting.co.za>
Message-ID: <1276372499.2.0.92561270725.issue8983@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

1. For old-style class instances, both help(i) and help(type(i)) give the help for the instance type, which is highly unhelpful IMO. Otherwise it seems than both C class instances and regular Python new-style class instances give the class doc for help(i). Summary: help(x) is good, help(type(x)) unnecessary.

2. 3. Magic methods are documented through docs.python.org and eventually ABCs, not docstrings. I see no reason to make an exception for __init__, except if removing its docstring breaks code.

4. There are actually two typos ;) Regarding parens, I personally think it?s not helpful to always put them, since e.g. ?len()? is not valid, but my choice is not Python?s.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8983>
_______________________________________

From report at bugs.python.org  Sat Jun 12 22:10:23 2010
From: report at bugs.python.org (Sworddragon)
Date: Sat, 12 Jun 2010 20:10:23 +0000
Subject: [issue8984] Python 3 doesn't register script arguments
In-Reply-To: <1276373423.06.0.827266888307.issue8984@psf.upfronthosting.co.za>
Message-ID: <1276373423.06.0.827266888307.issue8984@psf.upfronthosting.co.za>


New submission from Sworddragon <sworddragon2 at aol.com>:

Python 3.1.2 hasn't any arguments except the file name in sys.argv[0]. For example: build.py test
sys.argv[1] will be empty. I tried even the first example from the documentation 15.4 (optparse) but the filename is None. In Python 2.6.5 all is working fine.

----------
components: Library (Lib)
messages: 107690
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Python 3 doesn't register script arguments
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8984>
_______________________________________

From report at bugs.python.org  Sat Jun 12 22:14:01 2010
From: report at bugs.python.org (=?utf-8?q?Germ=C3=A1n_L=2E_Osella_Massa?=)
Date: Sat, 12 Jun 2010 20:14:01 +0000
Subject: [issue8985] String format() has problems parsing numeric indexes
In-Reply-To: <1276373641.02.0.137473124387.issue8985@psf.upfronthosting.co.za>
Message-ID: <1276373641.02.0.137473124387.issue8985@psf.upfronthosting.co.za>


New submission from Germ?n L. Osella Massa <gosella at gmail.com>:

The str.format() method allows index lookup on an object that supports __getitem__(). However, negative indexes are not supported.

Examples (using Python 2.6.5):

>>> "{0[0]}".format([0, 1, 2])
'0'

>>> "{0[-1]}".format([0, 1, 2])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list indices must be integers, not str

>>> u"{0[0]}".format([0, 1, 2])
u'0'
>>> u"{0[-1]}".format([0, 1, 2])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list indices must be integers, not unicode

Also notice that spaces matter:

>>> "{0[ 0 ]}".format([0, 1, 2])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list indices must be integers, not str

(The same thing happens on Python 3.1.2)

The problem is that the function get_integer() on Objects/stringlib/string_format.h don't expect spaces or a '-' char, only digits. If the index is not a continuous sequence of digits, it assumes that it is a key for a dict and the index is treated as a string, and that's the cause of the TypeError exception.

This code is the same from 2.6.5 up to trunk.

get_integer() is not very robust to parsing numbers. I'm not familiar with CPython but perhaps the same code used in int(str) can be applied here to take advantage of the better parsing that int() has.

----------
components: Library (Lib), Unicode
messages: 107691
nosy: Germ?n.L..Osella.Massa
priority: normal
severity: normal
status: open
title: String format() has problems parsing numeric indexes
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/issue8985>
_______________________________________

From report at bugs.python.org  Sat Jun 12 22:20:02 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 20:20:02 +0000
Subject: [issue8984] Python 3 doesn't register script arguments
In-Reply-To: <1276373423.06.0.827266888307.issue8984@psf.upfronthosting.co.za>
Message-ID: <1276374002.5.0.327888638056.issue8984@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It's not entirely clear to me what issue you're reporting here:  could you provide a short example script that exhibits the problem, and list the exact steps necessary to reproduce, along with actual and expected results?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8984>
_______________________________________

From report at bugs.python.org  Sat Jun 12 22:26:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 20:26:32 +0000
Subject: [issue8985] String format() has problems parsing numeric indexes
In-Reply-To: <1276373641.02.0.137473124387.issue8985@psf.upfronthosting.co.za>
Message-ID: <1276374392.11.0.396519211692.issue8985@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The behaviour is by design (I think), though perhaps the error messages could be improved.

Are you asking for negative indices and extra space to be accepted?  In that case this should be a feature request rather than a bug report.

----------
nosy: +eric.smith, mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8985>
_______________________________________

From report at bugs.python.org  Sat Jun 12 22:27:53 2010
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 12 Jun 2010 20:27:53 +0000
Subject: [issue8979] OptParse __getitem__
In-Reply-To: <1276304664.09.0.271886619191.issue8979@psf.upfronthosting.co.za>
Message-ID: <1276374473.3.0.522984738121.issue8979@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Given that the one obvious way of using dict-style syntax given a Python object is to call vars(), I thing adding a __getitem__ is probably a bad idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8979>
_______________________________________

From report at bugs.python.org  Sat Jun 12 22:34:44 2010
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 12 Jun 2010 20:34:44 +0000
Subject: [issue8982] argparse docs cross reference Namespace as a class but
	the Namespace class is not documented
In-Reply-To: <1276350269.78.0.816004374409.issue8982@psf.upfronthosting.co.za>
Message-ID: <1276374884.59.0.853813938643.issue8982@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

That's right, it doesn't support subscripting. The docs are silent on what namespace is mainly because I don't want to commit to anything other than an object with attributes. But that could be made clearer in the docs.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8982>
_______________________________________

From report at bugs.python.org  Sat Jun 12 22:35:16 2010
From: report at bugs.python.org (Sworddragon)
Date: Sat, 12 Jun 2010 20:35:16 +0000
Subject: [issue8984] Python 3 doesn't register script arguments
In-Reply-To: <1276373423.06.0.827266888307.issue8984@psf.upfronthosting.co.za>
Message-ID: <1276374916.44.0.614919681264.issue8984@psf.upfronthosting.co.za>


Sworddragon <sworddragon2 at aol.com> added the comment:

Examplescript test.py:

import sys
print(sys.argv[1])


Call this script now with an argument, for exmaple: test.py 1234
I expect to see the string 1234 in the console but Python 3 says "IndexError: list index out of range". With Python 2.6.5 I be able to see the correct string 1234.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8984>
_______________________________________

From report at bugs.python.org  Sat Jun 12 22:40:27 2010
From: report at bugs.python.org (Bryan Ward)
Date: Sat, 12 Jun 2010 20:40:27 +0000
Subject: [issue8979] OptParse __getitem__
In-Reply-To: <1276304664.09.0.271886619191.issue8979@psf.upfronthosting.co.za>
Message-ID: <1276375227.6.0.885385344473.issue8979@psf.upfronthosting.co.za>


Bryan Ward <bward1 at gmail.com> added the comment:

Thanks for your help and I apologize for the unnecessary ticket.  I was unfamiliar with vars() which seems to accomplish what I wanted.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8979>
_______________________________________

From report at bugs.python.org  Sat Jun 12 22:43:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 20:43:11 +0000
Subject: [issue8979] OptParse __getitem__
In-Reply-To: <1276304664.09.0.271886619191.issue8979@psf.upfronthosting.co.za>
Message-ID: <1276375391.24.0.149645833142.issue8979@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Don?t hesitate to propose future ideas to the python-ideas mailing list
http://mail.python.org/mailman/listinfo/python-ideas

----------
resolution:  -> rejected
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8979>
_______________________________________

From report at bugs.python.org  Sat Jun 12 22:46:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 20:46:06 +0000
Subject: [issue8985] String format() has problems parsing numeric indexes
In-Reply-To: <1276373641.02.0.137473124387.issue8985@psf.upfronthosting.co.za>
Message-ID: <1276375566.1.0.832186936592.issue8985@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FYI, the version field is used to note versions where the bug will be fixed, not versions where it?s found. New features and bug fixes go to the dev branch (3.2), security and documentation fixes go to the stable branches (2.6 and 3.1). (2.7 is in release candidate, so it?s frozen.)

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8985>
_______________________________________

From report at bugs.python.org  Sat Jun 12 22:48:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 20:48:50 +0000
Subject: [issue8984] Python 3 doesn't register script arguments
In-Reply-To: <1276373423.06.0.827266888307.issue8984@psf.upfronthosting.co.za>
Message-ID: <1276375730.07.0.382569504119.issue8984@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can?t reproduce here:
$ python3.1 -c "import sys; print(sys.argv[1])" 1234
1234
$ python3.1 --version
Python 3.1.2

----------
components: +Interpreter Core -Library (Lib)
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8984>
_______________________________________

From report at bugs.python.org  Sat Jun 12 22:49:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 20:49:37 +0000
Subject: [issue8984] Python 3 doesn't register script arguments
In-Reply-To: <1276373423.06.0.827266888307.issue8984@psf.upfronthosting.co.za>
Message-ID: <1276375777.13.0.856032206263.issue8984@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  I don't see any difference between the two here (OS X 10.6).  What platform are you on, and where did your copy of Python 3.1.2 come from?

newton:~ dickinsm$ cat test.py
import sys
print(sys.argv[1])
newton:~ dickinsm$ python3.1 test.py 1234
1234
newton:~ dickinsm$ python2.6 test.py 1234
1234
newton:~ dickinsm$ python3.1
Python 3.1.2 (r312:79147, May 18 2010, 17:21:15) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 
newton:~ dickinsm$ python2.6
Python 2.6.5 (r265:79063, May 18 2010, 17:12:15) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8984>
_______________________________________

From report at bugs.python.org  Sat Jun 12 22:52:51 2010
From: report at bugs.python.org (Sworddragon)
Date: Sat, 12 Jun 2010 20:52:51 +0000
Subject: [issue8984] Python 3 doesn't register script arguments
In-Reply-To: <1276373423.06.0.827266888307.issue8984@psf.upfronthosting.co.za>
Message-ID: <1276375971.63.0.870811217905.issue8984@psf.upfronthosting.co.za>


Sworddragon <sworddragon2 at aol.com> added the comment:

I'm using Windows XP Professional SP3. I downloaded Python 3.1.2 from this site. Even Python 3.0.1 hasn't worked.

----------
components: +Library (Lib) -Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8984>
_______________________________________

From report at bugs.python.org  Sat Jun 12 22:55:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 20:55:03 +0000
Subject: [issue8984] Python 3 doesn't register script arguments
In-Reply-To: <1276373423.06.0.827266888307.issue8984@psf.upfronthosting.co.za>
Message-ID: <1276376103.5.0.392578355292.issue8984@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

3.0 should not be used and does not get fixes.

Can you try downloading Python again and testing?

P.S. please do not change the component; Lib means ?Python files under Lib/ in the source checkout?, but sys is a module built by the interpreter core.

----------
components: +Interpreter Core -Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8984>
_______________________________________

From report at bugs.python.org  Sat Jun 12 23:03:44 2010
From: report at bugs.python.org (Sworddragon)
Date: Sat, 12 Jun 2010 21:03:44 +0000
Subject: [issue8984] Python 3 doesn't register script arguments
In-Reply-To: <1276373423.06.0.827266888307.issue8984@psf.upfronthosting.co.za>
Message-ID: <1276376624.26.0.0660663023064.issue8984@psf.upfronthosting.co.za>


Sworddragon <sworddragon2 at aol.com> added the comment:

I have already installed Python 3.1.2 a second time. I have selected during the installation that the files shall be compiled into bytecode.

----------
components: +Library (Lib) -Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8984>
_______________________________________

From report at bugs.python.org  Sat Jun 12 23:22:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Jun 2010 21:22:29 +0000
Subject: [issue8984] Python 3 doesn't register script arguments
In-Reply-To: <1276373423.06.0.827266888307.issue8984@psf.upfronthosting.co.za>
Message-ID: <1276377749.82.0.923692162976.issue8984@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8984>
_______________________________________

From report at bugs.python.org  Sat Jun 12 23:23:20 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 12 Jun 2010 21:23:20 +0000
Subject: [issue8985] String format() has problems parsing numeric indexes
In-Reply-To: <1276373641.02.0.137473124387.issue8985@psf.upfronthosting.co.za>
Message-ID: <1276377800.1.0.480537705523.issue8985@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

get_integer uses the narrowest possible definition for integer indexes, in order to pass all other strings to mappings.

>>> '{0[ 0 ]} {0[-1]}'.format({' 0 ': 'foo', '-1': 'bar'})
'foo bar'

Remember, it has to guess what type of lookup to do based on whether the value inside [] looks like an integer or not.

>From the PEP:
    Because keys are not quote-delimited, it is not possible to
    specify arbitrary dictionary keys (e.g., the strings "10" or
    ":-]") from within a format string.

I don't believe this restriction causes any practical problem.

I'm not sure the error could be improved. The code that's being called is essentially:

>>> [0, 1, 2]['-1']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list indices must be integers, not str

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8985>
_______________________________________

From report at bugs.python.org  Sat Jun 12 23:35:28 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 21:35:28 +0000
Subject: [issue8984] Python 3 doesn't register script arguments
In-Reply-To: <1276373423.06.0.827266888307.issue8984@psf.upfronthosting.co.za>
Message-ID: <1276378528.53.0.284922933426.issue8984@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm failing to reproduce this on Windows 7, too.

It sounds as though you're starting the python script without an explict 'python'.  What are your filetype associations for python scripts?

i.e., what's the result of typing 'assoc py' at a console prompt?
And what's the result of the 'ftype' command for the above?

Just for reference, I get:

>assoc.py
.py=Python.File

>ftype Python.File
Python.File=C:\Python31\python.exe "%1" %*

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8984>
_______________________________________

From report at bugs.python.org  Sat Jun 12 23:51:31 2010
From: report at bugs.python.org (Sworddragon)
Date: Sat, 12 Jun 2010 21:51:31 +0000
Subject: [issue8984] Python 3 doesn't register script arguments
In-Reply-To: <1276373423.06.0.827266888307.issue8984@psf.upfronthosting.co.za>
Message-ID: <1276379491.69.0.810245648751.issue8984@psf.upfronthosting.co.za>


Sworddragon <sworddragon2 at aol.com> added the comment:

assoc .py
.py=Python.File

I tried this now with Ubuntu and Python 3.1.2 and all works fine. But under Windows XP it doesn't work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8984>
_______________________________________

From report at bugs.python.org  Sat Jun 12 23:56:39 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 21:56:39 +0000
Subject: [issue8984] Python 3 doesn't register script arguments
In-Reply-To: <1276373423.06.0.827266888307.issue8984@psf.upfronthosting.co.za>
Message-ID: <1276379799.35.0.816593521583.issue8984@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay, thanks.  What does

ftype Python.File

give?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8984>
_______________________________________

From report at bugs.python.org  Sun Jun 13 00:09:48 2010
From: report at bugs.python.org (Sworddragon)
Date: Sat, 12 Jun 2010 22:09:48 +0000
Subject: [issue8984] Python 3 doesn't register script arguments
In-Reply-To: <1276373423.06.0.827266888307.issue8984@psf.upfronthosting.co.za>
Message-ID: <1276380588.71.0.752534607786.issue8984@psf.upfronthosting.co.za>


Sworddragon <sworddragon2 at aol.com> added the comment:

ftype Python.File
Python.File="E:\Python31\python.exe" "%1" %*

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8984>
_______________________________________

From report at bugs.python.org  Sun Jun 13 00:23:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 22:23:17 +0000
Subject: [issue8984] Python 3 doesn't register script arguments
In-Reply-To: <1276373423.06.0.827266888307.issue8984@psf.upfronthosting.co.za>
Message-ID: <1276381397.2.0.817329730146.issue8984@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've just found issue #7936, which looks like the same problem.  I'm going to close this issue as a duplicate of that one;  further discussion should be moved there.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> sys.argv contains only scriptname

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8984>
_______________________________________

From report at bugs.python.org  Sun Jun 13 00:24:43 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 22:24:43 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1276381483.35.0.553869905202.issue7936@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closed issue 8984 as a duplicate of this;  merging nosy lists.

Tom, did you ever find a solution to this problem?

----------
nosy: +Sworddragon, loewis, mark.dickinson, merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Sun Jun 13 00:42:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 22:42:34 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1276382554.58.0.923870241675.issue7936@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a link to a similar discussion about Perl on Windows:

http://community.activestate.com/forum-topic/problem-passing-arguments

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Sun Jun 13 00:48:21 2010
From: report at bugs.python.org (shypike)
Date: Sat, 12 Jun 2010 22:48:21 +0000
Subject: [issue8972] subprocess.list2cmdline doesn't quote the & character
In-Reply-To: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>
Message-ID: <1276382901.9.0.529586153547.issue8972@psf.upfronthosting.co.za>


shypike <shypike at sabnzbd.org> added the comment:

A work-around could be that the caller puts double quotes around the individual elements of the sequence that need it.
However, this won't work because list2cmdline doesn't handle backslash quoting properly. An element like r'"foo"' is translated to r'\"foo\"'. This is incorrect because cmd.exe cannot handle this. The backslash may be appropriate for embedded quotes (like in r'foo"bar'), but not for outer quotes (like in r'"foobar"').

The user shouldn't have to worry with adding quotes anyway, so it would be better to demand that '|' and '&' are passed as separate elements in the sequence. Example ['echo', 'foo', '&', 'bar'].
When someone passes ['echo', 'foo&bar'], it is very obvious that r'echo "foo&bar"' is expected and not r'echo foo & bar'.

I have added a patch for this way of working of list2cmdline.

----------
Added file: http://bugs.python.org/file17650/list2cmdline_proper_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8972>
_______________________________________

From report at bugs.python.org  Sun Jun 13 01:02:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jun 2010 23:02:48 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1276383768.76.0.568752986202.issue7936@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

>From various other sites, and from experiments (thanks Eric Smith) it looks like the associations reported by 'assoc' and 'ftype' aren't necessarily the associations that are actually being used.

Sworddragon:  can you get any useful information out of the Windows registry (e.g., using regedit, searching for Python.File, and looking under shell\open\command), or by setting file associations through the Control Panel?

I don't know enough about Python on Windows to know whether there's any hope that this is a problem that can be solved at the Python end, but I'd guess not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Sun Jun 13 01:03:49 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 12 Jun 2010 23:03:49 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1276383829.63.0.277991822005.issue7936@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree with Mark: there's probably nothing Python can do about this. It's almost certainly an error with how Python is being invoked.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Sun Jun 13 01:04:31 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 12 Jun 2010 23:04:31 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1276383871.45.0.340469385632.issue7936@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

That being said, it would be interesting to see what the registry key HKEY_CLASSES_ROOT\Python.File\shell\open\command contains.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Sun Jun 13 01:35:49 2010
From: report at bugs.python.org (Mads Kiilerich)
Date: Sat, 12 Jun 2010 23:35:49 +0000
Subject: [issue8469] struct - please make sizes explicit
In-Reply-To: <1271766650.13.0.432849451622.issue8469@psf.upfronthosting.co.za>
Message-ID: <1276385749.94.0.391379950969.issue8469@psf.upfronthosting.co.za>


Mads Kiilerich <mads at kiilerich.com> added the comment:

Thanks for improving the documentation!

A couple of comments for possible further improvements:

I think it would be helpful to also see an early notice about how to achieve platform independence, versus the default of the local platform.

And perhaps the description of "standard" perhaps could be improved.

Perhaps something like the following could be used. Relative to release26-maint/Doc/library/struct.rst rev 81959.

----------
keywords: +patch
Added file: http://bugs.python.org/file17651/struct.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8469>
_______________________________________

From report at bugs.python.org  Sun Jun 13 01:51:00 2010
From: report at bugs.python.org (geremy condra)
Date: Sat, 12 Jun 2010 23:51:00 +0000
Subject: [issue8986] math.erfc OverflowError
In-Reply-To: <1276386660.2.0.0883413482543.issue8986@psf.upfronthosting.co.za>
Message-ID: <1276386660.2.0.0883413482543.issue8986@psf.upfronthosting.co.za>


New submission from geremy condra <debatem1 at gmail.com>:

In Python3.2, calling math.erfc with a value in [-27.2, -30) raises
an OverflowError: math range error. This is inconsistent with the
erfc function from scipy (scipy.special.erfc) as well as with the C99
function by the same name, both of which return 2. I suspect that
this is the result of the cutoff for the use of the continuing fraction
approximation of erfc beginning when abs(x) > 30, but I'm not sure.

----------
components: Library (Lib)
messages: 107718
nosy: debatem1
priority: normal
severity: normal
status: open
title: math.erfc OverflowError
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8986>
_______________________________________

From report at bugs.python.org  Sun Jun 13 03:22:45 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Sun, 13 Jun 2010 01:22:45 +0000
Subject: [issue8968] token type constants are not documented
In-Reply-To: <1276216063.7.0.11813766705.issue8968@psf.upfronthosting.co.za>
Message-ID: <1276392165.25.0.81201044116.issue8968@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

> * I would list them all in one directive, like this:

Ok, done. Attaching the updated patch


> There is no description in that directive.  Best move part of the
description above them in it.

I am not sure I understand your request. Could you clarify?


>  NL and COMMENT are defined in tokenize because they are neither 
defined nor used by the Python tokenizer.

Oh, I just realized the source of my misunderstanding: token.py captures token types as they are returned by python's own tokenizer. While tokenize module  does its own tokenization and produces results which are a bit different. COMMENT and NL tokens is one of the differences but there is a difference in how the operation tokens are treated. In fact tokenize's docstring explicitly says so.

... It is designed to match the working of the Python tokenizer exactly, except that it produces COMMENT tokens for comments and gives type OP for all operators ...

I think this clarification should go into official docs as well, would you agree?

PS. even with this clarification, I find the situation quite a bit confusing: especially given that tok_name dict from token module does have a name for COMMENT and that name is inserted by tokenize module..  So I still feel that just adding COMMENT and NL to token module (with clarification that they are not generated by the python's own tokenizer) would be a bit cleaner.

----------
Added file: http://bugs.python.org/file17652/token.rst.patch.v2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8968>
_______________________________________

From report at bugs.python.org  Sun Jun 13 04:44:34 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Jun 2010 02:44:34 +0000
Subject: [issue8202] sys.argv[0] and python -m package
In-Reply-To: <1269289306.17.0.0782561601798.issue8202@psf.upfronthosting.co.za>
Message-ID: <1276397074.65.0.0153141383696.issue8202@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Revert seems sensible in this situation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8202>
_______________________________________

From report at bugs.python.org  Sun Jun 13 07:22:53 2010
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 13 Jun 2010 05:22:53 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

I discovered this investigating a bug report that python-cjson doesn't compile properly on Windows (http://pypi.python.org/pypi/python-cjson). Cjson's setup.py asks distutils to compile with the flag '-DMODULE_VERSION="1.0.5"', but distutils.spawn._nt_quote_args is not escaping the quotes correctly.

Specifically, the current behaviour is:
>>> distutils.spawn._nt_quote_args(['-DMODULE_VERSION="1.0.5"'])
['-DMODULE_VERSION="1.0.5"']

I expect the following:
>>> distutils.spawn._nt_quote_args(['-DMODULE_VERSION="1.0.5"'])
['"-DMODULE_VERSION=""1.0.5"""']

Not surprising, since that function contains a big comment:
    # XXX this doesn't seem very robust to me -- but if the Windows guys
    # say it'll work, I guess I'll have to accept it.  (What if an arg
    # contains quotes?  What other magic characters, other than spaces,
    # have to be escaped?  Is there an escaping mechanism other than
    # quoting?)

It only escapes spaces, and that's it. I've proposed a patch which escapes the following characters properly: "&()<>^| (as far as I can tell, these are the "reserved" characters on Windows).

Note: I did not escape * or ?, the wildcard characters. As far as I can tell, these only have special meaning on the command-line itself, and not when supplied to a program.

Alternatively, it could call subprocess.list2cmdline (but there seem to be issues with that: http://bugs.python.org/issue8972).

----------
assignee: tarek
components: Distutils
files: spawn.patch
keywords: patch
messages: 107722
nosy: mgiuca, tarek
priority: normal
severity: normal
status: open
title: Distutils doesn't quote Windows command lines properly
versions: Python 2.6
Added file: http://bugs.python.org/file17653/spawn.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Sun Jun 13 07:23:47 2010
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 13 Jun 2010 05:23:47 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1276406627.38.0.972927595403.issue8987@psf.upfronthosting.co.za>


Changes by Matt Giuca <matt.giuca at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Sun Jun 13 08:55:44 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Jun 2010 06:55:44 +0000
Subject: [issue8202] sys.argv[0] and python -m package
In-Reply-To: <1269289306.17.0.0782561601798.issue8202@psf.upfronthosting.co.za>
Message-ID: <1276412144.07.0.434688783848.issue8202@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Reverted in r81964, marking as 3.2 only.

For 3.2, I'll get rid of the hack by having SetArgV treat both "-c" and "-m" as special values for sys.argv[0], and by adding some unit tests that make sure the presence of files with those names has no effect on the value of sys.path[0] when the corresponding command line switches are used.

----------
stage: commit review -> unit test needed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8202>
_______________________________________

From report at bugs.python.org  Sun Jun 13 09:37:29 2010
From: report at bugs.python.org (Sworddragon)
Date: Sun, 13 Jun 2010 07:37:29 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1276414649.45.0.168948411045.issue7936@psf.upfronthosting.co.za>


Sworddragon <sworddragon2 at aol.com> added the comment:

This registry key contains "E:\Python31\python.exe" "%1" %*. I have too 2 python versions installed and manually associated the .py files to Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Sun Jun 13 10:00:45 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Jun 2010 08:00:45 +0000
Subject: [issue8986] math.erfc OverflowError
In-Reply-To: <1276386660.2.0.0883413482543.issue8986@psf.upfronthosting.co.za>
Message-ID: <1276416045.61.0.811348318128.issue8986@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +mark.dickinson
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8986>
_______________________________________

From report at bugs.python.org  Sun Jun 13 10:02:07 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Jun 2010 08:02:07 +0000
Subject: =?utf-8?b?W2lzc3VlODg4N10g4oCccHlkb2Mgc3Ry4oCdIHdvcmtzIGJ1dCBub3Qg4oCc?=
	=?utf-8?q?pydoc_str=2Etranslate=E2=80=9D?=
In-Reply-To: <1275565374.87.0.956319261544.issue8887@psf.upfronthosting.co.za>
Message-ID: <1276416127.06.0.435355662509.issue8887@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/issue8887>
_______________________________________

From report at bugs.python.org  Sun Jun 13 10:12:04 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Jun 2010 08:12:04 +0000
Subject: [issue8957] strptime('%c', ..) fails to parse output of strftime('%c',
	..) in non-English locale
In-Reply-To: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>
Message-ID: <1276416724.61.0.129450011367.issue8957@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/issue8957>
_______________________________________

From report at bugs.python.org  Sun Jun 13 10:13:02 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Jun 2010 08:13:02 +0000
Subject: [issue8940] *HTTPServer need a summary page with API inheritance table
In-Reply-To: <1276003396.33.0.469317406109.issue8940@psf.upfronthosting.co.za>
Message-ID: <1276416782.89.0.116862060019.issue8940@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Can you provide a patch?

----------
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8940>
_______________________________________

From report at bugs.python.org  Sun Jun 13 10:14:55 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Jun 2010 08:14:55 +0000
Subject: [issue8911] regrtest.main should have a test skipping argument
In-Reply-To: <1275794606.83.0.993053669818.issue8911@psf.upfronthosting.co.za>
Message-ID: <1276416895.39.0.917201998984.issue8911@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, flox
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8911>
_______________________________________

From report at bugs.python.org  Sun Jun 13 11:05:51 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 13 Jun 2010 09:05:51 +0000
Subject: [issue8986] math.erfc OverflowError
In-Reply-To: <1276386660.2.0.0883413482543.issue8986@psf.upfronthosting.co.za>
Message-ID: <1276419951.23.0.727866086448.issue8986@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8986>
_______________________________________

From report at bugs.python.org  Sun Jun 13 11:14:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 13 Jun 2010 09:14:32 +0000
Subject: [issue8986] math.erfc OverflowError
In-Reply-To: <1276386660.2.0.0883413482543.issue8986@psf.upfronthosting.co.za>
Message-ID: <1276420472.97.0.788193970614.issue8986@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report.  What platform are you on?  I'm not seeing this behaviour on OS X:

Python 3.2a0 (py3k:81935M, Jun 12 2010, 10:01:38) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import erfc
>>> erfc(-28.0)
2.0

It should be easy to fix, since erfc is already 2.0 (to within machine accuracy) in that argument range, but I'd like to understand where the problem is coming from first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8986>
_______________________________________

From report at bugs.python.org  Sun Jun 13 11:14:40 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 13 Jun 2010 09:14:40 +0000
Subject: [issue8986] math.erfc OverflowError
In-Reply-To: <1276386660.2.0.0883413482543.issue8986@psf.upfronthosting.co.za>
Message-ID: <1276420480.84.0.768303743834.issue8986@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8986>
_______________________________________

From report at bugs.python.org  Sun Jun 13 11:34:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 13 Jun 2010 09:34:31 +0000
Subject: [issue8986] math.erfc OverflowError
In-Reply-To: <1276386660.2.0.0883413482543.issue8986@psf.upfronthosting.co.za>
Message-ID: <1276421671.17.0.39858489016.issue8986@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Looking at the source, I think I know where this is coming from:  one of the terms in the expression for erfc(x) is exp(-x*x).  For abs(x) >= 27.284 or so, this underflows to zero.

So the likely cause is that whatever platform you're on is setting errno to ERANGE on underflow to 0;  that errno value later gets interpreted as representing an overflow.

And for x >= 30.0 a constant expression is used instead, so there's no OverflowError any more.

Okay:  solved in principle!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8986>
_______________________________________

From report at bugs.python.org  Sun Jun 13 11:47:27 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 13 Jun 2010 09:47:27 +0000
Subject: [issue8986] math.erfc OverflowError
In-Reply-To: <1276386660.2.0.0883413482543.issue8986@psf.upfronthosting.co.za>
Message-ID: <1276422447.03.0.860510278046.issue8986@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Geremy, can you verify that the attached patch fixes the problem?  If so, I'll add tests and commit.

----------
keywords: +patch
Added file: http://bugs.python.org/file17654/issue8986.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8986>
_______________________________________

From report at bugs.python.org  Sun Jun 13 11:47:44 2010
From: report at bugs.python.org (geremy condra)
Date: Sun, 13 Jun 2010 09:47:44 +0000
Subject: [issue8986] math.erfc OverflowError
In-Reply-To: <1276420472.97.0.788193970614.issue8986@psf.upfronthosting.co.za>
Message-ID: <AANLkTinGdJFw7s3FFXKBaDYiriuZbNn860bxI7pNjGjh@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Sun, Jun 13, 2010 at 5:14 AM, Mark Dickinson <report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Thanks for the report. ?What platform are you on? ?I'm not seeing this behaviour on OS X:

I'm on Ubuntu 10.04 64-bit.

Geremy Condra

> Python 3.2a0 (py3k:81935M, Jun 12 2010, 10:01:38)
> [GCC 4.2.1 (Apple Inc. build 5659)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> from math import erfc
>>>> erfc(-28.0)
> 2.0
>
> It should be easy to fix, since erfc is already 2.0 (to within machine accuracy) in that argument range, but I'd like to understand where the problem is coming from first.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8986>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8986>
_______________________________________

From report at bugs.python.org  Sun Jun 13 12:02:18 2010
From: report at bugs.python.org (geremy condra)
Date: Sun, 13 Jun 2010 10:02:18 +0000
Subject: [issue8986] math.erfc OverflowError
In-Reply-To: <1276422447.03.0.860510278046.issue8986@psf.upfronthosting.co.za>
Message-ID: <AANLkTil-9tKWhXe-L8LBJY-YTI_qQONhORcS6BstAfeg@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Sun, Jun 13, 2010 at 5:47 AM, Mark Dickinson <report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Geremy, can you verify that the attached patch fixes the problem? ?If so, I'll add tests and commit.

I've only tested it from 2**16 + 1 to -2**16 at unit and half-unit
intervals, but it doesn't blow up
here. Thanks- and I appreciate the quick response.

Geremy Condra

> ----------
> keywords: +patch
> Added file: http://bugs.python.org/file17654/issue8986.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8986>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8986>
_______________________________________

From report at bugs.python.org  Sun Jun 13 12:50:35 2010
From: report at bugs.python.org (gonegown)
Date: Sun, 13 Jun 2010 10:50:35 +0000
Subject: [issue8988] import + coding = failure (3.1.2/win32)
In-Reply-To: <1276426235.15.0.873898512927.issue8988@psf.upfronthosting.co.za>
Message-ID: <1276426235.15.0.873898512927.issue8988@psf.upfronthosting.co.za>


New submission from gonegown <nomedocac at gmail.com>:

I have python 3.1.2 fetched from the main site.

imagine two source files:

a.py:
-------
# coding: cp1251
import b;
print('A');
-------

b.py:
-------
print('B');
-------

Both reside in the same directory containing at least one non-ascii character (try 0xdb) in the _path_.

import will fail with an empty error!
#coding here works fine with utf-8 and fails using any other one

now tell me how the hell can file system encoding be related to file content encoding?!

I've attached the source

----------
components: None
files: pybug-import-coding.zip
messages: 107731
nosy: gonegown
priority: normal
severity: normal
status: open
title: import + coding = failure (3.1.2/win32)
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file17655/pybug-import-coding.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8988>
_______________________________________

From report at bugs.python.org  Sun Jun 13 13:02:02 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 13 Jun 2010 11:02:02 +0000
Subject: [issue8986] math.erfc OverflowError
In-Reply-To: <1276386660.2.0.0883413482543.issue8986@psf.upfronthosting.co.za>
Message-ID: <1276426922.15.0.563818656445.issue8986@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in r81967 (trunk) and r81968 (py3k).

I had to weaken the tests for erfc:  its accuracy for largish arguments (25.0 or so) is not ideal---I was seeing errors of 100 ulps and more.  However, I think this level of error is acceptable in practice, since for arguments this size the difference between erfc(x) and erfc(next_float_up(x)) is already several hundred ulps.

If anyone wants to look at improving the accuracy for large arguments, it's the calculation of exp(-x*x) that's the source of the error.  The way to fix it, if anyone cared, would be to do the multiplication x*x in double-double precision, giving x*x = y + z for doubles y and z, and then use exp(-y) * exp(-z) in place of exp(-x*x).

Thanks for catching this, Geremy!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8986>
_______________________________________

From report at bugs.python.org  Sun Jun 13 16:09:08 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 13 Jun 2010 14:09:08 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276438148.67.0.549637021497.issue5094@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The latest patch looks good to me.  I only have minor comments, in random order:

- Should the PyDateTime_TimeZone struct definition go into datetime.h, so that it's avaiable if you want to export any C-API functions later on?

- If you're not allowing subclassing, then presumably you don't need
  the new_timezone / new_timezone_ex dance?

- For clarity, please consider adding parentheses in:

    self = (PyDateTime_TimeZone *)type->tp_alloc(type, 0);

  to make it:

    self = (PyDateTime_TimeZone *)(type->tp_alloc(type, 0));

- Whitespace issues: there are a couple of tabs in the source (at around lines 810, 3388, 3390), and an overly long line (>79 characters) at around line 3365.

- Please add a brief comment before the added C functions (like new_timezone_ex) explaining their purpose.

- I wonder whether __ne__ should return the correct result (rather than returning NotImplemented) for timezone instances.  I realize that it's not necessary to implement it in order for 'tz1 != tz2' to work, but it still makes me uncomfortable that it's not implemented.  OTOH, I agree with the decision not to allow timezone order comparisons (though I bet they get requested at some point).

- There doesn't seem to be any mention of timezone.min or timezone.max in the docs.  Is this deliberate?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Sun Jun 13 17:15:38 2010
From: report at bugs.python.org (Adrian von Bidder)
Date: Sun, 13 Jun 2010 15:15:38 +0000
Subject: [issue8989] email.utils.make_msgid: specify domain
In-Reply-To: <1276442137.97.0.787561293748.issue8989@psf.upfronthosting.co.za>
Message-ID: <1276442137.97.0.787561293748.issue8989@psf.upfronthosting.co.za>


New submission from Adrian von Bidder <avbidder at fortytwo.ch>:

Using the hostname for the domain part of a Message-Id is probably the right thing usually but users may want to override this.

Please consider this rather trivial patch:

=====
--- utils.py.orig       2010-06-13 16:59:30.533861099 +0200
+++ utils.py    2010-06-13 17:02:18.650697979 +0200
@@ -173,13 +173,15 @@
 
 
 

-def make_msgid(idstring=None):
+def make_msgid(idstring=None, domain=None):
     """Returns a string suitable for RFC 2822 compliant Message-ID, e.g:
 
     <20020201195627.33539.96671 at nightshade.la.mastaler.com>
 
     Optional idstring if given is a string used to strengthen the
-    uniqueness of the message id.
+    uniqueness of the message id.  The domain part of the Message-ID
+    defaults to the locally defined hostname, but can be specified
+    explicitly.
     """
     timeval = time.time()
     utcdate = time.strftime('%Y%m%d%H%M%S', time.gmtime(timeval))
@@ -189,8 +191,9 @@
         idstring = ''
     else:
         idstring = '.' + idstring
-    idhost = socket.getfqdn()
-    msgid = '<%s.%s.%s%s@%s>' % (utcdate, pid, randint, idstring, idhost)
+    if domain is None:
+        domain = socket.getfqdn()
+    msgid = '<%s.%s.%s%s@%s>' % (utcdate, pid, randint, idstring, domain)
     return msgid
 
 
=====

thanks & greetings
-- vbi

----------
components: Library (Lib)
messages: 107734
nosy: avbidder at fortytwo.ch
priority: normal
severity: normal
status: open
title: email.utils.make_msgid: specify domain
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8989>
_______________________________________

From report at bugs.python.org  Sun Jun 13 17:20:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Jun 2010 15:20:30 +0000
Subject: [issue8989] email.utils.make_msgid: specify domain
In-Reply-To: <1276442137.97.0.787561293748.issue8989@psf.upfronthosting.co.za>
Message-ID: <1276442430.91.0.915248502838.issue8989@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Seems straightforward. Any reason not to allow it David?

Adrian, I edited the versions: new features go into 3.2 only. Please make sure your patch applies to this version (branch named py3k). Can you also write unit tests for this new parameter?

----------
keywords: +patch
nosy: +merwok, r.david.murray
stage:  -> unit test needed
type:  -> feature request
versions: +Python 3.2 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8989>
_______________________________________

From report at bugs.python.org  Sun Jun 13 17:49:13 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 13 Jun 2010 15:49:13 +0000
Subject: [issue8989] email.utils.make_msgid: specify domain
In-Reply-To: <1276442137.97.0.787561293748.issue8989@psf.upfronthosting.co.za>
Message-ID: <1276444153.86.0.0680521674372.issue8989@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Adrian, Could you generate the diffs from the
top level of the checkout and attach it here?

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8989>
_______________________________________

From report at bugs.python.org  Sun Jun 13 17:53:52 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 13 Jun 2010 15:53:52 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276444432.59.0.0662202055155.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Jun 13, 2010 at 10:09 AM, Mark Dickinson <report at bugs.python.org> wrote:
..
> - Should the PyDateTime_TimeZone struct definition go into
> datetime.h, so that it's avaiable if you want to export any C-API
> functions later on?
>
The original patch had this in the header file, but I moved it down to .c during dst debate. (See msg107186, point 3.)  In the future we may add accessor functions to datetime.h, but this can be done without exposing the C struct.
 
> - If you're not allowing subclassing, then presumably you don't need
> ?the new_timezone / new_timezone_ex dance?
>
I agree, but if you don't mind, I will not change it at this point.  There is a small chance that there will be an outcry for supporting subclassing and we will put that back in. Also, issue #2267 debate may result in removing the dance from other factory functions. (If the camp saying that the base class has no idea how to construct subclass instances wins.) Not a big deal either way, though.

> - For clarity, please consider adding parentheses in:
>
> ? ?self = (PyDateTime_TimeZone *)type->tp_alloc(type, 0);
>

will do.  PEP 7 does not mention that, but probably should. 

> - Whitespace issues: there are a couple of tabs in the source (at
> around lines 810, 3388, 3390), and an overly long line (>79
> characters) at around line 3365.
>

Thanks.  I thought I checked those.  Maybe I should take over issue8912 as a community service. :-) 

> - Please add a brief comment before the added C functions (like
> new_timezone_ex) explaining their purpose.
>

Will do.

> - I wonder whether __ne__ should return the correct result (rather
> than returning NotImplemented) for timezone instances. 

Will do.

> ?OTOH, I agree with the decision not to allow timezone order
> comparisons (though I bet they get requested at some point).

I will support such request.  It is very easy to implement (just remove the check that disallows it) and makes perfect sense.  I left them out only because it is easier to add features than to remove in the future and I don't want to debate this now.


>
> - There doesn't seem to be any mention of timezone.min or timezone.max
> in the docs. ?Is this deliberate?
>
Yes.  Without ordering, having min and max is rather strange.  I wanted to expose these for testing and will definitely document them when (and if) order comparisons are implemented.  For now, let's keep them as easter eggs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Sun Jun 13 18:06:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 13 Jun 2010 16:06:29 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276445189.28.0.462380146536.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Just to add a little bit of historical perspective, this proposal is really more than seven years old:

"""
s.keim (Dec 20, 2002 3:33 am; Comment #13)

.. do we really need methods like utcnow. I believe the following could be a little more easy to learn:

* the module define an UTC tzinfo object

* the module define an UTC tzinfo object instead of utcfromtimestamp(x) and utcnow(), the user can use fromtimestamp(x, tzinfo=UTC) and now(tzinfo=UTC)
""" http://www.zope.org/Members/fdrake/DateTimeWiki/SuggestedRequirements

Apparently, this proposal have been forgotten and reinvented again in msg106411, point 2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Sun Jun 13 19:07:17 2010
From: report at bugs.python.org (=?utf-8?q?Germ=C3=A1n_L=2E_Osella_Massa?=)
Date: Sun, 13 Jun 2010 17:07:17 +0000
Subject: [issue8985] String format() has problems parsing numeric indexes
In-Reply-To: <1276373641.02.0.137473124387.issue8985@psf.upfronthosting.co.za>
Message-ID: <1276448837.3.0.312722428561.issue8985@psf.upfronthosting.co.za>


Germ?n L. Osella Massa <gosella at gmail.com> added the comment:

I now see the rationale behind not accepting ' 10 ' == 10. But what about not accepting '-1' == -1?

I think is odd that negative numbers are not accepted as valid indexes. I'd expect that something like 

"First element is {0[0]} and last element is {0[-1]}".format([0,1,2,3])

would work but it didn't.

Should I create a new Issue requesting this as a new feature? Or could be reconsidered as a bug?

I could provide a simple patch that change get_integer() so it would accept negative integers as a valid number.

(This is the first issue I reported and English is not my native language so I apology for any mistake that I made)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8985>
_______________________________________

From report at bugs.python.org  Sun Jun 13 19:17:29 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 13 Jun 2010 17:17:29 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1276449449.36.0.327585175555.issue7370@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Agreed.
Attaching the unit test.

----------
Added file: http://bugs.python.org/file17656/test_httpserver.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Sun Jun 13 19:45:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Jun 2010 17:45:07 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1276449449.36.0.327585175555.issue7370@psf.upfronthosting.co.za>
Message-ID: <4C15191F.9060808@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

The skeleton is good but you have to change one thing. Your test should
exercise a function or method of BaseHTTPServer, not the underlying
implementation detail. I failed to explain that earlier:

1a) Write a test that checks that the current code produces right values
for a handful of cases (perhaps the RFC has them, else pick at random);
1b) Check that the test pass with the current code;
2a) Change BaseHTTPServer to use emails.utils.formatdate;
2b) Check that the test still pass.

End of HOWTO write a regression test :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Sun Jun 13 20:18:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 13 Jun 2010 18:18:44 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276453124.35.0.302541902469.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

issue5094g.diff addresses all Mark's suggestions except making struct definition public.  I also made a few other changes:

1. Constructor now raises TypeError when offset is not a timedelta instead of ValueError in previous version.

2. NEWS entry no longer says that argument is ignored by tzinfo methods implemented in timezone.  (Since these methods now check the type of the argument, it would be misleading to say that arg is ignored.)

3. Added some more tests for error cases.

4. Added ACK for Rafe Kaplan as the author of the original patch.

----------
Added file: http://bugs.python.org/file17657/issue5094g.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Sun Jun 13 20:19:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 13 Jun 2010 18:19:51 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276453191.74.0.169907859659.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Also I changed Py_DECREFs in destructor to Py_CLEAR.  I understand that while not strictly required in this case, it is a good practice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Sun Jun 13 21:42:54 2010
From: report at bugs.python.org (Thomas Jollans)
Date: Sun, 13 Jun 2010 19:42:54 +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: <1276458174.59.0.784735349158.issue8990@psf.upfronthosting.co.za>


New submission from Thomas Jollans <thomas at jollans.com>:

Currently, the array constructor, if given a bytearray, detects this with PyByteArray_Check, and hands it on to array_fromstring, which does not support bytearray (by using "s#" with PyArg_ParseTuple) and raises TypeError.

>>> array('h', bytearray(b'xyxyxyxyxyxyxyxyxy'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be bytes or read-only buffer, not bytearray
>>>  


I see no reason to insist on read-only buffers. I'm attaching a patch that I think fixes this.

----------
components: Extension Modules, Library (Lib)
files: array.diff
keywords: patch
messages: 107744
nosy: tjollans
priority: normal
severity: normal
status: open
title: array constructor and array.fromstring should accept bytearray.
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17658/array.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8990>
_______________________________________

From report at bugs.python.org  Sun Jun 13 21:45:24 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 13 Jun 2010 19:45:24 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1276458324.89.0.748322156194.issue6560@psf.upfronthosting.co.za>


David Watson <baikie at users.sourceforge.net> added the comment:

New version with minor changes.  Will also upload at http://codereview.appspot.com/1487041/show

----------
Added file: http://bugs.python.org/file17659/baikie-hwundram-v4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Sun Jun 13 21:55:04 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 13 Jun 2010 19:55:04 +0000
Subject: [issue8972] subprocess.list2cmdline doesn't quote the & character
In-Reply-To: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>
Message-ID: <1276458904.81.0.89108511014.issue8972@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/issue8972>
_______________________________________

From report at bugs.python.org  Sun Jun 13 22:02:13 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 13 Jun 2010 20:02:13 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1276459333.34.0.2819129099.issue6560@psf.upfronthosting.co.za>


David Watson <baikie at users.sourceforge.net> added the comment:

Optional patch to replace SocketTCPTest, etc. with the classes from the sendmsg patch.

----------
Added file: http://bugs.python.org/file17660/v4-replace-existing-classes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Sun Jun 13 22:06:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 13 Jun 2010 20:06:20 +0000
Subject: [issue8592] 'y' does not check for embedded NUL bytes
In-Reply-To: <1272737075.21.0.258918022173.issue8592@psf.upfronthosting.co.za>
Message-ID: <1276459580.8.0.472649543705.issue8592@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited a bigger patch: r81973 not only fixes "y" format, but also "u" and "Z". It does also add a lot of tests in test_getargs2.py for many string formats (not all, eg. "es" is not tested).

Even if I consider this as a bugfix, I don't want to backport to 3.1 because it might break programs which rely on this strange behaviour.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8592>
_______________________________________

From report at bugs.python.org  Sun Jun 13 22:20:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 13 Jun 2010 20:20:15 +0000
Subject: [issue8949] PyArg_Parse*(): "z" should not accept bytes
In-Reply-To: <1276032203.54.0.364398342729.issue8949@psf.upfronthosting.co.za>
Message-ID: <1276460415.64.0.874392322107.issue8949@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Update the patch to update also the new tests that I added in r81973 (to fix #8592).

----------
Added file: http://bugs.python.org/file17661/pyarg_z_no_bytes-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8949>
_______________________________________

From report at bugs.python.org  Sun Jun 13 22:20:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 13 Jun 2010 20:20:19 +0000
Subject: [issue8949] PyArg_Parse*(): "z" should not accept bytes
In-Reply-To: <1276032203.54.0.364398342729.issue8949@psf.upfronthosting.co.za>
Message-ID: <1276460419.13.0.323237249789.issue8949@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17591/pyarg_z_no_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8949>
_______________________________________

From report at bugs.python.org  Sun Jun 13 22:37:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 13 Jun 2010 20:37:37 +0000
Subject: [issue8991] PyArg_Parse*() functions: reject discontinious buffers
In-Reply-To: <1276461457.35.0.826008906861.issue8991@psf.upfronthosting.co.za>
Message-ID: <1276461457.35.0.826008906861.issue8991@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

getbuffer() checks that the buffer is contiguous. "s#", "y", "z" formats use convertbuffer() which doesn't check that the buffer is contigious, as "w" and "w#" formats which call directly PyObject_GetBuffer() which extra check.

I don't think that the functions using these format support discontiguous buffers. I cannot check because I don't know how to create such buffer. It would be safer to reject discontigious buffer.

If a function would like to support discontigious buffer, it should use "O" format, call PyObject_GetBuffer() with the right option and do its own checks on the buffer object.

----------
components: Interpreter Core
messages: 107749
nosy: haypo
priority: normal
severity: normal
status: open
title: PyArg_Parse*() functions: reject discontinious buffers
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8991>
_______________________________________

From report at bugs.python.org  Sun Jun 13 22:45:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 13 Jun 2010 20:45:23 +0000
Subject: [issue8215] getargs.c in Python3 contains some TODO and the
	documentation is outdated
In-Reply-To: <1269383341.97.0.71915040037.issue8215@psf.upfronthosting.co.za>
Message-ID: <1276461923.55.0.586174517693.issue8215@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r81811 and r81923 improve Doc/c-api/arg.rst. I opened more specific issues to improve getargs code and documentation:
 - #8991: PyArg_Parse*() functions: reject discontinious buffers
 - #8926: getargs.c: release the buffer on error
 - #8952: Doc/c-api/arg.rst: fix documentation of number formats
 - #8949: PyArg_Parse*(): "z" should not accept bytes
 - #8951: PyArg_Parse*(): factorize code of 's' and 'z' formats, and 'u' and 'Z' formats	open
 - #8850: Remove "w" format of PyParse_ParseTuple()

I prefer to close this issue because it is too generic. All points of this issues can be found in the other issues or are already fixed by some commits.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8215>
_______________________________________

From report at bugs.python.org  Sun Jun 13 22:58:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Jun 2010 20:58:41 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1276462721.0.0.825313806498.issue8987@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Distutils is frozen, because even fixing blatant bugs breaks third-party code that relies on internals. Can you check your bug with a Distutils2 checkout from hg.python.org/distutils2?

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Sun Jun 13 23:09:33 2010
From: report at bugs.python.org (shypike)
Date: Sun, 13 Jun 2010 21:09:33 +0000
Subject: [issue8972] subprocess.list2cmdline doesn't quote the & character
In-Reply-To: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>
Message-ID: <1276463373.84.0.911437206495.issue8972@psf.upfronthosting.co.za>


shypike <shypike at sabnzbd.org> added the comment:

The discussion is going the wrong way. Let me state what is the actual problem.
When the Popen() function is called with "shell=True", you cannot pass command line elements in which the characters '&' and '|' are embedded (example r'Q&A'). list2cmdline should embed such elements in double quotes '"' in the same way as when a space is detected (so r'"Q&A"').
When '&' and '|' require their special meaning, they should be passed as separate elements (r'&') and in that case list2cmdline should not double-quote them.

The whole C++ discussion was only invoked because I said a potential work-around doesn't work because the way list2cmdline is designed. That remark is not relevant, because the actual problem is different.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8972>
_______________________________________

From report at bugs.python.org  Sun Jun 13 23:15:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 13 Jun 2010 21:15:33 +0000
Subject: [issue8992] convertsimple() doesn't need to call converterr() if an
	exception was already raised
In-Reply-To: <1276463733.12.0.346579334159.issue8992@psf.upfronthosting.co.za>
Message-ID: <1276463733.12.0.346579334159.issue8992@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

If convertitem() result is not NULL, an error occured and seterror() is called (by the function calling convertitem()). seterror() does nothing if an exception was raised (if PyErr_Occurred() is non zero).

convertitem() doesn't need to call converterr() if an exception occurred because the string formatted by converterr() will be ignored. We just need to return a non NULL pointer: msgbuf.

Attached patch creates a RETURN_ERR_OCCURRED macro. convertsimple() should be a little bit faster and the code is more readable. Details:
 - addcleanup() now takes a boolean to indicate if it's a buffer or a pointer to simplify the API and have to raise a special error if the destructor is unknown
 - don't check that the result of PyUnicode_AsEncodedString() is a bytes object: PyUnicode_AsEncodedString() does already check that

----------
components: Interpreter Core
files: getarg_err_occurred.patch
keywords: patch
messages: 107753
nosy: haypo
priority: normal
severity: normal
status: open
title: convertsimple() doesn't need to call converterr() if an exception was already raised
versions: Python 3.2
Added file: http://bugs.python.org/file17662/getarg_err_occurred.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8992>
_______________________________________

From report at bugs.python.org  Sun Jun 13 23:16:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 13 Jun 2010 21:16:11 +0000
Subject: [issue8969] Windows: use (mbcs in) strict mode to encode/decode
	filenames, and enable os.fsencode()
In-Reply-To: <1276216388.28.0.366593840574.issue8969@psf.upfronthosting.co.za>
Message-ID: <1276463771.16.0.402852644815.issue8969@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/issue8969>
_______________________________________

From report at bugs.python.org  Sun Jun 13 23:33:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Jun 2010 21:33:54 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276464834.55.0.846421849541.issue8912@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Here?s a quick crack at it. Conservative approach: Don?t reindent, just complain.

----------
keywords: +patch
nosy: +merwok
stage:  -> patch review
versions: +Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17663/check-tabs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Sun Jun 13 23:36:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 13 Jun 2010 21:36:22 +0000
Subject: [issue8850] Remove "w" format of PyParse_ParseTuple()
In-Reply-To: <1275099860.74.0.46695580149.issue8850@psf.upfronthosting.co.za>
Message-ID: <1276464982.06.0.0448986383391.issue8850@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"w#" is not only useless but also not used in py3k source code. "w" is also not used. Only "w*" is used by fnctl and socket modules.

The problem with w# is that the caller cannot "release" the buffer and so we cannot lock the buffer. I don't know exactly what happens if you get a pointer to a bytearray, release the GIL and then use it, whereas another thread modifies and/or destroys the bytearray object. (I suppose that something bad will happen, like a segfault)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8850>
_______________________________________

From report at bugs.python.org  Sun Jun 13 23:46:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Jun 2010 21:46:52 +0000
Subject: [issue8350] os.mkdir doc comment is incorrect
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1276465612.14.0.347093645655.issue8350@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: georg.brandl -> docs at python
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Mon Jun 14 00:00:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Jun 2010 22:00:00 +0000
Subject: [issue8602] documentation of bz2 module mildly erroneous
In-Reply-To: <1272870234.45.0.00658969889364.issue8602@psf.upfronthosting.co.za>
Message-ID: <1276466400.33.0.635854076678.issue8602@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?d remove the lines ?Specifically it does not define the :meth:`__enter__` and :meth:`__exit__` methods required by the :keyword:`with` statement?, since they add unnecessary length to a simple note.

Please provide one patch per branch, and diff from the top level of the checkout (see http://www.python.org/dev/patches/). Thanks!

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8602>
_______________________________________

From report at bugs.python.org  Mon Jun 14 00:01:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Jun 2010 22:01:18 +0000
Subject: [issue8602] documentation of bz2 module mildly erroneous
In-Reply-To: <1272870234.45.0.00658969889364.issue8602@psf.upfronthosting.co.za>
Message-ID: <1276466478.09.0.0633210460922.issue8602@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Also, don?t bother with 3.0: It is not supported by python-dev anymore. Make documentation patches for py3k and trunk, and they?ll be backported to the stable branches 3.1 and 2.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8602>
_______________________________________

From report at bugs.python.org  Mon Jun 14 00:08:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Jun 2010 22:08:35 +0000
Subject: [issue8538] Add ConfigureAction to argparse
In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za>
Message-ID: <1276466915.09.0.807195856737.issue8538@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think you can go ahead and produce a patch. Don?t start splitting argparse into a package now though, this is a sensible decision IMO but has to be agreed by the maintainer; just add FlagAction and ConfigureAction to argparse for now.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8538>
_______________________________________

From report at bugs.python.org  Mon Jun 14 00:13:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Jun 2010 22:13:58 +0000
Subject: [issue8814] functools.WRAPPER_ASSIGNMENTS should include
	__annotations__
In-Reply-To: <1274736059.05.0.616257463555.issue8814@psf.upfronthosting.co.za>
Message-ID: <1276467238.92.0.779233237491.issue8814@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch looks good to me. Could you add some tests to Lib/test/test_functools.py to check that annotations are really copied?

(3.2 is not frozen, adjusting versions)

----------
stage:  -> unit test needed
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8814>
_______________________________________

From report at bugs.python.org  Mon Jun 14 00:16:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Jun 2010 22:16:17 +0000
Subject: [issue8653] urlparse.urlparse/urlsplit doc missing
In-Reply-To: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>
Message-ID: <1276467377.77.0.781904683976.issue8653@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Dave, can you explain your problem with a quote or a file name and line number, or directly propose a doc patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8653>
_______________________________________

From report at bugs.python.org  Mon Jun 14 00:21:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Jun 2010 22:21:35 +0000
Subject: [issue8925] Improve c-api/arg.rst: use "bytes" or "str" types instead
	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1276467695.38.0.385542653494.issue8925@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

haypo, I was not speaking about documenting the buffer protocol in general, but reacting to this specific change in your patch/commit:

-   buffer protocol (such as :class:`bytes` or :class:`bytearray` objects).
+   buffer protocol.

Before the commit, the term ?buffer protocol? was explained by the two examples with links, but now there?s neither link nor example, which is arguably a doc regression <wink>.

----------
title: Improve c-api/arg.rst: use "bytes" or "str" types instead	of "string" -> Improve c-api/arg.rst: use "bytes" or "str" types instead of "string"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8925>
_______________________________________

From report at bugs.python.org  Mon Jun 14 00:30:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Jun 2010 22:30:18 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276468218.94.0.307863960392.issue8912@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/issue8912>
_______________________________________

From report at bugs.python.org  Mon Jun 14 00:40:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Jun 2010 22:40:46 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276468846.29.0.986849719732.issue8912@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Updating patch to check header files too. Untested.

----------
Added file: http://bugs.python.org/file17664/check-tabs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Mon Jun 14 00:47:38 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 13 Jun 2010 22:47:38 +0000
Subject: [issue8930] messed up formatting after reindenting
In-Reply-To: <1275862117.51.0.974367285734.issue8930@psf.upfronthosting.co.za>
Message-ID: <1276469258.26.0.193487125336.issue8930@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

The following command (in bash shell) shows more files:
find -name '*.[ch]' -exec grep -El $'^\t' {} \;

I think that internal copies of libffi should be ignored.

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8930>
_______________________________________

From report at bugs.python.org  Mon Jun 14 00:59:11 2010
From: report at bugs.python.org (Sindre Myren)
Date: Sun, 13 Jun 2010 22:59:11 +0000
Subject: [issue5220] os.makedirs' mode argument has bad default value
In-Reply-To: <1234384571.02.0.296749790343.issue5220@psf.upfronthosting.co.za>
Message-ID: <1276469951.42.0.970816434763.issue5220@psf.upfronthosting.co.za>


Sindre Myren <smyrman at gmail.com> added the comment:

I have to agree with jab. While the way relative paths works are more or less common knowledge, the way umask does and does not work in relation to python isn't.

It is however given a short description at http://docs.python.org/library/os.html#os.makedirs:
...The default mode is 0777 (octal). On some systems, mode is ignored. Where it is used, the current umask value is first masked out.

And as it is documented (briefly) online that the umask *is* used, perhaps it is not necessary to add it to the doc-string?

----------
nosy: +smyrman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5220>
_______________________________________

From report at bugs.python.org  Mon Jun 14 01:47:16 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 13 Jun 2010 23:47: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: <1276472836.57.0.416086104932.issue7951@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Mon Jun 14 01:48:58 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 13 Jun 2010 23:48:58 +0000
Subject: [issue8985] String format() has problems parsing numeric indexes
In-Reply-To: <1276373641.02.0.137473124387.issue8985@psf.upfronthosting.co.za>
Message-ID: <1276472938.86.0.978292726596.issue8985@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'll consider this a duplicate. Issue 7951 is the existing feature request for this issue. I'll merge the nosy lists.

----------
resolution: rejected -> duplicate
superseder:  -> Should str.format allow negative indexes when used for __getitem__ access?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8985>
_______________________________________

From report at bugs.python.org  Mon Jun 14 01:49:49 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 13 Jun 2010 23:49:49 +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: <1276472989.52.0.13681782806.issue7951@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Closed issue 8985 as a duplicate of this; merging nosy lists.

----------
nosy: +gosella, mark.dickinson, merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Mon Jun 14 01:50:42 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 13 Jun 2010 23:50:42 +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: <1276473042.57.0.723698895975.issue7951@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Mon Jun 14 02:52:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Jun 2010 00:52:08 +0000
Subject: [issue8989] email.utils.make_msgid: specify domain
In-Reply-To: <1276442137.97.0.787561293748.issue8989@psf.upfronthosting.co.za>
Message-ID: <1276476728.14.0.0543070597484.issue8989@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This does seem like a reasonable (and backward compatible) addition to the API.  I'm only +0 on adding it, though, without at least one specific use case.  I'd want to mention that use case in the docs as an example, and stress that using the default is recommended unless you've got a good reason to do otherwise ("such as....").

Adrian, what use case(s) do you have in mind?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8989>
_______________________________________

From report at bugs.python.org  Mon Jun 14 02:52:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Jun 2010 00:52:29 +0000
Subject: [issue8989] email.utils.make_msgid: specify domain
In-Reply-To: <1276442137.97.0.787561293748.issue8989@psf.upfronthosting.co.za>
Message-ID: <1276476749.32.0.227600048228.issue8989@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/issue8989>
_______________________________________

From report at bugs.python.org  Mon Jun 14 02:59:52 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 14 Jun 2010 00:59:52 +0000
Subject: [issue8972] subprocess.list2cmdline doesn't quote the & character
In-Reply-To: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>
Message-ID: <1276477192.43.0.57481927169.issue8972@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

> That remark is not relevant, because the actual problem is different.

Maybe you can expand the test case to demonstrate the actual problem?  The tests in the latest patch are for list2cmdline directly.  But you can't observe the problem a bug in list2cmdline causes until you actually try to launch a child process.  So perhaps the test should do that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8972>
_______________________________________

From report at bugs.python.org  Mon Jun 14 03:55:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Jun 2010 01:55:23 +0000
Subject: [issue8972] subprocess.list2cmdline doesn't quote the & character
In-Reply-To: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>
Message-ID: <1276480523.5.0.651969137738.issue8972@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The actual bug here is that list2cmdline is called when shell=True and a list is passed.  This should not be done.  Instead, Popen should raise an TypeError (see issue 7839).

When calling Popen with shell=True, you should be passing in a string that is already correctly quoted.  This is how it works in Unix, and is how it should work in Windows as well.

So I agree with exarkun's comments in msg107679, and I think Gregory's fix in r60115 for issue 1300 was incorrect and that in fact the OP was correct that he did not understand what was happening (note that he did not report an actual bug, he just reported that the code looked wrong to him).

----------
nosy: +gregory.p.smith, r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> pending
superseder:  -> Popen should raise ValueError if pass a string when shell=False or a list when shell=True

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8972>
_______________________________________

From report at bugs.python.org  Mon Jun 14 03:56:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Jun 2010 01:56:51 +0000
Subject: [issue7839] Popen should raise ValueError if pass a string when
	shell=False or a list when shell=True
In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za>
Message-ID: <1276480611.99.0.890620380976.issue7839@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See issue 8972 for motivation for accepting this proposal.  Maybe I should start working on the patch :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7839>
_______________________________________

From report at bugs.python.org  Mon Jun 14 06:58:37 2010
From: report at bugs.python.org (flashk)
Date: Mon, 14 Jun 2010 04:58:37 +0000
Subject: [issue8993] Small typo in docs for PySys_SetArgv
In-Reply-To: <1276491516.78.0.349550856551.issue8993@psf.upfronthosting.co.za>
Message-ID: <1276491516.78.0.349550856551.issue8993@psf.upfronthosting.co.za>


New submission from flashk <flashk at gmail.com>:

The docs for PySys_SetArgv say:

"This function works like PySys_SetArgv() with updatepath set to 1."

I believe it should be "PySys_SetArgvEx".

I've attached a patch.

----------
assignee: docs at python
components: Documentation
files: init.rst.patch
keywords: patch
messages: 107771
nosy: docs at python, flashk
priority: normal
severity: normal
status: open
title: Small typo in docs for PySys_SetArgv
versions: Python 2.7
Added file: http://bugs.python.org/file17665/init.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8993>
_______________________________________

From report at bugs.python.org  Mon Jun 14 07:09:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Jun 2010 05:09:16 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1276492156.12.0.66329123798.issue8987@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note that list2cmdline does correct quoting (which includes the "s) if you are passing the string directly to a program.  In that case cmd.exe's metacharacters aren't special.  (As I noted in issue 8972, I believe that list2cmdline's current quoting of '|' characters is in error).

Perhaps a canonical list2cmdline actually belongs in shutil?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Mon Jun 14 07:12:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Jun 2010 05:12:43 +0000
Subject: [issue8988] import + coding = failure (3.1.2/win32)
In-Reply-To: <1276426235.15.0.873898512927.issue8988@psf.upfronthosting.co.za>
Message-ID: <1276492363.46.0.344330651309.issue8988@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/issue8988>
_______________________________________

From report at bugs.python.org  Mon Jun 14 07:13:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Jun 2010 05:13:18 +0000
Subject: [issue8988] import + coding = failure (3.1.2/win32)
In-Reply-To: <1276426235.15.0.873898512927.issue8988@psf.upfronthosting.co.za>
Message-ID: <1276492398.44.0.378658649912.issue8988@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components: +Interpreter Core -None
stage:  -> unit test needed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8988>
_______________________________________

From report at bugs.python.org  Mon Jun 14 07:44:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Jun 2010 05:44:03 +0000
Subject: [issue5220] os.makedirs' mode argument has bad default value
In-Reply-To: <1234384571.02.0.296749790343.issue5220@psf.upfronthosting.co.za>
Message-ID: <1276494243.45.0.796154364878.issue5220@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't understand what you mean when you say "how umask works in relation to Python".  How it works in relation to Python isn't different from how it works for any other Unix program.  Consider, for example, the unix man page for 'open'.

I don't think a docstring change is called for; the docstrings are brief summaries to act as memory aids, the real docs are the docs.  If someone does want to propose such a change they should open a new issue.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5220>
_______________________________________

From report at bugs.python.org  Mon Jun 14 11:13:57 2010
From: report at bugs.python.org (Torsten Landschoff)
Date: Mon, 14 Jun 2010 09:13:57 +0000
Subject: [issue8994] pydoc does not support non-ascii docstrings
In-Reply-To: <1276506836.98.0.338188119331.issue8994@psf.upfronthosting.co.za>
Message-ID: <1276506836.98.0.338188119331.issue8994@psf.upfronthosting.co.za>


New submission from Torsten Landschoff <t.landschoff at gmx.net>:

With the attached file doc.py I see the following behaviour:

torsten at ddhp3:~$ pydoc doc
Traceback (most recent call last):
  File "/usr/bin/pydoc", line 5, in <module>
    pydoc.cli()
  File "/usr/lib/python2.6/pydoc.py", line 2309, in cli
    help.help(arg)
  File "/usr/lib/python2.6/pydoc.py", line 1773, in help
    elif request: doc(request, 'Help on %s:')
  File "/usr/lib/python2.6/pydoc.py", line 1516, in doc
    pager(render_doc(thing, title, forceload))
  File "/usr/lib/python2.6/pydoc.py", line 1323, in pager
    pager(text)
  File "/usr/lib/python2.6/pydoc.py", line 1343, in <lambda>
    return lambda text: pipepager(text, 'less')
  File "/usr/lib/python2.6/pydoc.py", line 1364, in pipepager
    pipe.write(text)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 184-186: ordinal not in range(128)

With the terminal on sys.stdout I get "UTF-8" as the encoding (sys.stdout.encoding), therefore I would expect this to work. It would be helpful to have an option to set the encoding when running pydoc as well.

And, of course, accessing the documentation via a web browser (pydoc -p 8000, firefox http://localhost:8000) I get a blank screen for the doc.py example. And a backtrace on the terminal where I started pydoc.

----------
components: Unicode
files: doc.py
messages: 107774
nosy: torsten
priority: normal
severity: normal
status: open
title: pydoc does not support non-ascii docstrings
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17666/doc.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8994>
_______________________________________

From report at bugs.python.org  Mon Jun 14 11:53:32 2010
From: report at bugs.python.org (Bob)
Date: Mon, 14 Jun 2010 09:53:32 +0000
Subject: [issue8995] Performance issue with multiprocessing queue (3.1 VS 2.6)
In-Reply-To: <1276509212.88.0.604196007502.issue8995@psf.upfronthosting.co.za>
Message-ID: <1276509212.88.0.604196007502.issue8995@psf.upfronthosting.co.za>


New submission from Bob <for_elise03 at yahoo.fr>:

Hi,

I've found a strange performance issue when comparing queue.queue and multiprocessing.queue in python 2.6 and 3.1

My program creates a queue, and do 1 million put and get operations on either a small data or a "big" array.

My code: (This is the 3.1 version. Switch module name from queue to Queue to run on 2.6)

####################################################################
import multiprocessing
import queue

def with_queue(queuetype,datatype):
    if queuetype == 'multi':
        q = multiprocessing.Queue(1000)
    else:
        q = queue.Queue(1000)

    if datatype == 'small':
        data = 'some data'
    else:
        data = []
        for i in range(1000):
            data.append(i)
           
    for d in range(1000000):
        q.put(data)
        q.get()
       
if __name__=='__main__':
    from timeit import Timer
    t1 = Timer("with_queue('simple','small')","from __main__ import with_queue")
    t2 = Timer("with_queue('simple','big')","from __main__ import with_queue")
    t3 = Timer("with_queue('multi','small')","from __main__ import with_queue")
    t4 = Timer("with_queue('multi','big')","from __main__ import with_queue")
   
    print ('Using queue.Queue with small data            : ',t1.timeit(1))
    print ('Using queue.Queue with huge data             : ',t2.timeit(1))
    print ('Using multiprocessing.Queue with small data  : ',t3.timeit(1))
    print ('Using multiprocessing.Queue with huge  data  : ',t4.timeit(1))
#####################################################################

And the results (on my linux box:)

python2.6 read_write.py
    Using queue.Queue with small data            :  10.31s
    Using queue.Queue with huge data             :  10.39s
    Using multiprocessing.Queue with small data  :  33.85s
    Using multiprocessing.Queue with huge  data  :  155.38s

python3.1 read_write.py
    Using queue.Queue with small data            :  10.68s
    Using queue.Queue with huge data             :  10.61s
    Using multiprocessing.Queue with small data  :  50.27s
    Using multiprocessing.Queue with huge  data  :  472.49s


As you can see 3.1 is 50% slower than 2.6 in the third test; but 300 % slower in the 4th test.
If i go further with bigger data, 3.1 run for hours ... and i have to kill it before any result shows.
Am i doing something wrong or is there any known issue in 3.1 that can explain this ?

Thanks !

Bob

----------
components: Extension Modules
messages: 107775
nosy: bob
priority: normal
severity: normal
status: open
title: Performance issue with multiprocessing queue (3.1 VS 2.6)
type: performance
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8995>
_______________________________________

From report at bugs.python.org  Mon Jun 14 12:01:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Jun 2010 10:01:48 +0000
Subject: [issue8995] Performance issue with multiprocessing queue (3.1 VS 2.6)
In-Reply-To: <1276509212.88.0.604196007502.issue8995@psf.upfronthosting.co.za>
Message-ID: <1276509708.6.0.406150184184.issue8995@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> jnoller
nosy: +jnoller
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8995>
_______________________________________

From report at bugs.python.org  Mon Jun 14 12:57:42 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 14 Jun 2010 10:57:42 +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: <1276513062.86.0.300881972719.issue7951@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I (reluctantly) agree it's surprising that "{0[-1]}".format(args) fails.  And I suppose that if it were allowed then it would also make sense to consider "{-1}".format(*args) as well, in order to preserve the equivalence between "{n}".format(*args) and "{0[n]}".format(args).  And then:

>>> "{-0}".format(*['calvin'], **{'-0': 'hobbes'})
'hobbes'

would presumably produce 'calvin' instead of 'hobbes'...

On '+': if "{0[-1]}" were allowed, I'm not sure whether the "+1" in "{0[+1]}".format(...) should also be interpreted as a list index.  I don't really see the value of doing so apart from syntactic consistency: there are very few other places in Python that I'm aware of that accept -<one-or-more-digits> but not +<one-or-more-digits>.

FWIW, my overall feeling is that the current rules are simple and adequate, and there's no great need to add this complication.

I do wonder, though:

How complicated would it be to make "{0[1]}".format({'1':'foo'}) a bit magical?  That is, have the format method pass an integer to __getitem__ if the corresponding format argument is a sequence, and a string argument if it's a mapping (not sure what the criterion would be for distinguishing).  Is this too much magic?  Is it feasible implementation-wise?

I don't think it's do-able for simple rather than compound field names: e.g.,  "{0}".format(*args, **kwargs), since there we've got both a sequence *and* a dict, so it's not clear whether to look at args[0] or kwargs['0']. (Unless either args or kwargs is empty, perhaps.)  This is all getting a bit python-ideas'y, though.

BTW, I notice that PEP 3101's "Simple field names are either names or numbers [...] if names, they must be valid Python identifiers" isn't actually true:

>>> "{in-valid #identifier}".format(**{'in-valid #identifier': 42})
'42'

Though I don't have a problem with this;  indeed, I think this is preferable to checking for a valid identifier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Mon Jun 14 13:05:22 2010
From: report at bugs.python.org (Sworddragon)
Date: Mon, 14 Jun 2010 11:05:22 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1276513522.35.0.833018591307.issue7936@psf.upfronthosting.co.za>


Sworddragon <sworddragon2 at aol.com> added the comment:

I have set now the key to "E:\Python31\python.exe" "%%1" %%* and it works. So Windows XP need double % too. The installer of the next version should consider this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Mon Jun 14 13:11:23 2010
From: report at bugs.python.org (Sworddragon)
Date: Mon, 14 Jun 2010 11:11:23 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1276513883.15.0.949186562929.issue7936@psf.upfronthosting.co.za>


Sworddragon <sworddragon2 at aol.com> added the comment:

I made a mistake in the last post. After I have set the value, Python 2 was active and I forgot to set it to Python 3 back. This solution doesn't work. Well, I can't edit or delete the post.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Mon Jun 14 13:11:37 2010
From: report at bugs.python.org (Adrian von Bidder)
Date: Mon, 14 Jun 2010 11:11:37 +0000
Subject: [issue8989] email.utils.make_msgid: specify domain
In-Reply-To: <1276442137.97.0.787561293748.issue8989@psf.upfronthosting.co.za>
Message-ID: <1276513897.64.0.829144771696.issue8989@psf.upfronthosting.co.za>


Adrian von Bidder <avbidder at fortytwo.ch> added the comment:

Thanks for the positive feedback. I'll try to do the diff against top of tree and the unit test soon-ish.

Use case: 
 * In my specific case, I'm writing a sort of cross between mailing list and blog system and I'd like to use a static (across all installations) domain for internally generated messages.
 * kmail offers the choice of custom domain for message-id as well, I've set it to my own domain for ages.  It turns out that message-ids are harvested by spammers and so I've got a quite good way to build spamtraps since "nobody" will ever try to send real email to these "adresses". (Or, in the reverse case: if your host's fqdn is a valid email domain you may actually not want to cause this kind of load to your MX.)

(Not sure if this should be added to the documentation, though.  The explanation seems much too long in comparision with the complexity of the feature.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8989>
_______________________________________

From report at bugs.python.org  Mon Jun 14 13:22:40 2010
From: report at bugs.python.org (Sworddragon)
Date: Mon, 14 Jun 2010 11:22:40 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1276514560.6.0.236656566405.issue7936@psf.upfronthosting.co.za>


Sworddragon <sworddragon2 at aol.com> added the comment:

Now I found the real solution (and don't forgot to set it to Python 3 back). I have searched in the registry for python.exe to look how Python 2 is doing this. I sawed a key that looks dissimilar to the others before. It is the key HKEY_USERS\S-1-5-21-1078081533-682003330-1801674531-1003\Software\Classes\Applications\python.exe\shell\open\command which have the Standard value of "E:\Python31\python.exe" "%1". I set it to "E:\Python31\python.exe" "%1" %* and it worked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Mon Jun 14 13:23:36 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 14 Jun 2010 11:23:36 +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: <1276514616.24.0.921028513458.issue7951@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Addressing just the last part of Mark's message right now:

The PEP goes on to say:
    Implementation note: The implementation of this proposal is
    not required to enforce the rule about a simple or dotted name
    being a valid Python identifier.  ...

I rely on getattr lookup failing for dotted names, but for simple names there's no check at all. I agree it's desirable to leave this behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Mon Jun 14 13:27:28 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 14 Jun 2010 11:27:28 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1276514848.3.0.642087854783.issue7936@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

So the real question is is: how does that key get that invalid value? I can't reproduce the problem.

I believe that key you mention is an alias for HKEY_CURRENT_USER\Software\Classes\Applications\python.exe\shell\open\command, which doesn't exist on my XP machine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Mon Jun 14 13:50:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 11:50:15 +0000
Subject: [issue8988] import + coding = failure (3.1.2/win32)
In-Reply-To: <1276426235.15.0.873898512927.issue8988@psf.upfronthosting.co.za>
Message-ID: <1276516215.37.0.678869299525.issue8988@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This bug is maybe related to #8611?

Can you try with py3k (python 3.2)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8988>
_______________________________________

From report at bugs.python.org  Mon Jun 14 13:53:19 2010
From: report at bugs.python.org (Sworddragon)
Date: Mon, 14 Jun 2010 11:53:19 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1276516399.19.0.574527095034.issue7936@psf.upfronthosting.co.za>


Sworddragon <sworddragon2 at aol.com> added the comment:

I have now uninstalled Python 2 and 3 and installed them new. First Python 2 with only register extension and compile files to bytecode. After this I have made the same with Python 3. In the "Open with" menu was now "python" registered which was Python 3 (sys.version[0] from a testscript telled it me). Until this point the arguments were accepted. After this I have added the python.exe from Python 2 to the "Open with" menu. This was the point where the key got invalid. Now Python 3 is working correctly but not Python 2. Well, I can manually use now the workarround to fix it but maybe the problem can be solved with this information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Mon Jun 14 14:02:02 2010
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 14 Jun 2010 12:02:02 +0000
Subject: [issue8995] Performance issue with multiprocessing queue (3.1 VS 2.6)
In-Reply-To: <1276509212.88.0.604196007502.issue8995@psf.upfronthosting.co.za>
Message-ID: <1276516922.98.0.505686484837.issue8995@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

No - I don't know of anything which would trigger this in 3.1 off the top of my head. The performance degradation is pretty worrisome

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8995>
_______________________________________

From report at bugs.python.org  Mon Jun 14 15:37:54 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 14 Jun 2010 13:37:54 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276522674.96.0.481005969931.issue5094@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

issue5904g.diff looks good to me.  A very nice piece of work!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Mon Jun 14 16:21:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 14 Jun 2010 14:21:21 +0000
Subject: [issue5094] datetime lacks concrete tzinfo implementation for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276525281.26.0.251482995257.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r81981.  I'll open a separate documentation issue to update Doc/includes/tzinfo-examples.py and improve TZ related documentation.

----------
stage: patch review -> committed/rejected
status: open -> closed
title: datetime lacks concrete tzinfo impl. for UTC -> datetime lacks concrete tzinfo implementation for UTC

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Mon Jun 14 16:24:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 14 Jun 2010 14:24:47 +0000
Subject: [issue2397] Backport 3.0 struct module changes to 2.6
In-Reply-To: <1205856299.38.0.249134952512.issue2397@psf.upfronthosting.co.za>
Message-ID: <1276525487.48.0.777618472075.issue2397@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It's too late to backport any new features to 2.x.

----------
nosy: +mark.dickinson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2397>
_______________________________________

From report at bugs.python.org  Mon Jun 14 16:30:49 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 14 Jun 2010 14:30:49 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1276525849.42.0.296492871495.issue3163@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Mon Jun 14 16:34:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 14 Jun 2010 14:34:05 +0000
Subject: [issue1749662] New byte packing format for the struct module
Message-ID: <1276526045.32.0.760725644476.issue1749662@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1749662>
_______________________________________

From report at bugs.python.org  Mon Jun 14 16:35:08 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 14 Jun 2010 14:35:08 +0000
Subject: [issue2981] confusing action of struct.pack and struct.unpack with
	fmt 'p'
In-Reply-To: <1211903770.4.0.523120419892.issue2981@psf.upfronthosting.co.za>
Message-ID: <1276526108.83.0.512207176042.issue2981@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/issue2981>
_______________________________________

From report at bugs.python.org  Mon Jun 14 16:36:20 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 14 Jun 2010 14:36:20 +0000
Subject: [issue2263] struct.pack() + numpy int raises SystemError
In-Reply-To: <1205134764.8.0.415620235375.issue2263@psf.upfronthosting.co.za>
Message-ID: <1276526180.04.0.00209478606578.issue2263@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/issue2263>
_______________________________________

From report at bugs.python.org  Mon Jun 14 17:05:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 14 Jun 2010 15:05:00 +0000
Subject: [issue2981] confusing action of struct.pack and struct.unpack with
	fmt 'p'
In-Reply-To: <1211903770.4.0.523120419892.issue2981@psf.upfronthosting.co.za>
Message-ID: <1276527900.63.0.467417701584.issue2981@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think you're misunderstanding how the 'p' format works.

> Otherwise, why people should use format 'p'?
> Either when you struct.pack or struct.unpack you have to know the size
> of string at first, why not turn to format 's'?

No;  you don't need to know the size of the string beforehand;  you just need to know the *maximum* size of the string;  the number of bytes allocated to store that string.  For example (Python 2.6):

>>> import struct
>>> s = struct.Struct('20p')  # variable-length string stored in 20 bytes
>>> s.pack('abc')
'\x03abc\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
>>> s.unpack(_)
('abc',)
>>> s.pack('abcdef')
'\x06abcdef\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
>>> s.unpack(_)
('abcdef',)

Note that the packed sizes are the same (20 bytes each time), but you can pack and unpack any (byte)string of length up to 19 bytes, without needing to know its length beforehand.

Handling true variable-length fields is really outside the scope of the struct module.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2981>
_______________________________________

From report at bugs.python.org  Mon Jun 14 17:09:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Jun 2010 15:09:12 +0000
Subject: [issue8996] Add a default role to allow writing bare `len` instead of
	:func:`len`
In-Reply-To: <1276528152.92.0.60611534239.issue8996@psf.upfronthosting.co.za>
Message-ID: <1276528152.92.0.60611534239.issue8996@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Following a discussion on IRC:

<birkenfeld> I would even prefer having more of just `object` instead of :func:`object` or :class:`object`

I think it would be feasible to write a reST role that would use inspect or pydoc to find the type. It would not violate ?In the face of ambiguity, refuse the temptation to guess? if it only resolves `somebuiltin` and `some.fully.qualified.name`.

Cons: People unfamiliar with reST might confuse ``code`` with `name`; interpreting the role may prove non-trivial (either requiring importing Python module to introspect them, or keeping a mapping of names?types in some file).

Thoughts?

----------
assignee: docs at python
components: Documentation
messages: 107790
nosy: docs at python, merwok
priority: normal
severity: normal
status: open
title: Add a default role to allow writing bare `len` instead of :func:`len`
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8996>
_______________________________________

From report at bugs.python.org  Mon Jun 14 17:14:20 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 14 Jun 2010 15:14:20 +0000
Subject: [issue1749662] New byte packing format for the struct module
Message-ID: <1276528460.85.0.778549526855.issue1749662@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Is this still of interest to anyone?

What's the motivation for this particular choice (bigendian byteorder, native size, native alignment), out of all the various other choices that aren't currently implemented?

PEP 3118 also proposes the addition of a new format, '^', for (native byteorder, native size, no alignment).

There are 12 possible different formats (big/little/native byteorder * standard/native size * none/native padding), of which 4 are currently implemented (native**3, big*standard*none, little*standard*none, native*standard*none).  Of the 8 missing formats, it's not clear to me why either of the new proposed formats should be a particular target.

BTW, not that it really matters, but I've earmarked '$' for a different use, so I'm mildly opposed to its use here.

----------
nosy: +minge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1749662>
_______________________________________

From report at bugs.python.org  Mon Jun 14 17:26:44 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 14 Jun 2010 15:26:44 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1276529204.52.0.473095153146.issue3163@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Mon Jun 14 17:31:01 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 14 Jun 2010 15:31:01 +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: <1276529461.63.0.159890101907.issue7951@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Re: msg107776.

If it looks like an integer (ie, can be converted to an integer by 'int') then it's positional, otherwise it's a key. An optimisation is to perform a quick check upfront to see whether it starts like an integer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Mon Jun 14 17:32:49 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 14 Jun 2010 15:32:49 +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: <1276529569.89.0.0595103369746.issue7951@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Matthew:

would that include allowing whitespace, then?

>>> int('\t\n+56')
56

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Mon Jun 14 17:35:06 2010
From: report at bugs.python.org (sorin)
Date: Mon, 14 Jun 2010 15:35:06 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1276529706.85.0.44919621235.issue7475@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

I would like to know what happened with hex_codec and what is the new py3 for this.

Also, it would be really helpful to see DeprecationWarnings for all these codecs in py2x and include a note in py3 changelist. 

The official python documentation from http://docs.python.org/library/codecs.html lists them as valid without any signs of them as being dropped or replaced.

----------
nosy: +sorin
title: codecs missing: base64 bz2 hex zlib ... -> codecs missing: base64 bz2 hex zlib hex_codec ...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Mon Jun 14 17:56:55 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 14 Jun 2010 15:56:55 +0000
Subject: [issue8996] Add a default role to allow writing bare `len` instead of
	:func:`len`
In-Reply-To: <1276528152.92.0.60611534239.issue8996@psf.upfronthosting.co.za>
Message-ID: <1276531015.84.0.975704088723.issue8996@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The type doesn't matter anyway, no need to find it by questionable means.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8996>
_______________________________________

From report at bugs.python.org  Mon Jun 14 17:59:12 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 14 Jun 2010 15:59:12 +0000
Subject: [issue8993] Small typo in docs for PySys_SetArgv
In-Reply-To: <1276491516.78.0.349550856551.issue8993@psf.upfronthosting.co.za>
Message-ID: <1276531152.53.0.501397080258.issue8993@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r81984.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8993>
_______________________________________

From report at bugs.python.org  Mon Jun 14 18:09:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 14 Jun 2010 16:09:20 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276531760.37.0.553500659244.issue6641@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

With issue5094 patch now committed, I am replacing issue6641.diff with a new version that does not include issue5094.

----------
title: strptime doesn't support %z format ? -> datetime.strptime doesn't support %z format ?
Added file: http://bugs.python.org/file17667/issue6641.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Mon Jun 14 18:09:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 14 Jun 2010 16:09:27 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276531767.48.0.344890830056.issue6641@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17590/issue6641.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Mon Jun 14 18:45:34 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 14 Jun 2010 16:45:34 +0000
Subject: [issue8958] 2.7rc1 tarfile.py: `bltn_open(targetpath,
	"wb")` -> IOError: Is a directory
In-Reply-To: <1276118455.66.0.211402542637.issue8958@psf.upfronthosting.co.za>
Message-ID: <1276533934.15.0.668033349492.issue8958@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

I am curious as to why this should still "fail" as the OSX filesystem is case sensitive. Finder has no problems with extrating this particular tarball. Do you think this is a (separate) bug, or is this by design (why?)?

If this is by design, does it make sense to raise a custom exception from TarError, instead of the generic IOError?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8958>
_______________________________________

From report at bugs.python.org  Mon Jun 14 18:55:06 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 14 Jun 2010 16:55:06 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1276534506.66.0.207374384575.issue3163@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The proposed addition seems reasonable to me, for native packing and unpacking.

For standard mode packing and unpacking, I don't see the point;  we'd have to pick a standard size, which would almost certainly be either 4 or 8, and so would already be covered by either the 'iI' or the 'qQ' codes.  So I'd suggest adding the size_t/ssize_t codes only for native mode, and leaving them unsupported for the standard modes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Mon Jun 14 18:55:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 14 Jun 2010 16:55:36 +0000
Subject: [issue3163] module struct support for ssize_t and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1276534536.1.0.590917820635.issue3163@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

To avoid clashing with PEP 3118, we could use 'n' and 'N' instead of 'z' and 'Z'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3163>
_______________________________________

From report at bugs.python.org  Mon Jun 14 19:02:59 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 14 Jun 2010 17:02:59 +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: <1276534979.72.0.810994138843.issue7951@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

That's a good question. :-)

Possibly just an optional sign followed by one or more digits.

Another possibility that occurs to me is for it to default to positional if it looks like an integer, but allow quoting to force it to be a key:

>>> "{0}".format("foo", **{"0": "bar"})
'foo'
>>> "{'0'}".format("foo", **{"0": "bar"})
'bar'

Or is that taking it too far?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Mon Jun 14 19:18:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 14 Jun 2010 17:18:09 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1276535889.4.0.273637751473.issue6280@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The issue6280-calendar.diff patch looks good to me.

----------
assignee: mark.dickinson -> belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Mon Jun 14 19:43:01 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Mon, 14 Jun 2010 17:43:01 +0000
Subject: [issue8958] 2.7rc1 tarfile.py: `bltn_open(targetpath,
	"wb")` -> IOError: Is a directory
In-Reply-To: <1276118455.66.0.211402542637.issue8958@psf.upfronthosting.co.za>
Message-ID: <1276537381.37.0.626032333004.issue8958@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

a) The point is: the operation simply wouldn't fail on a case-sensitive filesystem. There is no platform-specific or otherwise special code in TarFile.makefile(). It simply tries to extract the file and the filesystem layer says no, because it believes there is already a directory with the same name. The same thing happens on a Windows filesystem BTW. The problem boils down to this:

>>> os.mkdir("A")
>>> open("a", "w")
IOError: [Errno 21] Is a directory: 'a'

And IIUC, the Mac OS X filesystem is case-preserving(!) by default, with the possibility to create new filesystems as case-sensitive. As I said, my Mac OS X expertise is almost nonexistent, you might as well ask someone with more knowledge on Python on Mac OS X.

b) I don't know what Finder does with that archive, but I cannot think of any other way than either not to extract the file at all or to extract it under a different name or to remove the directory first and then extract the file. Could you please examine how Finder extracts this archive?

c) IMHO the IOError exception is perfectly fine, because this kind of issue is outside of tarfile's scope. We hit a filesystem limit here. Also, there is no decent way to work around this problem, and I think there is no need to either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8958>
_______________________________________

From report at bugs.python.org  Mon Jun 14 19:43:50 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 14 Jun 2010 17:43:50 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1276537430.11.0.853701129609.issue6280@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed issue6280-calendar.diff in r81988.  I believe tests should be merged in 2.7.  Any objections?

As for the original RFE, I think it should be rejected.  I believe users should be encouraged to use datetime objects instead of timetuples and converting a UTC datetime to any kind of "since epoch" timestamp is very simple using datetime module arithmetics.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Mon Jun 14 19:56:46 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 14 Jun 2010 17:56:46 +0000
Subject: [issue8958] 2.7rc1 tarfile.py: `bltn_open(targetpath,
	"wb")` -> IOError: Is a directory
In-Reply-To: <1276537381.37.0.626032333004.issue8958@psf.upfronthosting.co.za>
Message-ID: <73DC5B7F-60B3-4D51-80EB-EF7A11B5CB9F@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On 2010-06-14, at 10:43 AM, Lars Gust?bel wrote:

> Lars Gust?bel <lars at gustaebel.de> added the comment:
> 
> a) The point is: the operation simply wouldn't fail on a case-sensitive filesystem. There is no platform-specific or otherwise special code in TarFile.makefile(). It simply tries to extract the file and the filesystem layer says no, because it believes there is already a directory with the same name. The same thing happens on a Windows filesystem BTW. The problem boils down to this:
> 
>>>> os.mkdir("A")
>>>> open("a", "w")
> IOError: [Errno 21] Is a directory: 'a'
> 
> And IIUC, the Mac OS X filesystem is case-preserving(!) by default, with the possibility to create new filesystems as case-sensitive. As I said, my Mac OS X expertise is almost nonexistent, you might as well ask someone with more knowledge on Python on Mac OS X.

Ah, I see. I didn't know about this compatibility quirk.

> b) I don't know what Finder does with that archive, but I cannot think of any other way than either not to extract the file at all or to extract it under a different name or to remove the directory first and then extract the file. Could you please examine how Finder extracts this archive?

I was wrong about Finder extracting the tarball; actually I used the Finder on my macbook (10.6), where `open("a", "w")` succeeds. Whereas this issue seems to be reproducible in 10.5 or 10.4 only.

I did try to use `tar` this time, and it failed:

$ tar zxf hntool-0.1.1.tar.gz 
tar: hntool-0.1.1/hntool: Cannot open: File exists
tar: Error exit delayed from previous errors

> c) IMHO the IOError exception is perfectly fine, because this kind of issue is outside of tarfile's scope. We hit a filesystem limit here. Also, there is no decent way to work around this problem, and I think there is no need to either.

In this case, yes ... I agree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8958>
_______________________________________

From report at bugs.python.org  Mon Jun 14 20:51:10 2010
From: report at bugs.python.org (Adrian von Bidder)
Date: Mon, 14 Jun 2010 18:51:10 +0000
Subject: [issue8989] email.utils.make_msgid: specify domain
In-Reply-To: <1276442137.97.0.787561293748.issue8989@psf.upfronthosting.co.za>
Message-ID: <1276541470.23.0.259787041153.issue8989@psf.upfronthosting.co.za>


Adrian von Bidder <avbidder at fortytwo.ch> added the comment:

I'm sure several of you have worked with the Python source code before and know by heart how to run the testsuite.  In other words: I admit that I've only written the code and have not tried it.

Given how trivial the patch is, I have some hope ;-)

----------
Added file: http://bugs.python.org/file17668/make_msgid-domain.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8989>
_______________________________________

From report at bugs.python.org  Mon Jun 14 21:02:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 19:02:44 +0000
Subject: [issue8838]
	Remove	codecs.readbuffer_encode()	and	codecs.charbuffer_encode()
In-Reply-To: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>
Message-ID: <1276542164.37.0.605263414666.issue8838@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue was about removing codecs.readbuffer_encode() and codecs.charbuffer_encode(). codecs.charbuffer_encode() was removed, but codecs.readbuffer_encode() explained that it should be kept. So I close this issue because there is nothing more to do on this topic.

@lemburg: You still have to write some doc (and tests?) for codecs.readbuffer_encode() ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Mon Jun 14 21:03:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 19:03:04 +0000
Subject: [issue8838]
	Remove	codecs.readbuffer_encode()	and	codecs.charbuffer_encode()
In-Reply-To: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>
Message-ID: <1276542184.11.0.393315225205.issue8838@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/issue8838>
_______________________________________

From report at bugs.python.org  Mon Jun 14 21:06:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 14 Jun 2010 19:06:10 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1276542370.42.0.16579047079.issue6280@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I reverted r81988 in r81989. Some code may rely on timegm() accepting float in tm_sec.  See http2time in Lib/http/cookiejar.py.

It is very easy to modify implementation to accept float seconds, but old implementation accidentally work for float hours and minutes as well.

----------
versions:  -Python 2.7
Added file: http://bugs.python.org/file17669/issue6280-calendar-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Mon Jun 14 21:18:40 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 14 Jun 2010 19:18:40 +0000
Subject: [issue8997] Write documentation for codecs.readbuffer_encode()
In-Reply-To: <1276543120.6.0.338687874276.issue8997@psf.upfronthosting.co.za>
Message-ID: <1276543120.6.0.338687874276.issue8997@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

See #8838 for details.

----------
assignee: lemburg
components: Documentation
messages: 107809
nosy: lemburg
priority: normal
severity: normal
status: open
title: Write documentation for codecs.readbuffer_encode()
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8997>
_______________________________________

From report at bugs.python.org  Mon Jun 14 21:19:24 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 14 Jun 2010 19:19:24 +0000
Subject: [issue8997] Write documentation for codecs.readbuffer_encode()
In-Reply-To: <1276543120.6.0.338687874276.issue8997@psf.upfronthosting.co.za>
Message-ID: <1276543164.74.0.352710343675.issue8997@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
components: +Unicode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8997>
_______________________________________

From report at bugs.python.org  Mon Jun 14 22:25:30 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 14 Jun 2010 20:25:30 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1276547130.88.0.233434262397.issue8857@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

FreeBSD/Qemu: ipv6 is ok, but this fails:

======================================================================
FAIL: testGetaddrinfo (__main__.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_socket.py", line 587, in testGetaddrinfo
    self.assertEqual(socktype, socket.SOCK_STREAM)
AssertionError: 2 != 1

----------------------------------------------------------------------
Ran 113 tests in 4.174s

FAILED (failures=1, skipped=79)
Traceback (most recent call last):
  File "Lib/test/test_socket.py", line 1530, in <module>
    test_main()
  File "Lib/test/test_socket.py", line 1526, in test_main
    support.run_unittest(*tests)
  File "/usr/home/stefan/svn/py3k/Lib/test/support.py", line 1054, in run_unittest
    _run_suite(suite)
  File "/usr/home/stefan/svn/py3k/Lib/test/support.py", line 1037, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_socket.py", line 587, in testGetaddrinfo
    self.assertEqual(socktype, socket.SOCK_STREAM)
AssertionError: 2 != 1

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Mon Jun 14 23:05:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 21:05:21 +0000
Subject: [issue8997] Write documentation for codecs.readbuffer_encode()
In-Reply-To: <1276543120.6.0.338687874276.issue8997@psf.upfronthosting.co.za>
Message-ID: <1276549521.35.0.0452777903387.issue8997@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/issue8997>
_______________________________________

From report at bugs.python.org  Mon Jun 14 23:20:30 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 14 Jun 2010 21:20:30 +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: <1276550430.45.0.21294332912.issue7951@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I can see the point of allowing negative indices for a consistency point, but is there really any practical problem that's currently causing people hardship that this would solve?

As for the rest of it, I think it's just not worth the additional burden on CPython and other implementations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Mon Jun 14 23:37:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 21:37:45 +0000
Subject: [issue8850] Remove "w" format of PyParse_ParseTuple()
In-Reply-To: <1275099860.74.0.46695580149.issue8850@psf.upfronthosting.co.za>
Message-ID: <1276551465.88.0.181243880235.issue8850@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New (improved) version of the patch:
 - Remove also "w#" format
 - Write tests for "w*" format

----------
Added file: http://bugs.python.org/file17670/remove_w_format-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8850>
_______________________________________

From report at bugs.python.org  Mon Jun 14 23:39:58 2010
From: report at bugs.python.org (geremy condra)
Date: Mon, 14 Jun 2010 21:39:58 +0000
Subject: [issue8998] add encryption/decryption/signature/verification routines
	to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>


New submission from geremy condra <debatem1 at gmail.com>:

Python's hashlib and ssl modules currently leverage OpenSSL to provide developers with access to cryptographic hash and TLS routines, but encryption/decryption and signature/verification support are still missing. I propose the addition of an easy-to-use crypto module modeled after Evpy[0] to remedy this.

----------
components: Library (Lib)
messages: 107813
nosy: debatem1
priority: normal
severity: normal
status: open
title: add encryption/decryption/signature/verification routines to stdlib
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Mon Jun 14 23:41:55 2010
From: report at bugs.python.org (geremy condra)
Date: Mon, 14 Jun 2010 21:41:55 +0000
Subject: [issue8998] add encryption/decryption/signature/verification routines
	to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1276551715.81.0.530599816858.issue8998@psf.upfronthosting.co.za>


geremy condra <debatem1 at gmail.com> added the comment:

apologies, forgot the link:

[0] http://gitorious.org/evpy

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Mon Jun 14 23:42:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Jun 2010 21:42:34 +0000
Subject: [issue8998] add encryption/decryption/signature/verification routines
	to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1276551754.32.0.768711114854.issue8998@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +exarkun, gregory.p.smith, pitrou
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Mon Jun 14 23:53:42 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 14 Jun 2010 21:53:42 +0000
Subject: [issue8918] distutils test failure on solaris: IOError: [Errno 2] No
	such file or directory: '_configtest.i'
In-Reply-To: <1275846660.59.0.731483262347.issue8918@psf.upfronthosting.co.za>
Message-ID: <1276552422.47.0.672081295596.issue8918@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

-bash-3.00$ cat _configtest.c 
// xxx
-bash-3.00$ 

-------------------------------------

This is how the C compiler is invoked:

$ cc -E -o _configtest.i _configtest.c  
# 1 "_configtest.c"
 
#ident "acomp: Sun C 5.9 SunOS_i386 2007/05/03"
$

It does not generate a _configtest.i file .. which is because the `-E` option on Solaris sends the preprocessed output directly to `stdout` without respecting the `-o` option. From "man cc",

     -E   Runs the source file through the preprocessor only and
          sends the output to stdout. The preprocessor is built
          directly into the compiler, except in -Xs mode, where
          /usr/ccs/lib/cpp is invoked. Includes the preprocessor
          line numbering information. See also -P option.

But the `-P` option does output to the .i file:

     -P   Preprocesses only the named C files and leaves the
          result in corresponding files suffixed .i.  The output
          will not contain any preprocessing line directives,
          unlike -E.

So the fix is to use `-P` instead of `-E` on Solaris. I see that `-E` is used in lib/python2.7/distutils/ccompiler.py .. around this line:

        else:
            cpp = cc + " -E"           # not always

Tarek, note the "not always" command above. At least, we now know that on Solaris this happens to be "-P".

The resulting .i file is:

-bash-3.00$ cat _configtest.i 
 
#ident "acomp: Sun C 5.9 SunOS_i386 2007/05/03"
-bash-3.00$ 

-------------------------------------

As for `cc` itself:

-bash-3.00$ which cc
/usr/bin/cc
-bash-3.00$ cc -V
cc: Sun C 5.9 SunOS_i386 2007/05/03
usage: cc [ options] files.  Use 'cc -flags' for details

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8918>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:09:15 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 14 Jun 2010 22:09:15 +0000
Subject: [issue8998] add encryption/decryption/signature/verification routines
	to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1276553355.35.0.268706279092.issue8998@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Assuming you are willing to contribute evpy (and have the rights to do so, i.e. all of the code is truly yours): what's the user acceptance of the code?

In particular, what do authors of competing OpenSSL wrappers (like M2Crypto) or other Python crypto packages (like pycrypto) think about this idea?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:12:37 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 14 Jun 2010 22:12:37 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276553557.14.0.411229602882.issue8912@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Thanks for the patch, ?ric. I will get to it when I can.

----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:12:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Jun 2010 22:12:41 +0000
Subject: [issue8998] add encryption/decryption/signature/verification routines
	to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1276553561.51.0.577770341689.issue8998@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +heikki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:14:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Jun 2010 22:14:42 +0000
Subject: [issue8998] add encryption/decryption/signature/verification routines
	to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1276553682.07.0.612577190474.issue8998@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> and have the rights to do so, i.e. all of the code is truly yours

Is it really required, or is a non-copyleft liberal license (MIT-like or BSD-like) enough?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:14:52 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 14 Jun 2010 22:14:52 +0000
Subject: [issue5094] datetime lacks concrete tzinfo implementation for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276553692.64.0.268971329825.issue5094@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Thanks for sticking with this, Alexander. I realized I was a slight pain to deal with on this one. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:14:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 22:14:58 +0000
Subject: [issue8991] PyArg_Parse*() functions: reject discontinious buffers
In-Reply-To: <1276461457.35.0.826008906861.issue8991@psf.upfronthosting.co.za>
Message-ID: <1276553698.24.0.148787908636.issue8991@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Write a patch. test_getargs2.py has now tests for many byte and unicode formats and so it can validate the patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file17671/reject_discontigious.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8991>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:26:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 14 Jun 2010 22:26:14 +0000
Subject: [issue8998] add encryption/decryption/signature/verification
	routines	to stdlib
In-Reply-To: <1276553682.07.0.612577190474.issue8998@psf.upfronthosting.co.za>
Message-ID: <4C16AC83.7080401@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> and have the rights to do so, i.e. all of the code is truly yours
>
> Is it really required, or is a non-copyleft liberal license (MIT-like or BSD-like) enough?

The contributor would have to sign a contributor agreement, giving the 
PSF the right to relicense under the PSF license (or anything they 
please to relicense under). If the contributor only has a BSD license 
(from his contributors), he has no right to contribute the code under 
the contributor agreement (i.e. he, himself, wouldn't have the right
to relicense).

----------
title: add encryption/decryption/signature/verification routines to stdlib -> add encryption/decryption/signature/verification routines	to stdlib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:27:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Jun 2010 22:27:18 +0000
Subject: [issue8998] add encryption/decryption/signature/verification
	routines	to stdlib
In-Reply-To: <4C16AC83.7080401@v.loewis.de>
Message-ID: <1276554434.3237.21.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The contributor would have to sign a contributor agreement, giving the 
> PSF the right to relicense under the PSF license (or anything they 
> please to relicense under). If the contributor only has a BSD license 
> (from his contributors), he has no right to contribute the code under 
> the contributor agreement (i.e. he, himself, wouldn't have the right
> to relicense).

I always forget about that :/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:27:53 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 14 Jun 2010 22:27:53 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1276554473.92.0.77583018745.issue8998@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
title: add encryption/decryption/signature/verification routines	to stdlib -> add crypto routines to stdlib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:28:51 2010
From: report at bugs.python.org (geremy condra)
Date: Mon, 14 Jun 2010 22:28:51 +0000
Subject: [issue8998] add encryption/decryption/signature/verification routines
	to stdlib
In-Reply-To: <1276553355.35.0.268706279092.issue8998@psf.upfronthosting.co.za>
Message-ID: <AANLkTilT7cHz4AIDOlNPSq4h0N88wNgtukAFb5-WADpr@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Mon, Jun 14, 2010 at 3:09 PM, Martin v. L?wis <report at bugs.python.org> wrote:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> Assuming you are willing to contribute evpy (and have the rights to do so, i.e. all of the code is truly yours): what's the user acceptance of the code?

I'd be willing to, but I see more utility in contributing specific
elements of its
functionality to the stdlib. Obviously the code is mine, and I can relicense
as needed if necessary.

As for your second question, I don't believe it sees much in the way of use.

> In particular, what do authors of competing OpenSSL wrappers (like M2Crypto) or other Python crypto packages (like pycrypto) think about this idea?

Evpy and M2Crypto have very different goals. M2Crypto seeks to be a
complete wrapper for OpenSSL, which we don't, and also uses SWIG,
which disqualifies it from consideration for the stdlib.

I don't know what the pycrypto folks would say about evpy, but I admit
to being very wary of that project- it appears to have been constructed
in a way which lends itself well to academic exercise rather than
practical use by nonexperts, and have had multiple occasions to correct
its dire misuse.

Geremy Condra

----------
title: add crypto routines to stdlib -> add encryption/decryption/signature/verification routines to stdlib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:31:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Jun 2010 22:31:18 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276554678.57.0.211663154349.issue8912@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I may add that although there is no formal test of any kind, I added tabs in two places in one .c file and in one place in another place, and it correctly reported two files. It?s a small function mostly copied from the one above; the only part where I used my brain is the counter (Python did the rest), so it should be ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:34:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 22:34:01 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1276554841.23.0.00350786611459.issue3297@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

We are too close from the final 2.7 release, it's too late to backport. As I wrote, this feature is not important and there are many workaround, so we don't need to backport to 3.1. Close the issue: use Python 3.2 if you want a better support of unicode ;-)

----------
dependencies:  -Use Py_UCS4 instead of Py_UNICODE in unicodectype.c
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3297>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:37:31 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 14 Jun 2010 22:37:31 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <AANLkTilT7cHz4AIDOlNPSq4h0N88wNgtukAFb5-WADpr@mail.gmail.com>
Message-ID: <4C16AF28.2040600@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Evpy and M2Crypto have very different goals. M2Crypto seeks to be a
> complete wrapper for OpenSSL, which we don't, and also uses SWIG,
> which disqualifies it from consideration for the stdlib.
>
> I don't know what the pycrypto folks would say about evpy, but I admit
> to being very wary of that project- it appears to have been constructed
> in a way which lends itself well to academic exercise rather than
> practical use by nonexperts, and have had multiple occasions to correct
> its dire misuse.

That isn't really my question; it's the other way 'round: what do *they*
(i.e. the respective authors) say about evpy? In the absence of actual
user input, support for inclusion of it by these experts would be a 
valuable indication that this specific library should be included. 
Likewise, objective resistance may lead to significant changes before 
inclusion, or to rejection. In the absence of both user support and 
expert opinions, I'd ask for a PEP.

----------
title: add encryption/decryption/signature/verification routines to stdlib -> add crypto routines to stdlib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:39:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 22:39:16 +0000
Subject: [issue8850] Remove "w" format of PyParse_ParseTuple()
In-Reply-To: <1275099860.74.0.46695580149.issue8850@psf.upfronthosting.co.za>
Message-ID: <1276555156.55.0.266784985314.issue8850@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #8926.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8850>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:40:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 22:40:10 +0000
Subject: [issue4769] b64decode should accept strings or bytes
In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za>
Message-ID: <1276555210.04.0.0687696555259.issue4769@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4769>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:41:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Jun 2010 22:41:33 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1276555293.86.0.291390193404.issue8998@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:48:01 2010
From: report at bugs.python.org (geremy condra)
Date: Mon, 14 Jun 2010 22:48:01 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <4C16AF28.2040600@v.loewis.de>
Message-ID: <AANLkTinI92yZAZnp4md74XdvroNhAc9-AltnPP41CzOQ@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Mon, Jun 14, 2010 at 3:37 PM, Martin v. L?wis <report at bugs.python.org> wrote:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
>> Evpy and M2Crypto have very different goals. M2Crypto seeks to be a
>> complete wrapper for OpenSSL, which we don't, and also uses SWIG,
>> which disqualifies it from consideration for the stdlib.
>>
>> I don't know what the pycrypto folks would say about evpy, but I admit
>> to being very wary of that project- it appears to have been constructed
>> in a way which lends itself well to academic exercise rather than
>> practical use by nonexperts, and have had multiple occasions to correct
>> its dire misuse.
>
> That isn't really my question; it's the other way 'round: what do *they*
> (i.e. the respective authors) say about evpy? In the absence of actual
> user input, support for inclusion of it by these experts would be a
> valuable indication that this specific library should be included.
> Likewise, objective resistance may lead to significant changes before
> inclusion, or to rejection. In the absence of both user support and
> expert opinions, I'd ask for a PEP.

I have no idea, and as I said earlier in the mailing list, I'm
willing to contribute the code, make changes as requested,
and maintain it- but I have no interest in or skill with the
political footwork the process demands. I like to think that
if this is as widely desired as it is asked for on python-list
that a champion will sooner or later emerge.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:48:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 14 Jun 2010 22:48:39 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276555719.69.0.289368879233.issue8912@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

?ric,

It will be helpful if your code could also check for lines longer than 79 characters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:49:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 14 Jun 2010 22:49:12 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276555752.64.0.10538151524.issue8912@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

.. and trailing white space.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:50:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 22:50:05 +0000
Subject: [issue4352] imp.find_module() fails with a UnicodeDecodeError when
	called with non-ASCII search paths
In-Reply-To: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za>
Message-ID: <1276555805.99.0.00594482929874.issue4352@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

About the mbcs encoding: issue #850997 proposes to make it more strict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4352>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:51:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Jun 2010 22:51:05 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <AANLkTinI92yZAZnp4md74XdvroNhAc9-AltnPP41CzOQ@mail.gmail.com>
Message-ID: <1276555860.3237.24.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le lundi 14 juin 2010 ? 22:48 +0000, geremy condra a ?crit :
> 
> I have no idea, and as I said earlier in the mailing list, I'm
> willing to contribute the code, make changes as requested,
> and maintain it- but I have no interest in or skill with the
> political footwork the process demands. I like to think that
> if this is as widely desired as it is asked for on python-list
> that a champion will sooner or later emerge.

For the record, Gregory P Smith (current maintainer of hashlib -- if I'm
not mistaken :-)), Jean-Paul Calderone (maintainer of pyOpenSSL) and
Heikki Toivonen (maintainer of m2crypto) have been added to the nosy
list for this issue.
As for the built-in ssl module, I've been doing most of the maintenance
work on it lately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:52:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 22:52:29 +0000
Subject: [issue8647] PyUnicode_GetMax is undocumented
In-Reply-To: <1273248439.66.0.594970239714.issue8647@psf.upfronthosting.co.za>
Message-ID: <1276555949.41.0.751009095507.issue8647@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you write a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8647>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:52:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 22:52:39 +0000
Subject: [issue8646] PyUnicode_EncodeDecimal is undocumented
In-Reply-To: <1273247945.7.0.702043835904.issue8646@psf.upfronthosting.co.za>
Message-ID: <1276555959.57.0.591166754427.issue8646@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you write a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8646>
_______________________________________

From report at bugs.python.org  Tue Jun 15 00:53:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 22:53:07 +0000
Subject: [issue8645] PyUnicode_AsEncodedObject is undocumented
In-Reply-To: <1273247735.73.0.712345896243.issue8645@psf.upfronthosting.co.za>
Message-ID: <1276555987.31.0.26185384657.issue8645@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you write a patch?

See also #8646.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8645>
_______________________________________

From report at bugs.python.org  Tue Jun 15 01:04:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 23:04:36 +0000
Subject: [issue8203] IDLE about dialog credits raises UnicodeDecodeError
In-Reply-To: <1269291921.68.0.001122865499.issue8203@psf.upfronthosting.co.za>
Message-ID: <1276556676.81.0.537574294863.issue8203@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

ping myself: i have to apply the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8203>
_______________________________________

From report at bugs.python.org  Tue Jun 15 01:11:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 23:11:52 +0000
Subject: [issue6543] traceback presented in wrong encoding
In-Reply-To: <1248247915.99.0.198197502387.issue6543@psf.upfronthosting.co.za>
Message-ID: <1276557112.63.0.807650970205.issue6543@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The patch changes the prototype of _Py_DisplaySourceLine() function. Is it possible that a third party module uses this function? Should we keep backward compatibility with third pary modules using the private C API?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6543>
_______________________________________

From report at bugs.python.org  Tue Jun 15 01:13:26 2010
From: report at bugs.python.org (Sindre Myren)
Date: Mon, 14 Jun 2010 23:13:26 +0000
Subject: [issue5220] os.makedirs' mode argument has bad default value
In-Reply-To: <1234384571.02.0.296749790343.issue5220@psf.upfronthosting.co.za>
Message-ID: <1276557206.37.0.557040933884.issue5220@psf.upfronthosting.co.za>


Sindre Myren <smyrman at gmail.com> added the comment:

>I don't understand what you mean when you say "how umask works in 
>relation to Python".  How it works in relation to Python isn't different 
>from how it works for any other Unix program.  Consider, for example, 
>the unix man page for 'open'.

This is what I mean.
The following gnu commands give (on Archlinux):
$ umask
0022
$ mkdir test1
$ mkdir test2 --mode 0777
$ ls -l
drwxr-xr-x 2 sindrero users 4096 Jun 15 00:59 test
drwxrwxrwx 2 sindrero users 4096 Jun 15 00:59 test2

So we see that new folder created with the --mode parameter to gnu's mkdir does not get the umask masked out.

The following code in python gives:
>> import os
>> os.mkdir('test3')
>> os.mkdir('test4')
>> exit()
$ ls -l
drwxr-xr-x 2 sindrero users 4096 Jun 15 01:01 test3
drwxr-xr-x 2 sindrero users 4096 Jun 15 01:01 test4

I (as a programmer) have never seen the specific code for python's mkdir function, And I have no way to know whether I should presume that mkdir in python works the same way as the gnu command or not. Unless it is documented that is.

Cheers :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5220>
_______________________________________

From report at bugs.python.org  Tue Jun 15 01:14:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 23:14:37 +0000
Subject: [issue3137] Python doesn't handle SIGINT well if it arrives during
	interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1276557277.05.0.687316712355.issue3137@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Bug related to this issue: #8124, PySys_WriteStdout() and PySys_WriteStderr() ignore signal handlers errors.
> ...
> Leave this issue open until #8124 is fixed.

I fixed both issues, so it's time to close this one.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3137>
_______________________________________

From report at bugs.python.org  Tue Jun 15 01:15:34 2010
From: report at bugs.python.org (Sindre Myren)
Date: Mon, 14 Jun 2010 23:15:34 +0000
Subject: [issue5220] os.makedirs' mode argument has bad default value
In-Reply-To: <1234384571.02.0.296749790343.issue5220@psf.upfronthosting.co.za>
Message-ID: <1276557334.22.0.368158974618.issue5220@psf.upfronthosting.co.za>


Sindre Myren <smyrman at gmail.com> added the comment:

*Sorry.. A bit quick there. The line 
>> os.mkdir('test4')
should have been:
>> os.mkdir('test4', 0777)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5220>
_______________________________________

From report at bugs.python.org  Tue Jun 15 01:20:45 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 14 Jun 2010 23:20:45 +0000
Subject: [issue5220] os.makedirs' mode argument has bad default value
In-Reply-To: <1276557206.37.0.557040933884.issue5220@psf.upfronthosting.co.za>
Message-ID: <4C16B94A.4010908@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I (as a programmer) have never seen the specific code for python's
> mkdir function, And I have no way to know whether I should presume
> that mkdir in python works the same way as the gnu command or not.
> Unless it is documented that is.

You should assume that Python's mkdir does the same as Linux' mkdir 
system call (which is different from the mkdir utility). You can
see mkdir's document with "man 2 mkdir", or on

http://linux.die.net/man/2/mkdir

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5220>
_______________________________________

From report at bugs.python.org  Tue Jun 15 01:53:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Jun 2010 23:53:44 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276559624.7.0.413686640925.issue8912@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Replacing VCS hooks, are we? :) Updated and attached.

Ideas for other feature requests:
- Printing the name of files with issues;
- Fail-fast mode or full report.

----------
Added file: http://bugs.python.org/file17672/patchcheck-pep7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 01:53:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Jun 2010 23:53:49 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276559629.07.0.174963673466.issue8912@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file17663/check-tabs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 01:53:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Jun 2010 23:53:52 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276559632.08.0.408109690522.issue8912@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file17664/check-tabs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 03:25:46 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 15 Jun 2010 01:25:46 +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: <1276565146.65.0.615976447841.issue7951@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Your original:

    "{0[-1]}".format('fox')

is a worse gotcha than:

    "{-1}".format('fox')

because you're much less likely to want to do the latter.

It's one of those things that it would be nice to have fixed, or we could just add a warning to the documentation that it _might_ be fixed in the future, so people shouldn't rely on the current behaviour. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Tue Jun 15 05:04:01 2010
From: report at bugs.python.org (Mike Crute)
Date: Tue, 15 Jun 2010 03:04:01 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1276571041.34.0.904959730699.issue8998@psf.upfronthosting.co.za>


Changes by Mike Crute <mcrute at gmail.com>:


----------
nosy: +mcrute

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 06:59:37 2010
From: report at bugs.python.org (geremy condra)
Date: Tue, 15 Jun 2010 04:59:37 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276555860.3237.24.camel@localhost.localdomain>
Message-ID: <AANLkTin1zTlmR_ErbNfwTjWqkN7SvHXnF3nA4S388LDe@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Mon, Jun 14, 2010 at 6:51 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Le lundi 14 juin 2010 ? 22:48 +0000, geremy condra a ?crit :
>>
>> I have no idea, and as I said earlier in the mailing list, I'm
>> willing to contribute the code, make changes as requested,
>> and maintain it- but I have no interest in or skill with the
>> political footwork the process demands. I like to think that
>> if this is as widely desired as it is asked for on python-list
>> that a champion will sooner or later emerge.
>
> For the record, Gregory P Smith (current maintainer of hashlib -- if I'm
> not mistaken :-)), Jean-Paul Calderone (maintainer of pyOpenSSL) and
> Heikki Toivonen (maintainer of m2crypto) have been added to the nosy
> list for this issue.
> As for the built-in ssl module, I've been doing most of the maintenance
> work on it lately.

Lot of people. If nobody minds I'm going to go ahead and post a
link to this on python-crypto, since a lot of the interface emerged
out of discussions that group had at pycon.

I'd also urge folks who are interested in this to be vocal about
whether they like the API and where they'd like to see changes-
I'm open to suggestions and, as noted in the mailing list, am
reimplementing in C, so this is a good time to be talking about
where you'd like to see things go.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 08:49:09 2010
From: report at bugs.python.org (Sindre Myren)
Date: Tue, 15 Jun 2010 06:49:09 +0000
Subject: [issue5220] os.makedirs' mode argument has bad default value
In-Reply-To: <1234384571.02.0.296749790343.issue5220@psf.upfronthosting.co.za>
Message-ID: <1276584549.19.0.598786559147.issue5220@psf.upfronthosting.co.za>


Sindre Myren <smyrman at gmail.com> added the comment:

Thank you very much for the clarification :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5220>
_______________________________________

From report at bugs.python.org  Tue Jun 15 09:17:34 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 15 Jun 2010 07:17:34 +0000
Subject: [issue6543] traceback presented in wrong encoding
In-Reply-To: <1248247915.99.0.198197502387.issue6543@psf.upfronthosting.co.za>
Message-ID: <1276586254.14.0.129092794493.issue6543@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

In issue3343, we chose to mark this function as private.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6543>
_______________________________________

From report at bugs.python.org  Tue Jun 15 09:26:50 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 15 Jun 2010 07:26:50 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276586810.9.0.0237284303057.issue8912@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Nitpick:  shouldn't that

    len(line) > 79

be

    len(line) > 80

?  Either that, or strip the line ending from the line before computing its length.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 09:36:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 15 Jun 2010 07:36:58 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276587418.76.0.547692247676.issue8912@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Similarly, isn't

  line[-1].isspace()

always going to be true (well, except possibly at the end of the file), thanks to the line-ending character?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 10:14:56 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 15 Jun 2010 08:14:56 +0000
Subject: [issue8940] *HTTPServer need a summary page with API inheritance table
In-Reply-To: <1276416782.89.0.116862060019.issue8940@psf.upfronthosting.co.za>
Message-ID: <AANLkTinGI_3wL_J_piaOszWRLCvAjcc26ZbOSDCWGGiQ@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

No.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8940>
_______________________________________

From report at bugs.python.org  Tue Jun 15 10:24:12 2010
From: report at bugs.python.org (Daniel Urban)
Date: Tue, 15 Jun 2010 08:24:12 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1276590252.58.0.974695870922.issue8998@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/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 10:29:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Jun 2010 08:29:11 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276590551.3.0.706987069299.issue8912@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file17672/patchcheck-pep7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 10:34:48 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 15 Jun 2010 08:34:48 +0000
Subject: [issue8903] Add module level now() and today() functions to datetime
	module
In-Reply-To: <1275720507.31.0.185559003971.issue8903@psf.upfronthosting.co.za>
Message-ID: <1276590888.14.0.436189088631.issue8903@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Raymond mention your reasons please. I may need them one day for describing development process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8903>
_______________________________________

From report at bugs.python.org  Tue Jun 15 10:43:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Jun 2010 08:43:44 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276591424.72.0.37644241916.issue8912@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Forgot readling kept the line end, thanks for catching. Updated (yay for Mercurial Queues!)

----------
Added file: http://bugs.python.org/file17673/patchcheck-pep7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 10:45:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Jun 2010 08:45:39 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276591539.92.0.192215736998.issue8912@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

s/readling/readline/
s/readline/iterating over the file/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 10:53:02 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 15 Jun 2010 08:53:02 +0000
Subject: [issue8469] struct - please make sizes explicit
In-Reply-To: <1271766650.13.0.432849451622.issue8469@psf.upfronthosting.co.za>
Message-ID: <1276591982.59.0.81368403277.issue8469@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the additional suggestions and patch.  I've implemented most of them in revisions r81992 through r81995.

I've left the note about 'native size and alignment':  native alignment *is* determined using sizeof, and I think this is important information.

I've also re-added the information that the 'f' and 'd' formats use IEEE binary32 and binary64, as a note to the format characters table.

And I've moved the information that the 'P' format is only available in native mode to the 'format characters' section.

Additional suggestions for improvments welcome!

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8469>
_______________________________________

From report at bugs.python.org  Tue Jun 15 11:16:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 15 Jun 2010 09:16:56 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276593416.95.0.238814989986.issue8912@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sorry to be nitpicky, but:

(a) the line[-2] produces "IndexError: string index out of range" on empty
lines, and

(b) this won't detect trailing whitespace on the last line of a file, if there's no newline at the end of the file.  Actually, it might also be worth checking that there *is* a newline at the end of the file;  this is actually required by the C standards.  (E.g., C99 5.1.1.2p2: "A source file that is not empty shall end in a new-line character".)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 11:18:30 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 15 Jun 2010 09:18:30 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276593510.52.0.119076297708.issue8912@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

s/actually//g

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 11:19:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Jun 2010 09:19:33 +0000
Subject: [issue8999] Add Mercurial support to patchcheck
In-Reply-To: <1276593572.4.0.720668123002.issue8999@psf.upfronthosting.co.za>
Message-ID: <1276593572.4.0.720668123002.issue8999@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I got bored of manually changing the svn status command to hg status when testing my patch for #8912, so I made a proper patch once and for all. (Did I already say yay for Mercurial Queues?)

----------
components: Demos and Tools
files: hg-support.diff
keywords: patch
messages: 107858
nosy: merwok
priority: low
severity: normal
stage: patch review
status: open
title: Add Mercurial support to patchcheck
type: feature request
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file17674/hg-support.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8999>
_______________________________________

From report at bugs.python.org  Tue Jun 15 11:39:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Jun 2010 09:39:08 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276594748.88.0.921943413085.issue8912@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file17673/patchcheck-pep7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 11:39:40 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 15 Jun 2010 09:39:40 +0000
Subject: [issue8940] *HTTPServer need a summary page with API inheritance table
In-Reply-To: <1276003396.33.0.469317406109.issue8940@psf.upfronthosting.co.za>
Message-ID: <1276594780.16.0.992225689237.issue8940@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

May I ask why?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8940>
_______________________________________

From report at bugs.python.org  Tue Jun 15 11:54:06 2010
From: report at bugs.python.org (Tom Zych)
Date: Tue, 15 Jun 2010 09:54:06 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1276595646.33.0.133588018354.issue7936@psf.upfronthosting.co.za>


Tom Zych <freethinker at pobox.com> added the comment:

The problem went away by itself after a while. I suspect a Windows update.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Tue Jun 15 12:08:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Jun 2010 10:08:19 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276596499.17.0.126013745184.issue8912@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the helpful reviews. I have fixed the trailing whitespace check with ?line[-2:-1].isspace()?, but I have a bug with my file counting. Before I go further, I?d like feedback from people using patchcheck:

1) Reindenting Python is a task best handled by reindent.py, but checking for tabs, line length and trailing whitespace is basically a reimplementation of grep and wc. Is it an explicit and important goal that patchcheck.py be independent of external tools?

2) Do you like the current report format? (?checking for one thing: n files?) It requires you to use grep of your editor?s search after checking. What about printing out file names and line numbers?

3) What about a function to strip trailing spaces and add a final newline where needed instead of just complaining? Is it okay to replace tabs with spaces in C too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 12:12:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Jun 2010 10:12:11 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276596731.87.0.422729111824.issue8912@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Another one: I?d like to move the file name filtering from the worker functions into the main function. With that change, looping over all file names to get only the C files would be written and run only once, even if there are four functions that operate on these files. There is not backward compatibility guarantee for Tools/*, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 12:21:30 2010
From: report at bugs.python.org (Christian Schubert)
Date: Tue, 15 Jun 2010 10:21:30 +0000
Subject: [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1276597290.26.0.26628872249.issue8865@psf.upfronthosting.co.za>


Christian Schubert <bugs at apexo.de> added the comment:

added a patch which fixes both issues

before releasing the GIL we take a copy of the ufds pointer and its len, erasing the ufds pointer in the poll object (to make sure nobody else fiddles with it); when we're done we either but it back into the object (when it's still NULL) or we free it

the update logic is modified as well, since the uptodate flag is not sufficient anymore, we now count up a tag for each modification of the poll dictionary and remember that tag together with the ufds pointer

the result is:
- for the single-threaded case we do little extra work (moving ufds from/to poll object)
- correct for the multi-threaded case, with slightly higher overhead (one additional call to each of malloc, update_ufd_array, free), probably worse than having one poll object per thread, but not worse than allocating a new poll object each time we want to poll

there still is potential for incorrect poll results (but not for memory corruption): when poll_register/poll_unregister are called exactly 2**32 times (or multiples thereof) while poll_poll is running, it will happily put back its outdated ufds pointer into the poll object when its done, this could be alleviated by changing tag to long long ... which is unlikely to wrap around anytime soon.

----------
keywords: +patch
Added file: http://bugs.python.org/file17675/select.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8865>
_______________________________________

From report at bugs.python.org  Tue Jun 15 12:22:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Jun 2010 10:22:26 +0000
Subject: [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1276597346.45.0.107142761076.issue8865@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8865>
_______________________________________

From report at bugs.python.org  Tue Jun 15 12:24:14 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 15 Jun 2010 10:24:14 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276597454.46.0.892512530876.issue8912@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Answering as a rather infrequent user of 'make patchcheck', but someone who vows to use it more often in future... :)

(1) Well, it would be awkward to use grep or wc on Windows, so it's convenient not to need external tools.

(2) +1 to a more detailed report, at least giving the file name and what was wrong with it ("trailing whitespace in yourfile.c");  I could imagine that people might care about finding trailing whitespace or tabs, but not about line length, for example.  (Many of the existing C files already have lines >= 80 characters.)

(3) Don't really care:  emacs already does both these things for me nicely.  I'd rather just have patchcheck do the reporting.  And automatic replacement of tabs with spaces in C files might not guess correctly what the author intended.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 12:31:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Jun 2010 10:31:07 +0000
Subject: [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1276597867.53.0.1965409532.issue8865@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/issue8865>
_______________________________________

From report at bugs.python.org  Tue Jun 15 12:46:35 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 15 Jun 2010 10:46:35 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1276598795.77.0.462713372015.issue8912@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

and your proposed refactoring sounds fine to me.  I can't really see any backwards compatibility concerns.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 15 12:57:07 2010
From: report at bugs.python.org (James Teh)
Date: Tue, 15 Jun 2010 10:57:07 +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: <1276599427.93.0.559461282535.issue8959@psf.upfronthosting.co.za>


Changes by James Teh <jamie at nvaccess.org>:


----------
nosy: +jteh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8959>
_______________________________________

From report at bugs.python.org  Tue Jun 15 13:24:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Jun 2010 11:24:22 +0000
Subject: [issue8999] Add Mercurial support to patchcheck
In-Reply-To: <1276593572.4.0.720668123002.issue8999@psf.upfronthosting.co.za>
Message-ID: <1276601062.03.0.514810705585.issue8999@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Adding nosy from the other patchcheck bug, hope it doesn?t annoy anyone.

----------
nosy: +belopolsky, brett.cannon, mark.dickinson, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8999>
_______________________________________

From report at bugs.python.org  Tue Jun 15 14:27:18 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 15 Jun 2010 12:27:18 +0000
Subject: [issue8940] *HTTPServer need a summary page with API inheritance table
In-Reply-To: <1276003396.33.0.469317406109.issue8940@psf.upfronthosting.co.za>
Message-ID: <1276604838.98.0.173726471013.issue8940@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/issue8940>
_______________________________________

From report at bugs.python.org  Tue Jun 15 14:50:59 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 15 Jun 2010 12:50:59 +0000
Subject: [issue8940] *HTTPServer need a summary page with API inheritance table
In-Reply-To: <1276003396.33.0.469317406109.issue8940@psf.upfronthosting.co.za>
Message-ID: <1276606259.12.0.670961544016.issue8940@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

1. No time
2. Looks complicated

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8940>
_______________________________________

From report at bugs.python.org  Tue Jun 15 14:53:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 15 Jun 2010 12:53:22 +0000
Subject: [issue8940] *HTTPServer need a summary page with API inheritance table
In-Reply-To: <1276003396.33.0.469317406109.issue8940@psf.upfronthosting.co.za>
Message-ID: <1276606402.9.0.0623286330973.issue8940@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: open -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8940>
_______________________________________

From report at bugs.python.org  Tue Jun 15 14:59:08 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 15 Jun 2010 12:59:08 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1276606748.46.0.179502306541.issue8998@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/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 15:21:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Jun 2010 13:21:13 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1276608073.65.0.599603228222.issue8998@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've taken a quick look at the source tree (there doesn't seem to be any separate docs) and here is my opinion:
- the evp.py API is too low-level (it's a one-to-one mapping to the OpenSSL C API); we would want at least some kind of object-oriented abstraction around the basic concepts (such as in the hashlib and ssl modules) rather than passing opaque pointers around
- the other APIs (cipher.py, envelope.py, signature.py) look conversely too high-level, since they focus on specific use cases and make some arbitrary choices for the user (for example, envelope.py imposes AES-192)

By the way, the use of function signature annotations to mirror C APIs as Python APIs through ctypes is nice, perhaps you should upload it as a separate library on PyPI :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 15:53:25 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 15 Jun 2010 13:53:25 +0000
Subject: [issue8647] PyUnicode_GetMax is undocumented
In-Reply-To: <1273248439.66.0.594970239714.issue8647@psf.upfronthosting.co.za>
Message-ID: <1276610005.15.0.892016347069.issue8647@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Yes, though it may be a while before I find time to do so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8647>
_______________________________________

From report at bugs.python.org  Tue Jun 15 15:53:52 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 15 Jun 2010 13:53:52 +0000
Subject: [issue8646] PyUnicode_EncodeDecimal is undocumented
In-Reply-To: <1273247945.7.0.702043835904.issue8646@psf.upfronthosting.co.za>
Message-ID: <1276610032.69.0.636284698775.issue8646@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Yes, though it may be a while before I find time to do so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8646>
_______________________________________

From report at bugs.python.org  Tue Jun 15 15:55:19 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 15 Jun 2010 13:55:19 +0000
Subject: [issue8645] PyUnicode_AsEncodedObject is undocumented
In-Reply-To: <1273247735.73.0.712345896243.issue8645@psf.upfronthosting.co.za>
Message-ID: <1276610119.64.0.297746623486.issue8645@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I'm not really clear on what PyUnicode_AsEncodedObject does (as opposed to PyUnicode_AsEncodedString).  Someone already familiar with those two functions would have a much easier time writing a documentation patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8645>
_______________________________________

From report at bugs.python.org  Tue Jun 15 16:49:47 2010
From: report at bugs.python.org (geremy condra)
Date: Tue, 15 Jun 2010 14:49:47 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276608073.65.0.599603228222.issue8998@psf.upfronthosting.co.za>
Message-ID: <AANLkTimBTJVxg6x5fmEugMbs4O8bAdVfoLbarxNh_2VG@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Tue, Jun 15, 2010 at 9:21 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> I've taken a quick look at the source tree (there doesn't seem to be any separate docs) and here is my opinion:
> - the evp.py API is too low-level (it's a one-to-one mapping to the OpenSSL C API); we would want at least some kind of object-oriented abstraction around the basic concepts (such as in the hashlib and ssl modules) rather than passing opaque pointers around

evp.py is mostly for internal use (to map the openssl calls into
Python) and won't exist in the rewrite- most of the people who would
want to use that should really be using M2Crypto or similar.

> - the other APIs (cipher.py, envelope.py, signature.py) look conversely too high-level, since they focus on specific use cases and make some arbitrary choices for the user (for example, envelope.py imposes AES-192)

The goals of the library are simplicity and ease of use. I've
frequently found that out of fear of making incorrect choices, people
will simply decide not to use crypto at all, or that they make
incredibly stupid choices like using RSA without padding. I'd be
willing to add in the option to alter those options via keyword
arguments if it became a major point of contention, but in general I
think its better for those who "just want to encrypt something" to
have a lot of those decisions made for them. The specific decision
you're talking about was made because while AES-256 has a bigger
number at the end, its key schedule appears weaker in light of recent
attacks.

> By the way, the use of function signature annotations to mirror C APIs as Python APIs through ctypes is nice, perhaps you should upload it as a separate library on PyPI :)

I've posted them as recipes on ASPN ([0] and [1]). I used a similar
technique and the JNI to mechanically wrap the Android libraries
(Java) for access from Python, and it worked pretty well. Looking at
the data from pypi, ease-of-use things don't seem to see a lot of use,
but if you think I ought to then I could go ahead and do that.

Geremy Condra

[0] http://code.activestate.com/recipes/576731-c-function-decorator/
[1] http://code.activestate.com/recipes/576734-c-struct-decorator/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 17:04:19 2010
From: report at bugs.python.org (Damjan Georgievski)
Date: Tue, 15 Jun 2010 15:04:19 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1276614259.1.0.280857362362.issue8998@psf.upfronthosting.co.za>


Damjan Georgievski <gdamjan at users.sourceforge.net> added the comment:

AFAIK, what the stdlib needs is a high-level crypto module, analogous to hashlib

----------
nosy: +gdamjan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 17:25:41 2010
From: report at bugs.python.org (Nils Philippsen)
Date: Tue, 15 Jun 2010 15:25:41 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1276615541.97.0.113506268943.issue2504@psf.upfronthosting.co.za>


Changes by Nils Philippsen <nils at redhat.com>:


----------
nosy: +nils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Tue Jun 15 17:36:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 15 Jun 2010 15:36:21 +0000
Subject: [issue5094] datetime lacks concrete tzinfo implementation for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276616181.43.0.911774247452.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Reopening to add some minor fixes to tests and documentation.  See issue5094h.diff.  Ezio, thanks for finding these issues.

----------
status: closed -> open
Added file: http://bugs.python.org/file17676/issue5094h.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue Jun 15 17:37:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 15 Jun 2010 15:37:38 +0000
Subject: [issue5094] datetime lacks concrete tzinfo implementation for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276616258.46.0.2759378656.issue5094@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue Jun 15 17:42:18 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Jun 2010 15:42:18 +0000
Subject: [issue8442] Broken zipfile with  python 3.2 on osx
In-Reply-To: <1271603737.34.0.035153225146.issue8442@psf.upfronthosting.co.za>
Message-ID: <1276616538.45.0.244348533197.issue8442@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is no longer a problem, I cannot reproduce the issue with the current trunk.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8442>
_______________________________________

From report at bugs.python.org  Tue Jun 15 17:52:50 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 15 Jun 2010 15:52:50 +0000
Subject: [issue9000] Provide parseable repr to datetime.timezone
In-Reply-To: <1276617170.01.0.394704824446.issue9000@psf.upfronthosting.co.za>
Message-ID: <1276617170.01.0.394704824446.issue9000@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Recently added datetime.timezone class does not have a custom repr, so one gets

>>> timezone.utc
<datetime.timezone object at 0x100681ef0>

instead of parseable

datetime.timezone(datetime.timedelta(0))

This is inconsistent with the way other classes in datetime module behave.

----------
assignee: belopolsky
keywords: easy
messages: 107876
nosy: belopolsky
priority: normal
severity: normal
stage: unit test needed
status: open
title: Provide parseable repr to datetime.timezone
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9000>
_______________________________________

From report at bugs.python.org  Tue Jun 15 17:53:22 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 15 Jun 2010 15:53:22 +0000
Subject: [issue9000] Provide parseable repr to datetime.timezone
In-Reply-To: <1276617170.01.0.394704824446.issue9000@psf.upfronthosting.co.za>
Message-ID: <1276617202.41.0.812921306331.issue9000@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
dependencies: +datetime lacks concrete tzinfo implementation for UTC
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9000>
_______________________________________

From report at bugs.python.org  Tue Jun 15 17:54:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 15 Jun 2010 15:54:33 +0000
Subject: [issue9000] Provide parseable repr to datetime.timezone
In-Reply-To: <1276617170.01.0.394704824446.issue9000@psf.upfronthosting.co.za>
Message-ID: <1276617273.74.0.443454428665.issue9000@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Merged issue5094 nosy list.

----------
nosy: +ajaksu2, akira, brett.cannon, doerwalter, durban, ezio.melotti, gagenellina, kawai, l0nwlf, mark.dickinson, merwok, pitrou, r.david.murray, rafe, techtonik, tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9000>
_______________________________________

From report at bugs.python.org  Tue Jun 15 18:06:15 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Jun 2010 16:06:15 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1276617975.47.0.729543595991.issue8577@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've fixed this issue for the 3.2 branch in r81999.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Tue Jun 15 18:22:05 2010
From: report at bugs.python.org (Renato Cunha)
Date: Tue, 15 Jun 2010 16:22:05 +0000
Subject: [issue9001] PyFile_FromFd wrong documentation
In-Reply-To: <1276618925.14.0.0301082394986.issue9001@psf.upfronthosting.co.za>
Message-ID: <1276618925.14.0.0301082394986.issue9001@psf.upfronthosting.co.za>


New submission from Renato Cunha <renato at renatocunha.com>:

PyFile_FromFd has a wrong argument cound and, consequently, a wrong description in py3k docs. The "errors" is never mentioned.

----------
assignee: docs at python
components: Documentation
files: correct-py3k-c-api-doc.diff
keywords: patch
messages: 107879
nosy: docs at python, trovao
priority: normal
severity: normal
status: open
title: PyFile_FromFd wrong documentation
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17677/correct-py3k-c-api-doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9001>
_______________________________________

From report at bugs.python.org  Tue Jun 15 18:45:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Jun 2010 16:45:17 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1276620317.07.0.896165146973.issue8577@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks like this just broke the 3.x buildbots.


======================================================================
FAIL: test_get_python_inc (distutils.tests.test_sysconfig.SysconfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/Lib/distutils/tests/support.py", line 16, in _capture_warnings
    return func(*args, **kw)
  File "/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/Lib/distutils/tests/test_sysconfig.py", line 47, in test_get_python_inc
    self.assertTrue(os.path.isdir(inc_dir), inc_dir)
AssertionError: Include

======================================================================
FAIL: test_user_site (distutils.tests.test_install.InstallTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/Lib/distutils/tests/test_install.py", line 100, in test_user_site
    self._test_user_site()
  File "/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/Lib/distutils/tests/test_install.py", line 129, in _test_user_site
    self.assertTrue(os.path.exists(self.user_base))
AssertionError: False is not True

----------
assignee: tarek -> ronaldoussoren
nosy: +pitrou
status: closed -> open
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Tue Jun 15 18:46:57 2010
From: report at bugs.python.org (Renato Cunha)
Date: Tue, 15 Jun 2010 16:46:57 +0000
Subject: [issue9002] Add a pointer on where to find a better description of
	PyFile_FromFd arguments
In-Reply-To: <1276620417.22.0.459801828644.issue9002@psf.upfronthosting.co.za>
Message-ID: <1276620417.22.0.459801828644.issue9002@psf.upfronthosting.co.za>


New submission from Renato Cunha <renato at renatocunha.com>:

Even though the "File Objects" section in py3k documentation makes it clear that the functions there listed are just wrappers over the io module, it took me a bit to find which function PyFile_FromFd was wrapping.

So, what about making it clear that PyFile_FromFd wraps io.open? The attached patch tries to do that. (It assumes that my previous patch, from issue #9001, will get accepted, as it builds on it.)

----------
assignee: docs at python
components: Documentation
files: py3k-pyfile-from-fd-io-module.diff
keywords: patch
messages: 107881
nosy: docs at python, trovao
priority: normal
severity: normal
status: open
title: Add a pointer on where to find a better description of PyFile_FromFd arguments
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17678/py3k-pyfile-from-fd-io-module.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9002>
_______________________________________

From report at bugs.python.org  Tue Jun 15 18:48:39 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 15 Jun 2010 16:48:39 +0000
Subject: [issue9002] Add a pointer on where to find a better description of
	PyFile_FromFd arguments
In-Reply-To: <1276620417.22.0.459801828644.issue9002@psf.upfronthosting.co.za>
Message-ID: <1276620519.79.0.126324233257.issue9002@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
dependencies: +PyFile_FromFd wrong documentation
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9002>
_______________________________________

From report at bugs.python.org  Tue Jun 15 18:49:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Jun 2010 16:49:14 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <AANLkTimBTJVxg6x5fmEugMbs4O8bAdVfoLbarxNh_2VG@mail.gmail.com>
Message-ID: <1276620549.3109.112.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mardi 15 juin 2010 ? 14:49 +0000, geremy condra a ?crit :
> The goals of the library are simplicity and ease of use. I've
> frequently found that out of fear of making incorrect choices, people
> will simply decide not to use crypto at all, or that they make
> incredibly stupid choices like using RSA without padding. I'd be
> willing to add in the option to alter those options via keyword
> arguments if it became a major point of contention, but in general I
> think its better for those who "just want to encrypt something" to
> have a lot of those decisions made for them. The specific decision
> you're talking about was made because while AES-256 has a bigger
> number at the end, its key schedule appears weaker in light of recent
> attacks.

While it's fine to perhaps detect and warn about insecure use, I don't
think the API should be too directive (for inclusion in the stdlib
anyway). Most (if not all) stdlib modules don't impose any specific
policy but instead provide building blocks for users to address their
specific needs. Directive APIs should probably be left to third-party
libraries (which can of course build on the primitives provided by the
stdlib). Also, some uses of crypto functions can be to interoperate with
existing cryptographic protocols, and for that you need a fine-grained
control over algorithmic options.

Do note that the docs can be as educating as needed; they can include
suggestions, warnings and even small recipes.

As for default argument values, the problem is that we're then stuck
with them (for compatibility). It means that if e.g. AES-192 gets
compromised, Python will promote an API which by default is insecure and
dangerous to use. Again, giving equal access to various ciphers and then
providing guidance in the documentation would be a better compromise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 18:59:25 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 15 Jun 2010 16:59:25 +0000
Subject: [issue1368368] prompt_user_passwd() in FancyURLopener masks 401
	Unauthorized error page
Message-ID: <1276621165.6.0.866724137728.issue1368368@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

The reason the the password is prompted is because, on 401 authentication failure, there is a retry logic by default. When the authentication is retried, it is prompted for username:password using getpass. When using GUI modules it is desired to override the prompt_user_passwd for prompting via GUI.

The way to 'resolve' this issue it seems to me is have a switch retry=False in http_error_401 and http_error_407 methods, which will not prompt the user but instead will throw the Exception and the HTTP Error value. 

retry=True will prompt the user in the cmdline or in GUI (if it is overridden).

- This is adding an extra flag in the function, so I am not sure py2.7 is the right candidate. But the same functions are present in py3k trunk, we can patch it in there. 

I am setting the priority to low and attaching the patch too. I see the bug was reported way back in 2005 and it has not been a serious concern for anyone so far. My take is to patch it in py3k and close the issue.

- Also, anyone using urllib should just migrate to use urllib2 facilities. This piece of code is present for supporting the legacy apps only.

- And the most important of all, username:password at url.tld is deprecated, it should not be used at all.

----------
keywords: +patch
priority: normal -> low
stage: needs patch -> patch review
Added file: http://bugs.python.org/file17679/Issue1368368.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1368368>
_______________________________________

From report at bugs.python.org  Tue Jun 15 19:16:45 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Jun 2010 17:16:45 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1276622205.72.0.825247111597.issue8577@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Sigh. test.test_distutils behaves different when run through regrtest than when run directly.

I have a fix, but am running an extended test cycle before committing (that is, both with and without srcdir==builddir)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Tue Jun 15 19:22:15 2010
From: report at bugs.python.org (geremy condra)
Date: Tue, 15 Jun 2010 17:22:15 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276620549.3109.112.camel@localhost.localdomain>
Message-ID: <AANLkTilFrmmL6fiP_4SSD-RtY3owwud92Rh0G-s_bekb@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Tue, Jun 15, 2010 at 9:49 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Le mardi 15 juin 2010 ? 14:49 +0000, geremy condra a ?crit :
>> The goals of the library are simplicity and ease of use. I've
>> frequently found that out of fear of making incorrect choices, people
>> will simply decide not to use crypto at all, or that they make
>> incredibly stupid choices like using RSA without padding. I'd be
>> willing to add in the option to alter those options via keyword
>> arguments if it became a major point of contention, but in general I
>> think its better for those who "just want to encrypt something" to
>> have a lot of those decisions made for them. The specific decision
>> you're talking about was made because while AES-256 has a bigger
>> number at the end, its key schedule appears weaker in light of recent
>> attacks.
>
> While it's fine to perhaps detect and warn about insecure use, I don't
> think the API should be too directive (for inclusion in the stdlib
> anyway). Most (if not all) stdlib modules don't impose any specific
> policy but instead provide building blocks for users to address their
> specific needs. Directive APIs should probably be left to third-party
> libraries (which can of course build on the primitives provided by the
> stdlib). Also, some uses of crypto functions can be to interoperate with
> existing cryptographic protocols, and for that you need a fine-grained
> control over algorithmic options.

I'm not clear on how a crypto library is supposed to detect insecure
use short of simply not allowing suspicious things. Maybe you have
some ideas there?

As for building-block type systems, like I say they have their place,
particularly where interoperating with existing systems is a concern,
and I don't want to come across as though I don't respect projects
like M2Crypto- I just think that most developers don't need that
level of complexity and aren't prepared to invest the time to learn
how to get what they want out of it. That's where something like
evpy shines.

> Do note that the docs can be as educating as needed; they can include
> suggestions, warnings and even small recipes.

I'm reasonably sure that there aren't enough docs in the world to
stop people from using OpenSSL to live dangerously. Evpy you
could get people not to be completely stupid with, at least a large
portion of the time.

> As for default argument values, the problem is that we're then stuck
> with them (for compatibility). It means that if e.g. AES-192 gets
> compromised, Python will promote an API which by default is insecure and
> dangerous to use. Again, giving equal access to various ciphers and then
> providing guidance in the documentation would be a better compromise.

I would be enormously surprised if a weakness in AES-192 was found that
weakened it to the point where it would actually constitute bad advice,
assuming that you made all the other right decisions. Having said that, it
might be a good idea to put a version switch in that allowed you to specify
compatibility modes, just in case.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 15 19:26:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Jun 2010 17:26:06 +0000
Subject: [issue5094] datetime lacks concrete tzinfo implementation for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276622766.56.0.109771675902.issue5094@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 for replacing math range notation with English. Much easier for non-math people that do Python :)

One more nit: Your docstrings use verb forms like ?Returns? where PEP?257 advises to use ?Return?: ?[the docstring] prescribes the function or method's effect as a command ("Do this", "Return that"), not as a description; e.g. don't write "Returns the pathname ..."?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue Jun 15 19:32:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Jun 2010 17:32:08 +0000
Subject: [issue9001] PyFile_FromFd wrong documentation
In-Reply-To: <1276618925.14.0.0301082394986.issue9001@psf.upfronthosting.co.za>
Message-ID: <1276623128.81.0.495076709999.issue9001@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you! This was committed in r82000, and I improved other text a bit in r82001.

----------
nosy: +pitrou
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9001>
_______________________________________

From report at bugs.python.org  Tue Jun 15 19:33:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Jun 2010 17:33:17 +0000
Subject: [issue9002] Add a pointer on where to find a better description of
	PyFile_FromFd arguments
In-Reply-To: <1276620417.22.0.459801828644.issue9002@psf.upfronthosting.co.za>
Message-ID: <1276623197.47.0.282823628012.issue9002@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Same resolution as in #9001. Thanks again.

----------
nosy: +pitrou
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9002>
_______________________________________

From report at bugs.python.org  Tue Jun 15 19:57:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 15 Jun 2010 17:57:29 +0000
Subject: [issue5094] datetime lacks concrete tzinfo implementation for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276624649.9.0.956071181737.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

What about 

"""
.. method:: datetime.utcoffset()

   If :attr:`tzinfo` is ``None``, returns ``None``, else returns ...
"""

Should this use "return" too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue Jun 15 20:02:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Jun 2010 18:02:32 +0000
Subject: [issue5094] datetime lacks concrete tzinfo implementation for UTC
In-Reply-To: <1276624649.9.0.956071181737.issue5094@psf.upfronthosting.co.za>
Message-ID: <4C17C036.30302@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

.. method:: datetime.utcoffset()

   Return ``None`` if :attr:`tzinfo` is ``None``, else else return ...

That said, to keep diffs readable, perhaps stick with the existing
convention know, and later a PEP 257 compliance diff can be made.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue Jun 15 20:07:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 15 Jun 2010 18:07:14 +0000
Subject: [issue5094] datetime lacks concrete tzinfo implementation for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276625234.39.0.639006061672.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

How to specify offset range horse got its beating above.  See msg107554.  The current wording is the best compromise between verbosity and precision.

Replacing the patch with one that fixes other nits.

----------
Added file: http://bugs.python.org/file17680/issue5094h.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue Jun 15 20:08:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 15 Jun 2010 18:08:53 +0000
Subject: [issue5094] datetime lacks concrete tzinfo implementation for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276625333.77.0.694921141519.issue5094@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17676/issue5094h.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue Jun 15 20:26:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Jun 2010 18:26:24 +0000
Subject: [issue5094] datetime lacks concrete tzinfo implementation for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276626384.91.0.473889824262.issue5094@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Suggestion for one line:
?The *dt* argument must be aware with ``tzinfo`` set to ``self``.?
?The *dt* argument must be an aware datetime, with ``tzinfo`` set to ``self``.?

If there is a reST construct for aware datetime, use it. Since ?self? is not special, perhaps an alternate wording like ?the timezone instance from which the method is called?, but less ugly.

Some PyDoc_STR calls still use ?Returns.?

By the way, you could have committed the unittest changes directly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue Jun 15 22:22:28 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 15 Jun 2010 20:22:28 +0000
Subject: [issue5094] datetime lacks concrete tzinfo implementation for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276633348.05.0.7416988766.issue5094@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Good job. Thanks for working on this.

It is possible to backport this to future of Python 2.7?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue Jun 15 22:27:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Jun 2010 20:27:53 +0000
Subject: [issue5094] datetime lacks concrete tzinfo implementation for UTC
In-Reply-To: <1276633348.05.0.7416988766.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276633668.3109.115.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It is possible to backport this to future of Python 2.7?

No.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue Jun 15 23:17:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Jun 2010 21:17:28 +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: <1276636648.27.0.132013259421.issue1589@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Reopening. I think it would be nice to provide the appropriate convenience function(s) as part of the ssl module, even if the user has to call them explicitly.

----------
assignee: janssen -> 
nosy: +pitrou
resolution: rejected -> 
status: closed -> open
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Tue Jun 15 23:20:27 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Jun 2010 21:20:27 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1276636827.36.0.544998227677.issue8577@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This should be fixed in r82005, this passes all tests both with and without srcdir==builddir

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Tue Jun 15 23:27:40 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 15 Jun 2010 21:27:40 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1276637260.36.0.816861404333.issue8577@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

As I said earlier, I am going to revert Distutils state in py3k so it's like the 3.1 branch. So the changes in distutils/ in py3k that are not backported in 3.1 will be lost.

I had a lack of time lately, but I should be able to do it this week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Wed Jun 16 00:44:23 2010
From: report at bugs.python.org (Thomas Vander Stichele)
Date: Tue, 15 Jun 2010 22:44:23 +0000
Subject: [issue644744] bdist_rpm fails when installing man pages
Message-ID: <1276641863.59.0.617682817493.issue644744@psf.upfronthosting.co.za>


Thomas Vander Stichele <thomasvs at users.sourceforge.net> added the comment:

What do you mean, it's frozen ? Without the patch you're already breaking a third party tool, namely rpm.  What other tool worth caring about that uses bdist_rpm could possibly get broken by fixing an obvious bug ? Why is it so impossible to simply fix a bug for a feature that people are trying to use and are baffled by having it not working ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue644744>
_______________________________________

From report at bugs.python.org  Wed Jun 16 01:42:56 2010
From: report at bugs.python.org (=?utf-8?b?UmVuw6kgU2Now7xtYW5u?=)
Date: Tue, 15 Jun 2010 23:42:56 +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: <1276645376.08.0.0874178713217.issue3871@psf.upfronthosting.co.za>


Ren? Sch?mann <whitetigx at gmail.com> added the comment:

Roumen thanks for this work, but will you upload a new version?
Just because i can't get it to work, i can't even patch it^^

Maybe it's the SVN Client i use (Tortoise SVN) or that i don't know how to apply this patch :D It would be nice when you help me

Kind regards

----------
nosy: +WhiteTiger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Wed Jun 16 03:04:38 2010
From: report at bugs.python.org (geremy condra)
Date: Wed, 16 Jun 2010 01:04:38 +0000
Subject: [issue9003] urllib about https behavior
In-Reply-To: <1276650277.98.0.113951617798.issue9003@psf.upfronthosting.co.za>
Message-ID: <1276650277.98.0.113951617798.issue9003@psf.upfronthosting.co.za>


New submission from geremy condra <debatem1 at gmail.com>:

urllib currently blindly accepts bad certificates when passed an https address. This behavior, clearly not desirable for many users, is also not documented. I propose one of two changes:

1) add mechanisms for enforcing correct behavior to urllib, or
2) change the documentation for that module to include something akin to the following warning:

"Warning: urllib does not perform certificate checks if passed an HTTPS url! This permits remote machines to masquerade as your intended destination."

----------
components: Library (Lib)
messages: 107900
nosy: debatem1
priority: normal
severity: normal
status: open
title: urllib about https behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9003>
_______________________________________

From report at bugs.python.org  Wed Jun 16 03:20:55 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 16 Jun 2010 01:20:55 +0000
Subject: [issue9003] urllib about https behavior
In-Reply-To: <1276650277.98.0.113951617798.issue9003@psf.upfronthosting.co.za>
Message-ID: <1276651255.46.0.627954914464.issue9003@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9003>
_______________________________________

From report at bugs.python.org  Wed Jun 16 04:02:28 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 02:02:28 +0000
Subject: [issue5094] datetime lacks concrete tzinfo implementation for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1276653748.94.0.127437690623.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On this happy note, I am closing this issue.  Doc changes have been committed in r82004, test changes in r82003.  For repr(timezone(..)) development, please follow issue #9000.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Wed Jun 16 04:08:01 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 02:08:01 +0000
Subject: [issue3129] struct allows repeat spec. without a format specifier
In-Reply-To: <1213694469.69.0.0950890622628.issue3129@psf.upfronthosting.co.za>
Message-ID: <1276654081.0.0.306878213217.issue3129@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3129>
_______________________________________

From report at bugs.python.org  Wed Jun 16 04:21:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 02:21:03 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276654863.55.0.486003684037.issue6641@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17681/issue6641.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Wed Jun 16 04:21:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 02:21:11 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276654871.31.0.729198318867.issue6641@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17667/issue6641.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Wed Jun 16 04:22:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 02:22:12 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276654932.96.0.505282263015.issue6641@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Mark,

I am reassigning this to you for a commit review.

----------
assignee: belopolsky -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Wed Jun 16 04:55:00 2010
From: report at bugs.python.org (Craig McQueen)
Date: Wed, 16 Jun 2010 02:55:00 +0000
Subject: [issue1596321] KeyError at exit after 'import threading' in other
	thread
Message-ID: <1276656900.15.0.604573599076.issue1596321@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

>From my limited experience using cx_Freeze 4.1.2 with Python 2.6.5, it seems that this issue is triggered in a cx_Frozen program simply by having `import threading` in the program. I'm not sure what cx_Freeze is doing that makes this issue show up.

----------
nosy: +cmcqueen1975

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1596321>
_______________________________________

From report at bugs.python.org  Wed Jun 16 04:57:42 2010
From: report at bugs.python.org (Craig McQueen)
Date: Wed, 16 Jun 2010 02:57:42 +0000
Subject: [issue1596321] KeyError at exit after 'import threading' in other
	thread
Message-ID: <1276657062.38.0.766415153468.issue1596321@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

Sorry I should have said, I'm running on Windows 2000 SP4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1596321>
_______________________________________

From report at bugs.python.org  Wed Jun 16 05:08:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 16 Jun 2010 03:08:31 +0000
Subject: [issue9003] urllib about https behavior
In-Reply-To: <1276650277.98.0.113951617798.issue9003@psf.upfronthosting.co.za>
Message-ID: <1276657711.81.0.0342898883279.issue9003@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/issue9003>
_______________________________________

From report at bugs.python.org  Wed Jun 16 05:19:43 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 16 Jun 2010 03:19:43 +0000
Subject: [issue8943] Bug in InteractiveConsole
In-Reply-To: <1276014263.34.0.524334073977.issue8943@psf.upfronthosting.co.za>
Message-ID: <1276658383.45.0.0737029833972.issue8943@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Yes, the problem is observed in py3k. Pickle module when used via Interactive console is trying to import the class as __console__.ClassName and it is failing to see the __console__ module.

_pickle.PicklingError: Can't pickle <class '__console__.Example'>: import of module '__console__' failed

----------
nosy: +alexandre.vassalotti, orsenthil
stage:  -> needs patch
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8943>
_______________________________________

From report at bugs.python.org  Wed Jun 16 05:36:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 03:36:44 +0000
Subject: [issue9004] datetime.utctimetuple() should not set tm_isdst flag to 0
In-Reply-To: <1276659404.06.0.425467293989.issue9004@psf.upfronthosting.co.za>
Message-ID: <1276659404.06.0.425467293989.issue9004@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

I find the following quite misleading:

>>> from datetime import datetime
>>> import time
>>> time.strftime('%c %z %Z', datetime.utcnow().utctimetuple())
'Wed Jun 16 03:26:26 2010 -0500 EST'

As far as I can tell, the only other function that uses the tm_isdst flag is time.mktime, but it expect a timetuple containing local time, not UTC time.

----------
assignee: belopolsky
components: Extension Modules
messages: 107906
nosy: belopolsky, mark.dickinson
priority: normal
severity: normal
stage: unit test needed
status: open
title: datetime.utctimetuple() should not set tm_isdst flag to 0
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9004>
_______________________________________

From report at bugs.python.org  Wed Jun 16 05:57:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 03:57:07 +0000
Subject: [issue9005] Year range in timetuple
In-Reply-To: <1276660627.85.0.364876080456.issue9005@psf.upfronthosting.co.za>
Message-ID: <1276660627.85.0.364876080456.issue9005@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Current datetime.timetuple() implementation goes out of its way to support edge cases that produce timetuples beyond the naive datetime range:

>>> t1 = datetime.min.replace(tzinfo=timezone.max)
>>> t2 = datetime.max.replace(tzinfo=timezone.min)
>>> print(t1.utctimetuple())
time.struct_time(tm_year=0, tm_mon=12, tm_mday=31, tm_hour=0, tm_min=1, tm_sec=0, tm_wday=6, tm_yday=366, tm_isdst=0)
>>> print(t2.utctimetuple())
time.struct_time(tm_year=10000, tm_mon=1, tm_mday=1, tm_hour=23, tm_min=58, tm_sec=59, tm_wday=5, tm_yday=1, tm_isdst=0)

The last result is particularly troublesome because it may crash time.asctime on POSIX compliant systems.  See Issue #6608.

tm_year is described in help(time) as 4-digit year suggesting range of [1000, 9999].  Most C libraries support even smaller ranges.

----------
assignee: belopolsky
components: Extension Modules
messages: 107907
nosy: belopolsky, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Year range in timetuple
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9005>
_______________________________________

From report at bugs.python.org  Wed Jun 16 05:58:38 2010
From: report at bugs.python.org (geremy condra)
Date: Wed, 16 Jun 2010 03:58:38 +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: <1276660718.96.0.375818001543.issue1589@psf.upfronthosting.co.za>


Changes by geremy condra <debatem1 at gmail.com>:


----------
nosy: +debatem1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Jun 16 06:33:02 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 16 Jun 2010 04:33:02 +0000
Subject: [issue9000] Provide parseable repr to datetime.timezone
In-Reply-To: <1276617170.01.0.394704824446.issue9000@psf.upfronthosting.co.za>
Message-ID: <1276662782.31.0.0198552375655.issue9000@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/issue9000>
_______________________________________

From report at bugs.python.org  Wed Jun 16 07:58:05 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 16 Jun 2010 05:58:05 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1276667885.78.0.491674764631.issue8577@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Tarek: I'm not 100% that all my changes in Lib/distutils were backported to 3.1. This last patch definitely wasn't, but isn't also isn't relevant for 3.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Wed Jun 16 11:13:30 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 16 Jun 2010 09:13:30 +0000
Subject: [issue7370] patch: BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1276679610.04.0.501586090016.issue7370@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I do not like the idea that BaseHTTPServer depends on email package, which in turn may depend on another package etc. Having date formatting function inside of email package breaks "single responsibility" principle that would be nice to have in stdlib.

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Wed Jun 16 11:20:36 2010
From: report at bugs.python.org (=?utf-8?q?Timoth=C3=A9e_CEZARD?=)
Date: Wed, 16 Jun 2010 09:20:36 +0000
Subject: [issue9006] xml-rpc Server object does not propagate the encoding to
	Unmarshaller
In-Reply-To: <1276680036.39.0.0895862907842.issue9006@psf.upfronthosting.co.za>
Message-ID: <1276680036.39.0.0895862907842.issue9006@psf.upfronthosting.co.za>


New submission from Timoth?e CEZARD <tim.cezard at gmail.com>:

xmlrpc cleint  (Server class) default encoding is utf-8 it can be modified through the encoding keyword parameter. This parameter is not passed to the Unmarshaller that decode the bit flow causing the server to crash
attached is two script reproducing the issue

----------
components: XML
files: xmlrpc_bug.tar.gz
messages: 107910
nosy: Timoth?e.CEZARD
priority: normal
severity: normal
status: open
title: xml-rpc Server object does not propagate the encoding to Unmarshaller
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file17682/xmlrpc_bug.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9006>
_______________________________________

From report at bugs.python.org  Wed Jun 16 12:12:23 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 16 Jun 2010 10:12:23 +0000
Subject: [issue9007] CGIHTTPServer
In-Reply-To: <1276683142.96.0.591092806304.issue9007@psf.upfronthosting.co.za>
Message-ID: <1276683142.96.0.591092806304.issue9007@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

CGIHTTPServer only supports Python CGI scripts. That should be reflected in documentation.

----------
assignee: docs at python
components: Documentation
messages: 107911
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: CGIHTTPServer
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/issue9007>
_______________________________________

From report at bugs.python.org  Wed Jun 16 12:12:42 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 16 Jun 2010 10:12:42 +0000
Subject: [issue9007] CGIHTTPServer supports only Python CGI scripts
In-Reply-To: <1276683142.96.0.591092806304.issue9007@psf.upfronthosting.co.za>
Message-ID: <1276683162.8.0.379288593819.issue9007@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
title: CGIHTTPServer -> CGIHTTPServer supports only Python CGI scripts

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9007>
_______________________________________

From report at bugs.python.org  Wed Jun 16 12:13:44 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 16 Jun 2010 10:13:44 +0000
Subject: [issue9008] CGIHTTPServer support for arbitrary CGI scripts
In-Reply-To: <1276683224.45.0.0857224786266.issue9008@psf.upfronthosting.co.za>
Message-ID: <1276683224.45.0.0857224786266.issue9008@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

CGIHTTPServer should support all CGI scripts, not only Python ones.

----------
components: Library (Lib)
messages: 107912
nosy: techtonik
priority: normal
severity: normal
status: open
title: CGIHTTPServer support for arbitrary CGI scripts
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9008>
_______________________________________

From report at bugs.python.org  Wed Jun 16 13:38:49 2010
From: report at bugs.python.org (holger krekel)
Date: Wed, 16 Jun 2010 11:38:49 +0000
Subject: [issue8720] undo findsource regression/change
In-Reply-To: <1273877995.17.0.0354087541128.issue8720@psf.upfronthosting.co.za>
Message-ID: <1276688329.8.0.554724533799.issue8720@psf.upfronthosting.co.za>


holger krekel <holger.krekel at gmail.com> added the comment:

Seems the inspect.getsourcefile regression now is in the RC1 of Python2.7 as well.  I suggest to apply the "getsourcefile.patch" patch which was attached from David.  I tested it and it works fine for Python2.7 and Python3.1.

----------
status: open -> pending
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8720>
_______________________________________

From report at bugs.python.org  Wed Jun 16 13:56:47 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 16 Jun 2010 11:56:47 +0000
Subject: [issue1711605] CGIHttpServer leaves traces of previous requests in env
Message-ID: <1276689407.24.0.876858110769.issue1711605@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I don't see why it modifies os.environ at all environ it passed as argument to child subprocess.

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1711605>
_______________________________________

From report at bugs.python.org  Wed Jun 16 13:58:11 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 16 Jun 2010 11:58:11 +0000
Subject: [issue1711605] CGIHttpServer leaves traces of previous requests in env
Message-ID: <1276689491.63.0.619094508649.issue1711605@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I can't edit my comment. That suxx. It should be
"...at all if environ is passed..."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1711605>
_______________________________________

From report at bugs.python.org  Wed Jun 16 14:14:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 16 Jun 2010 12:14:42 +0000
Subject: [issue9008] CGIHTTPServer support for arbitrary CGI scripts
In-Reply-To: <1276683224.45.0.0857224786266.issue9008@psf.upfronthosting.co.za>
Message-ID: <1276690482.26.0.834719924857.issue9008@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I suspect this bug will sit here languishing without action, for various reasons:

1) From other doc discussion, I assume you won?t be able to propose a patch.

2) There is no dedicated maintainer for http or cgi.

3) CGI is a low-level, archaic, inefficient interface.

4) The cgi server has grave bugs like this one (from the doc):
?CGI scripts run by the CGIHTTPRequestHandler class cannot execute redirects (HTTP code 302), because code 200 (script output follows) is sent prior to execution of the CGI script.?

----------
nosy: +merwok
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9008>
_______________________________________

From report at bugs.python.org  Wed Jun 16 14:16:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 16 Jun 2010 12:16:38 +0000
Subject: [issue9008] CGIHTTPServer support for arbitrary CGI scripts
In-Reply-To: <1276683224.45.0.0857224786266.issue9008@psf.upfronthosting.co.za>
Message-ID: <1276690598.97.0.689315347948.issue9008@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Forgot the conclusion: I suspect noone will want to work on that.

(I removed 2.7 since it?s feature frozen.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9008>
_______________________________________

From report at bugs.python.org  Wed Jun 16 14:20:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 16 Jun 2010 12:20:56 +0000
Subject: [issue9006] xml-rpc Server object does not propagate the encoding to
	Unmarshaller
In-Reply-To: <1276680036.39.0.0895862907842.issue9006@psf.upfronthosting.co.za>
Message-ID: <1276690856.73.0.393117009086.issue9006@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank your for reporting this bug. Are you able to reproduce the bug with current development versions, a.k.a. 2.7 (svn trunk, or the rc release) and 3.2 (py3k branch)? Only security and documentation fixes go in stable releases like 2.6 and 3.1. Also, please upload separate files instead of archives, it?s easier for review. Thanks again!

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9006>
_______________________________________

From report at bugs.python.org  Wed Jun 16 14:54:24 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 16 Jun 2010 12:54:24 +0000
Subject: [issue9008] CGIHTTPServer support for arbitrary CGI scripts
In-Reply-To: <1276690598.97.0.689315347948.issue9008@psf.upfronthosting.co.za>
Message-ID: <20100616125413.GA12400@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Wed, Jun 16, 2010 at 12:16:38PM +0000, ?ric Araujo wrote:
> Forgot the conclusion: I suspect noone will want to work on that.

Nope, please don't come to that conclusion soon. It is a valid
request. It is not that only maintainers listed will work on those.

> (I removed 2.7 since it?s feature frozen.)

This is fine.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9008>
_______________________________________

From report at bugs.python.org  Wed Jun 16 15:13:35 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 16 Jun 2010 13:13:35 +0000
Subject: [issue9007] CGIHTTPServer supports only Python CGI scripts
In-Reply-To: <1276683142.96.0.591092806304.issue9007@psf.upfronthosting.co.za>
Message-ID: <1276694015.96.0.55129657808.issue9007@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority: normal -> low
stage:  -> needs patch
type:  -> behavior
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9007>
_______________________________________

From report at bugs.python.org  Wed Jun 16 15:19:39 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 16 Jun 2010 13:19:39 +0000
Subject: [issue7370] BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1276694379.73.0.296462698018.issue7370@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
title: patch: BaseHTTPServer reinventing rfc822 date formatting -> BaseHTTPServer reinventing rfc822 date formatting

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Wed Jun 16 15:29:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 16 Jun 2010 13:29:16 +0000
Subject: [issue9008] CGIHTTPServer support for arbitrary CGI scripts
In-Reply-To: <20100616125413.GA12400@remy>
Message-ID: <4C18D1A9.5020305@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Sorry, somehow I forgot the ton of work you?ve been putting into
urlparse and urllib :)

Note that I never said or thought it was an invalid request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9008>
_______________________________________

From report at bugs.python.org  Wed Jun 16 15:38:32 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 16 Jun 2010 13:38:32 +0000
Subject: [issue9008] CGIHTTPServer support for arbitrary CGI scripts
In-Reply-To: <1276690482.26.0.834719924857.issue9008@psf.upfronthosting.co.za>
Message-ID: <AANLkTimJbiTUPKueevbz5e8Gc02ZjeHLDtABYLNU2lqc@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

> I suspect this bug will sit here languishing without action, for various reasons:

I suspect this kind of discussions piss off readers of tickets, but
I'll continue, as I do not see any other useful public medium at hand
right now.

-- start offtopic --

> 1) From other doc discussion, I assume you won?t be able to propose a patch.

Right. I do not feel comfortable with Python workflow - now that I
have several dozens of unfinished patches - they start to conflict
with changes in repository. Conflict resolution takes a lot of time
and I can't afford maintaining a separate copy of Python checkout for
every patch. It also takes too long to setup test environment and
execute tests. There is a lot of yak shaving involved between:
1. make ticket
2. find source
3. make patch
4. test patch
5. attach patch
6. refresh patch
7. test patch
8. attach patch
...

I've already explained it somewhere in more detail. A pity it is lost.

I am waiting for Mercurial 1.6 to try anchored MQ. Perhaps then I will
be able to revisit Python contribution process.

> 2) There is no dedicated maintainer for http or cgi.

I can not be. pydotorg tools suxx tremendously and I do not feel
inspired by wasting time trying to fish required information. To be a
maintainer I need:
1. separate commit notifications for the module with ability to reply
to dedicated review group
2. separate bug tracker category for my module with giving users
ability to change every property of it
3. bug tracker timeline for the module that includes ticket changes,
wiki edits, commits and everything else. Filtered.
4. roadmap page with Google Wave content for collaborations
5. dashboard page with links to all the above

Look at Trac Hacks for a minimum acceptable example of a tool that is
able to persuade me to become a stdlib module developer. Sorry for not
able to compile this into a report for EuroPython.

> 3) CGI is a low-level, archaic, inefficient interface.

stdlib doesn't propose anything better.

-- end offtopic --

> 4) The cgi server has grave bugs like this one (from the doc):
> ?CGI scripts run by the CGIHTTPRequestHandler class cannot execute redirects (HTTP code 302), because code 200 (script output follows) is sent prior to execution of the CGI script.?

It would be nice if this also clarify if it is the bug of Python class
or a limitation of CGI protocol.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9008>
_______________________________________

From report at bugs.python.org  Wed Jun 16 15:58:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Jun 2010 13:58:32 +0000
Subject: [issue9008] CGIHTTPServer support for arbitrary CGI scripts
In-Reply-To: <1276683224.45.0.0857224786266.issue9008@psf.upfronthosting.co.za>
Message-ID: <1276696712.34.0.308813921281.issue9008@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Conflict resolution takes a lot of time
> and I can't afford maintaining a separate copy of Python checkout for
> every patch

Then try various hg features such as named branches, or bookmarks, or mq, or pbranch, etc.
(or any SVN-facing tool you would like, including git-svn, bzr-svn, etc.)

> To be a maintainer I need:
[snip]

Most people in most open source projects seem perfectly content without such an artillery of sophisticated tools/gadgets. While the workflow can always be improved, it is not obvious to me that your requirements are in any way reasonable, or even serious ("serious" as in "this is the only reasonable way one can work efficiently on Python" -- plenty of people, almost all of them unpaid volunteers, seem to disagree).

By the way, the first thing needed to qualify as a maintainer would be to *prove* that you are up to the task. Not to have a bunch of nifty tools. In other words, you can't just come and say "hey, I'd like to be a maintainer" and expect this request to be granted automatically.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9008>
_______________________________________

From report at bugs.python.org  Wed Jun 16 16:00:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Jun 2010 14:00:48 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

I've opened this issue to track efforts to improve the quality of the Python/dtoa.c file, which provides Python's string-to-float and float-to-string conversions.

Particular issues in mind (non-exhaustive):

 - do a thorough review and test of _Py_dg_dtoa;  this has already
   been done for _Py_dg_strtod (issue 7632, issue 7743), and uncovered
   several problems, including a memory leak, some asserts that were
   triggered in debug mode, and many cases of wrong output.   

 - break out the parsing code from _Py_dg_strtod into a separate
   function, for clarity and maintainability (and possible re-use
   of the parsing code itself)

 - improve _Py_dg_strtod tests, by using contined-fractions to generate
   and test particularly difficult cases.

 - _Py_dg_strtod silently gives wrong results for huge inputs;  while
   not particular serious, this is easily avoidable.

 - improve API to rely on errno less.

 - some pieces of code are currently unused;  improve code coverage
   and tests to identify thoses pieces and remove them.

 - the current code is convoluted in places and hard to explain;
   at least some extra comments should be added.

 - try to make Python/dtoa.c as Python-agnostic as possible, so that
   the code can be reused in other projects where desired.

----------
assignee: mark.dickinson
components: Interpreter Core
messages: 107923
nosy: eric.smith, mark.dickinson
priority: normal
severity: normal
status: open
title: Improve quality of Python/dtoa.c
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Wed Jun 16 16:24:26 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 16 Jun 2010 14:24:26 +0000
Subject: [issue9003] urllib about https behavior
In-Reply-To: <1276650277.98.0.113951617798.issue9003@psf.upfronthosting.co.za>
Message-ID: <1276698266.52.0.758540991696.issue9003@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/issue9003>
_______________________________________

From report at bugs.python.org  Wed Jun 16 16:32:39 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 16 Jun 2010 14:32:39 +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: <1276698759.84.0.91814391298.issue1589@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/issue1589>
_______________________________________

From report at bugs.python.org  Wed Jun 16 16:36:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 14:36:31 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1276698991.89.0.853302429755.issue9009@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From orsenthil at gmail.com  Wed Jun 16 14:54:13 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Wed, 16 Jun 2010 18:24:13 +0530
Subject: [issue9008] CGIHTTPServer support for arbitrary CGI scripts
In-Reply-To: <1276690598.97.0.689315347948.issue9008@psf.upfronthosting.co.za>
References: <1276683224.45.0.0857224786266.issue9008@psf.upfronthosting.co.za>
	<1276690598.97.0.689315347948.issue9008@psf.upfronthosting.co.za>
Message-ID: <20100616125413.GA12400@remy>

On Wed, Jun 16, 2010 at 12:16:38PM +0000, ?ric Araujo wrote:
> Forgot the conclusion: I suspect noone will want to work on that.

Nope, please don't come to that conclusion soon. It is a valid
request. It is not that only maintainers listed will work on those.


> (I removed 2.7 since it?s feature frozen.)

This is fine.

From report at bugs.python.org  Wed Jun 16 16:44:57 2010
From: report at bugs.python.org (=?utf-8?q?Timoth=C3=A9e_CEZARD?=)
Date: Wed, 16 Jun 2010 14:44:57 +0000
Subject: [issue9006] xml-rpc Server object does not propagate the encoding to
	Unmarshaller
In-Reply-To: <1276680036.39.0.0895862907842.issue9006@psf.upfronthosting.co.za>
Message-ID: <1276699497.12.0.968570469221.issue9006@psf.upfronthosting.co.za>


Timoth?e CEZARD <tim.cezard at gmail.com> added the comment:

With 2.7 I'm getting another exception 
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 5, column 15
where with 2.6 I was getting 
UnicodeDecodeError: 'utf8' codec can't decode byte 0xa3 in position 0: unexpected code byte
I didn't try with 3.2 yet.

I also "fixed" the bug in 2.6 by passing the encoding stored in ServerProxy to Transport and then Unmarshaller.
I probably did not do it the proper way but it works now

----------
Added file: http://bugs.python.org/file17683/xmlrpclib_fixed.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9006>
_______________________________________

From report at bugs.python.org  Wed Jun 16 17:11:25 2010
From: report at bugs.python.org (Ruben Bakker)
Date: Wed, 16 Jun 2010 15:11:25 +0000
Subject: [issue9010] Infinite loop in imaplib.IMAP4_SSL when used with Gmail
In-Reply-To: <1276701085.45.0.35769519286.issue9010@psf.upfronthosting.co.za>
Message-ID: <1276701085.45.0.35769519286.issue9010@psf.upfronthosting.co.za>


New submission from Ruben Bakker <ruben.bakker1 at gmail.com>:

When using imaplib.IMAP4_SSL to open a Gmail mailbox, the readline method can go into a infinite loop. It happens after Gmail drops the connection, usually after some time/inactivity. The next imaplib request will cause the infinite loop inside the readline() method.

Steps to reproduce:
Perform this script (use python -i to get the prompt):

import imaplib

HOST="imap.gmail.com"
PORT=993
USERNAME="username at gmail.com"
PASSWORD="password"

server = imaplib.IMAP4_SSL(host=HOST, port=PORT)
server.login(USERNAME, PASSWORD)

def f():
	print server.select("INBOX")
	print server.uid("FETCH", "1:*", "(UID FLAGS BODY.PEEK[HEADER.FIELDS (Subject)])")

Call the f() function and then wait about about an hour. Call f() again and server.select() will not return but take all CPU.

Add this line in IMAP4_SSL
          if not char: raise self.abort('socket error: EOF')

complete method:
    def readline(self):
        """Read line from remote."""
        line = []
        while 1:
            char = self.sslobj.read(1)
            if not char: raise self.abort('socket error: EOF')
            line.append(char)
            if char == "\n": return ''.join(line)

----------
components: Library (Lib)
messages: 107925
nosy: Ruben.Bakker
priority: normal
severity: normal
status: open
title: Infinite loop in imaplib.IMAP4_SSL when used with Gmail
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9010>
_______________________________________

From report at bugs.python.org  Wed Jun 16 17:12:54 2010
From: report at bugs.python.org (Ruben Bakker)
Date: Wed, 16 Jun 2010 15:12:54 +0000
Subject: [issue9010] Infinite loop in imaplib.IMAP4_SSL when used with Gmail
In-Reply-To: <1276701085.45.0.35769519286.issue9010@psf.upfronthosting.co.za>
Message-ID: <1276701174.85.0.533594836982.issue9010@psf.upfronthosting.co.za>


Ruben Bakker <ruben.bakker1 at gmail.com> added the comment:

I forgot to mention that the section after "Add this line to IMAP4_SSL" describes the solution. Sorry about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9010>
_______________________________________

From report at bugs.python.org  Wed Jun 16 17:13:17 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 16 Jun 2010 15:13:17 +0000
Subject: [issue8937] SimpleHTTPServer should contain usage example
In-Reply-To: <1275975534.8.0.563527396515.issue8937@psf.upfronthosting.co.za>
Message-ID: <1276701197.99.0.661041918162.issue8937@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r82018.

----------
nosy: +orsenthil
resolution:  -> fixed
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8937>
_______________________________________

From report at bugs.python.org  Wed Jun 16 17:39:00 2010
From: report at bugs.python.org (Alex Samuel)
Date: Wed, 16 Jun 2010 15:39:00 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>


New submission from Alex Samuel <alex at alexsamuel.net>:

The unary negative optimization in ast_for_factor() seems to modify the ST in a way changes its meaning.

In Python 3.1.2, the ST is no longer compilable:

$ cat exprbug.py
import parser

st = parser.expr("-3")
print(st.totuple())
compiled = st.compile()
print(eval(compiled))
print(st.totuple())
print(eval(st.compile()))

$ ~/sw/Python-3.1.2/bin/python3 exprbug.py
(258, (326, (301, (305, (306, (307, (308, (310, (311, (312, (313, (314, (315, (316, (317, (15, '-'), (317, (318, (319, (2, '3')))))))))))))))))), (4, ''), (0, ''))
-3
(258, (326, (301, (305, (306, (307, (308, (310, (311, (312, (313, (314, (315, (316, (317, (15, '-'), (317, (318, (319, (2, '-3')))))))))))))))))), (4, ''), (0, ''))
Traceback (most recent call last):
  File "exprbug.py", line 8, in <module>
    print(eval(st.compile()))
ValueError: could not convert string to float: --3


In earlier versions of Python (I have confirmed 2.5 and 2.6), it is compiled to incorrect code and produces wrong results when evaluated:

$ ~/sw/Python-2.6.2/bin/python exprbug.py
(258, (327, (304, (305, (306, (307, (308, (310, (311, (312, (313, (314, (315, (316, (15, '-'), (316, (317, (318, (2, '3'))))))))))))))))), (4, ''), (0, ''))
-3
(258, (327, (304, (305, (306, (307, (308, (310, (311, (312, (313, (314, (315, (316, (15, '-'), (316, (317, (318, (2, '-3'))))))))))))))))), (4, ''), (0, ''))
-1.0


If I remove the big if statement from the front of ast_to_factor(), the code behaves correctly.  I think this is because STR(pnum) is changed in place and never restored to its previous value.

----------
components: Interpreter Core
messages: 107928
nosy: alexhsamuel
priority: normal
severity: normal
status: open
title: ast_for_factor unary minus optimization changes AST
type: behavior
versions: Python 2.5, Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Wed Jun 16 17:46:54 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 15:46:54 +0000
Subject: [issue9012] Separate compilation of time and datetime modules
In-Reply-To: <1276703214.18.0.763658156575.issue9012@psf.upfronthosting.co.za>
Message-ID: <1276703214.18.0.763658156575.issue9012@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Here is the history of the issue per Martin v. L?wis on python-dev:

"""

This was added with

------------------------------------------------------------------------
r36221 | bcannon | 2004-06-24 03:38:47 +0200 (Do, 24. Jun 2004) | 3 Zeilen

Add compilation of timemodule.c with datetimemodule.c to get
__PyTime_DoubleToTimet().

------------------------------------------------------------------------

So it's clearly intentional. I doubt its desirable, though. If only
__PyTime_DoubleToTimet needs to be duplicated, I'd rather put that
function into a separate C file that gets included twice, instead of including the full timemodule.c into datetimemodule.c.
"""
-- "Sharing functions between C extension modules in stdlib", http://mail.python.org/pipermail/python-dev/2010-June/100587.html

I hope this is non-controversial, but I would like someone to comment on the choice of file name.  I chose _timefunc.c to make it more distinguishable from module file names.  Ideally, however I would like to see this in either _time.h/_time.c pair (both in Module dir like _math.{c,h}) or in pytime.h/pytime.c (like pymath.{c,h}).

Marking this as "resource usage" because the patch will result in smaller size of datetime module.

----------
assignee: belopolsky
messages: 107929
nosy: belopolsky, brett.cannon, loewis, mark.dickinson
priority: normal
severity: normal
stage: patch review
status: open
title: Separate compilation of time and datetime modules
type: resource usage
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9012>
_______________________________________

From report at bugs.python.org  Wed Jun 16 17:50:50 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 15:50:50 +0000
Subject: [issue9012] Separate compilation of time and datetime modules
In-Reply-To: <1276703214.18.0.763658156575.issue9012@psf.upfronthosting.co.za>
Message-ID: <1276703450.63.0.833842937607.issue9012@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
keywords: +patch
Added file: http://bugs.python.org/file17684/timefunc-split.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9012>
_______________________________________

From report at bugs.python.org  Wed Jun 16 17:56:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 16 Jun 2010 15:56:59 +0000
Subject: [issue9010] Infinite loop in imaplib.IMAP4_SSL when used with Gmail
In-Reply-To: <1276701085.45.0.35769519286.issue9010@psf.upfronthosting.co.za>
Message-ID: <1276703819.37.0.364564448254.issue9010@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The readline return on '' was introduced by the patch for issue 5949, which discusses the fact that SSL may return '' indefinitely in some situations.  I've merged the nosy list from that issue to this one; anyone who isn't interested, my apologies and please delete yourself.  I'm especially hoping that Scott Dial will understand what is going on here and be able to suggest a fix.

I'm guessing this affects all maintained versions, but since that hasn't been tested I'm not updating the versions list.  Ruben, if you can test it with 2.7RC1 that would be especially helpful, since there are other fixes in 2.7 that may affect this, and if this is a regression we'll want to fix it before the next RC.

----------
nosy: +benjamin.peterson, janssen, kevinwatters, ncoghlan, r.david.murray, rhettinger, rmore, rtucker, scott.dial
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9010>
_______________________________________

From report at bugs.python.org  Wed Jun 16 17:58:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 16 Jun 2010 15:58:53 +0000
Subject: [issue9010] Infinite loop in imaplib.IMAP4_SSL when used with Gmail
In-Reply-To: <1276701085.45.0.35769519286.issue9010@psf.upfronthosting.co.za>
Message-ID: <1276703933.55.0.923596326197.issue9010@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Wait a minute, I misread your message.  You don't show the return on ''.  So I think perhaps the #5949 patch fixes this.  Ruben, can you please test with 2.7RC1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9010>
_______________________________________

From report at bugs.python.org  Wed Jun 16 18:02:33 2010
From: report at bugs.python.org (vijay)
Date: Wed, 16 Jun 2010 16:02:33 +0000
Subject: [issue5712] tkinter - askopenfilenames returns string instead of
	tuple in windows 2.6.1 release
In-Reply-To: <1239039911.64.0.172824576559.issue5712@psf.upfronthosting.co.za>
Message-ID: <1276704153.23.0.245807696324.issue5712@psf.upfronthosting.co.za>


vijay <vijay.psaibola at gmail.com> added the comment:

Two issues related with the workaround suggested by nosklo.

1. Splitting the filepaths isnt simple, as there may be blank spaces etc.
2. We have different versions of Python installed in our Lab machines, some have 2.5 and others got 2.6. If I run the code using the version2.6 workaround on a machine with version2.5, obviously it gives an error!!

Any updates on a fix? This bug is really giving me a hard time.

----------
nosy: +luckycusp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5712>
_______________________________________

From report at bugs.python.org  Wed Jun 16 18:12:45 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Wed, 16 Jun 2010 16:12:45 +0000
Subject: [issue9010] Infinite loop in imaplib.IMAP4_SSL when used with Gmail
In-Reply-To: <1276701085.45.0.35769519286.issue9010@psf.upfronthosting.co.za>
Message-ID: <1276704765.38.0.582722428279.issue9010@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

"import imaplib

HOST="imap.gmail.com"
PORT=993
USERNAME="username at gmail.com"
PASSWORD="password"

server = imaplib.IMAP4_SSL(host=HOST, port=PORT)
server.login(USERNAME, PASSWORD)

def f():
	print server.select("INBOX")
	print server.uid("FETCH", "1:*", "(UID FLAGS BODY.PEEK[HEADER.FIELDS (Subject)])")

Call the f() function and then wait about about an hour. Call f() again and server.select() will not return but take all CPU."

Tried to reproduce this on Python 2.7RC1. Seemed Ok to me. Took some 3 seconds to call f() not only once, but twice, thrice.

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9010>
_______________________________________

From report at bugs.python.org  Wed Jun 16 18:46:24 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 16 Jun 2010 16:46:24 +0000
Subject: [issue8937] SimpleHTTPServer should contain usage example
In-Reply-To: <1275975534.8.0.563527396515.issue8937@psf.upfronthosting.co.za>
Message-ID: <1276706784.59.0.279461588047.issue8937@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Merged into other branches in r82020, r82022 and r82023.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8937>
_______________________________________

From report at bugs.python.org  Wed Jun 16 18:46:34 2010
From: report at bugs.python.org (vijay)
Date: Wed, 16 Jun 2010 16:46:34 +0000
Subject: [issue5712] tkinter - askopenfilenames returns string instead of
	tuple in windows 2.6.1 release
In-Reply-To: <1239039911.64.0.172824576559.issue5712@psf.upfronthosting.co.za>
Message-ID: <1276706794.86.0.5647842789.issue5712@psf.upfronthosting.co.za>


vijay <vijay.psaibola at gmail.com> added the comment:

Update!! I found a very good workaround for this and it works very nicely, with both 2.5 and 2.6 versions. 

Below is the segment from my code:-

from Tkinter import *
import tkFileDialog

master = Tk()
master.withdraw() #hiding tkinter window

Inputfiles = tkFileDialog.askopenfilenames(title="Select the source input file(s)", filetypes=[("mpf file",".mpf"),("All files",".*")])

#Heres the TRICK!
InputfilesList =  master.tk.splitlist(Inputfiles)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5712>
_______________________________________

From report at bugs.python.org  Wed Jun 16 18:47:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 16:47:04 +0000
Subject: [issue9012] Separate compilation of time and datetime modules
In-Reply-To: <1276703214.18.0.763658156575.issue9012@psf.upfronthosting.co.za>
Message-ID: <1276706824.16.0.226282826414.issue9012@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Based on IRC discussion, here is a modified patch that places C code in _time.c and creates a stub for _time.h so that future shared definitions can go there.

----------
Added file: http://bugs.python.org/file17685/issue9012.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9012>
_______________________________________

From report at bugs.python.org  Wed Jun 16 18:47:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 16:47:12 +0000
Subject: [issue9012] Separate compilation of time and datetime modules
In-Reply-To: <1276703214.18.0.763658156575.issue9012@psf.upfronthosting.co.za>
Message-ID: <1276706832.55.0.51444682026.issue9012@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9012>
_______________________________________

From report at bugs.python.org  Wed Jun 16 18:47:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 16:47:27 +0000
Subject: [issue9012] Separate compilation of time and datetime modules
In-Reply-To: <1276703214.18.0.763658156575.issue9012@psf.upfronthosting.co.za>
Message-ID: <1276706847.36.0.150084923384.issue9012@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9012>
_______________________________________

From report at bugs.python.org  Wed Jun 16 18:54:21 2010
From: report at bugs.python.org (Justin Samuel)
Date: Wed, 16 Jun 2010 16:54:21 +0000
Subject: [issue9003] urllib about https behavior
In-Reply-To: <1276650277.98.0.113951617798.issue9003@psf.upfronthosting.co.za>
Message-ID: <1276707261.34.0.997254510065.issue9003@psf.upfronthosting.co.za>


Changes by Justin Samuel <js at justinsamuel.com>:


----------
nosy: +jsamuel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9003>
_______________________________________

From report at bugs.python.org  Wed Jun 16 18:54:41 2010
From: report at bugs.python.org (Justin Samuel)
Date: Wed, 16 Jun 2010 16:54:41 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1276707281.81.0.120070261447.issue8998@psf.upfronthosting.co.za>


Changes by Justin Samuel <js at justinsamuel.com>:


----------
nosy: +jsamuel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Wed Jun 16 18:54:48 2010
From: report at bugs.python.org (Justin Samuel)
Date: Wed, 16 Jun 2010 16:54:48 +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: <1276707288.04.0.306014629837.issue1589@psf.upfronthosting.co.za>


Changes by Justin Samuel <js at justinsamuel.com>:


----------
nosy: +jsamuel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Jun 16 18:57:58 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 16:57:58 +0000
Subject: [issue9012] Separate compilation of time and datetime modules
In-Reply-To: <1276703214.18.0.763658156575.issue9012@psf.upfronthosting.co.za>
Message-ID: <1276707478.39.0.591536214763.issue9012@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Added new Module/_time.h to the patch.

----------
Added file: http://bugs.python.org/file17686/issue9012.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9012>
_______________________________________

From report at bugs.python.org  Wed Jun 16 18:58:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 16:58:03 +0000
Subject: [issue9012] Separate compilation of time and datetime modules
In-Reply-To: <1276703214.18.0.763658156575.issue9012@psf.upfronthosting.co.za>
Message-ID: <1276707483.67.0.560991937119.issue9012@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17685/issue9012.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9012>
_______________________________________

From report at bugs.python.org  Wed Jun 16 19:04:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Jun 2010 17:04:56 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1276707896.99.0.472142143728.issue9009@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Created new 'py3k-dtoa' branch for this work in r82024.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Wed Jun 16 19:29:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 16 Jun 2010 17:29:42 +0000
Subject: [issue5610] email feedparser.py CRLFLF bug: $ vs \Z
In-Reply-To: <1238435977.23.0.604038870745.issue5610@psf.upfronthosting.co.za>
Message-ID: <1276709382.36.0.582565630592.issue5610@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

NLCR_eol patch merged to 2.6 in r82010, py3k in r82011, and 3.1 in r82012.

Since there's been no further feedback I'll close this.  If someone comes up with a test case for the boundary_re, they can open a new issue.

----------
resolution:  -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5610>
_______________________________________

From report at bugs.python.org  Wed Jun 16 19:58:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 17:58:31 +0000
Subject: [issue9013] Implement tzinfo.dst() method in timezone
In-Reply-To: <1276711111.49.0.476665122732.issue9013@psf.upfronthosting.co.za>
Message-ID: <1276711111.49.0.476665122732.issue9013@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

This idea was brought in the original fixed offset timezone proposal (see issue 5094), but was met with some opposition.  See msg106914, point 2. As a result, the timezone implementation is in conflict with tzinfo documentation that says "If utcoffset() does not return None, dst() should not return None either." http://docs.python.org/dev/py3k/library/datetime.html#datetime.tzinfo.utcoffset


Note that dst() is not needed for time calculations involving fixed offset timezones because DST shift is included in utcoffset().  It is however needed for interoperability with timetuple time representation. See issue9004.

If the long term goal is to move users from using timetuples to to datetime objects, it is important for time objects to be able to store DST flag.

----------
assignee: belopolsky
components: Extension Modules
messages: 107940
nosy: belopolsky
priority: normal
severity: normal
stage: unit test needed
status: open
title: Implement tzinfo.dst() method in timezone
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9013>
_______________________________________

From report at bugs.python.org  Wed Jun 16 20:00:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 18:00:56 +0000
Subject: [issue9013] Implement tzinfo.dst() method in timezone
In-Reply-To: <1276711111.49.0.476665122732.issue9013@psf.upfronthosting.co.za>
Message-ID: <1276711256.95.0.615591993632.issue9013@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
dependencies: +datetime lacks concrete tzinfo implementation for UTC
nosy: +brett.cannon, mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9013>
_______________________________________

From report at bugs.python.org  Wed Jun 16 20:13:40 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 16 Jun 2010 18:13:40 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <1275175831.39.0.913540756271.issue8854@psf.upfronthosting.co.za>
Message-ID: <1276712020.21.0.0162659094718.issue8854@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Here's a patch fixing the problem.

----------
keywords: +patch
versions: +Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17687/msvc9compiler.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Wed Jun 16 20:16:03 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 16 Jun 2010 18:16:03 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <1275175831.39.0.913540756271.issue8854@psf.upfronthosting.co.za>
Message-ID: <1276712163.49.0.0599383713936.issue8854@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

If possible, the patch should go into Python 2.7 rc2, since without it, you can't build Python extensions on Windows x64 platforms.

----------
assignee: tarek -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Wed Jun 16 20:18:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Jun 2010 18:18:59 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1276712339.78.0.881866159976.issue9009@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

A couple of preparatory commits:

r82025: In _Py_dg_strtod, 'e' now represents the adjusted exponent rather than the base exponent;  that is, the input value is of the form +- m * 10**e with 0.1 <= m < 1.0.  It's easier to produce such an 'e' from the parsing stage if we care about detecting overflow and underflow.

r82031: Update the s2b function:  remove a premature optimization in order to make s2b more general and its correctness more easily verifiable; alter the way that the input string is parsed so that it doesn't depend on nd0 being in the range [0, nd].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Wed Jun 16 20:19:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Jun 2010 18:19:41 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1276712381.91.0.720897790596.issue9009@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

And here's a patch to pull out the parsing stage of _Py_dg_strtod into a separate function.

----------
keywords: +patch
Added file: http://bugs.python.org/file17688/dtoa_parsing.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Wed Jun 16 20:41:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Jun 2010 18:41:31 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1276713691.67.0.39743517012.issue9009@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r82032: Commit some additional tests for test_strtod.py.

test_extra_long_significand will currently fail;  with the dtoa_parsing patch, it passes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Wed Jun 16 20:43:14 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Jun 2010 18:43:14 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1276713794.12.0.288373851345.issue9009@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
stage:  -> patch review
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Wed Jun 16 20:49:30 2010
From: report at bugs.python.org (Clovis Fabricio)
Date: Wed, 16 Jun 2010 18:49:30 +0000
Subject: [issue5712] tkinter - askopenfilenames returns string instead of
	tuple in windows 2.6.1 release
In-Reply-To: <1239039911.64.0.172824576559.issue5712@psf.upfronthosting.co.za>
Message-ID: <1276714170.47.0.678104677022.issue5712@psf.upfronthosting.co.za>


Clovis Fabricio <nosklo+python at gmail.com> added the comment:

UGH! Sorry for that, I mispasted something and didn't notice, since it filled the comment entry box perfectly :(

This is the real message I meant to paste:

----------------------------

vijay,

The workaround I provided above takes the blank spaces in filepaths
you mention into account and splits the paths correctly in all
situations I can think of. I'm using it in production now for over an
year, and had no issues at all. Perhaps you can provide an example of
path that would break the code, so it can be fixed.

thanks in advance
Clovis

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5712>
_______________________________________

From report at bugs.python.org  Wed Jun 16 20:58:42 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 16 Jun 2010 18:58:42 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1276714722.78.0.297847703284.issue9009@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I realize the ship's already sailed on this issue [1], but isn't it a problem that editing this code makes it more difficult to apply patches from Gay's original code? What do we do if Gay releases a new version of his code with bug fixes?


[1] Sorry non-native American-English speakers. I mean that we already have this problem since we've already modified the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Wed Jun 16 21:09:23 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Jun 2010 19:09:23 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1276715363.04.0.825762895029.issue9009@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Gay's changes tend to be very small;  any bugfixes he releases can likely be applied by hand, if they're relevant.

I did originally want to keep close to Gay's code, but frankly I'm not very happy with the quality of that code;  and in communications with Gay it's become clear that there are issues that will not be fixed upstream, but that I consider unacceptable for Python's copy of dtoa.c.

Some examples of problems with the original code:

(1) Gay's code does no checking of return values from malloc.  We had to add those checks, which was the first point at which our code started diverging from his.

(2) There's a segment at the beginning of the bigcomp function that's unnecessary, and in fact would produce incorrect results if it were ever called;  it's just about possible to show that it *can't* ever be called.  I've asked David Gay about this, but he insists that it's necessary.  (I've removed it in Python's version of the code.)

(3) The original code silently produces wrong results for huge inputs (more than 20000 characters);  I know this is an extreme use case, but again I find this unacceptable for Python.  (I haven't asked Gay about this;  I'd be very surprised if he wanted to do anything about it, though.)

(4) The original code is horribly convoluted in places, making it very difficult to check for correctness.  (For example, see the spaghetti mess in the parsing section of strtod.c).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Wed Jun 16 21:22:54 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Jun 2010 19:22:54 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1276716174.88.0.0889060818762.issue9009@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's the section of the 'bigcomp' code that I was referring to above:

	/* Now b/d = exactly half-way between the two floating-point values */
	/* on either side of the input string.  Compute first digit of b/d. */

	if (!(dig = quorem(b,d))) {
		b = multadd(b, 10, 0);	/* very unlikely */
		dig = quorem(b,d);
		}

You can see it in the original source at http://www.netlib.org/fp/dtoa.c

This code is part of the algorithm for strtod.  Here b and d are Bigints, and b / d is a fraction that gives an approximation to the value of the input to strtod;  the aim is to produce the digits of b / d one-by-one to compare them with the strtod input, and (eventually) use the result of that comparison work out whether to round up or down.

If the condition of the 'if' block above is ever satisfied, b is multiplied by 10 (that's the multadd(b, 10, 0) call), so the fraction b / d is multiplied by 10 (with no corresponding correction for the strtod input string), and the wrong comparison is made!

There are many other similar pieces of code in _Py_dg_strtod that can never get called (I've run coverage programs over the code to help verify this);  trying to establish the correctness of the current code isn't easy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Wed Jun 16 21:25:44 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 16 Jun 2010 19:25:44 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276716174.88.0.0889060818762.issue9009@psf.upfronthosting.co.za>
Message-ID: <8fd6b811d3b084436dd1c6c51ee6f9d7.squirrel@mail.trueblade.com>


Eric Smith <eric at trueblade.com> added the comment:

Just to be clear: I'm okay with this divergence, as long as we've made it
clear we're explicitly doing so and we've given our reasons. Mark's done
that, and of course he's the expert in the subject.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Wed Jun 16 21:33:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 16 Jun 2010 19:33:15 +0000
Subject: [issue5712] tkinter - askopenfilenames returns string instead of
	tuple in windows 2.6.1 release
In-Reply-To: <1239039911.64.0.172824576559.issue5712@psf.upfronthosting.co.za>
Message-ID: <1276716795.24.0.0375404003148.issue5712@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5712>
_______________________________________

From report at bugs.python.org  Wed Jun 16 21:45:04 2010
From: report at bugs.python.org (vijay)
Date: Wed, 16 Jun 2010 19:45:04 +0000
Subject: [issue5712] tkinter - askopenfilenames returns string instead of
	tuple in windows 2.6.1 release
In-Reply-To: <1239039911.64.0.172824576559.issue5712@psf.upfronthosting.co.za>
Message-ID: <1276717504.22.0.547963784403.issue5712@psf.upfronthosting.co.za>


vijay <vijay.psaibola at gmail.com> added the comment:

Hi Clovis

Ok, I did not check if your split string function check for spaces or not, sorry for that. 

In my first post I mentioned this:-

"2. We have different versions of Python installed in our Lab machines, some have 2.5 and others got 2.6. If I run the code using the version2.6 workaround on a machine with version2.5, obviously it gives an error!!"

Infact I started out using your split string function but it was on a machine with Python2.6. It worked fine. Then I ran the same code on a machine with version Python2.5 and it threw an error when I tried calling your function, because the argument I passed to your function was already a tuple and not a string!! (I hope I could explain without confusing)

I would prefer my code to have some level of downward compatibility (to be able to run on Python of lower versions). Thats the reason I prefer to use the 'splitlist' method from Tkinter, as I dont need to change my code for different Python versions.

Best Regards
Vijay

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5712>
_______________________________________

From report at bugs.python.org  Wed Jun 16 21:58:50 2010
From: report at bugs.python.org (Renato Cunha)
Date: Wed, 16 Jun 2010 19:58:50 +0000
Subject: [issue9014] Incorrect documentation of the PyObject_HEAD macro
In-Reply-To: <1276718330.85.0.16685449654.issue9014@psf.upfronthosting.co.za>
Message-ID: <1276718330.85.0.16685449654.issue9014@psf.upfronthosting.co.za>


New submission from Renato Cunha <renato at renatocunha.com>:

PyObject_HEAD's documentation in py3k (http://docs.python.org/dev/py3k/c-api/structures.html#PyObject_HEAD) uses the same content used in the python 2.x's docs which is wrong, as there were some API changes.

PyObject_HEAD is actually defined as

#define PyObject_HEAD PyObject ob_base;

with PyObject defined as

typedef struct _object {
    _PyObject_HEAD_EXTRA
    Py_ssize_t ob_refcnt;
    struct _typeobject *ob_type;
} PyObject;

(The PyTRACE_REFS discussion is still valid, though.)

Additionally, it'd be nice to mention that the Py_REFCNT(ob) and Py_TYPE(ob) macros should be used to access the PyObject members.

----------
assignee: docs at python
components: Documentation
messages: 107953
nosy: docs at python, trovao
priority: normal
severity: normal
status: open
title: Incorrect documentation of the PyObject_HEAD macro
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9014>
_______________________________________

From report at bugs.python.org  Wed Jun 16 22:49:34 2010
From: report at bugs.python.org (Gerald Dalley)
Date: Wed, 16 Jun 2010 20:49:34 +0000
Subject: [issue7689] Pickling of classes with a metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <1276721374.32.0.0178077009607.issue7689@psf.upfronthosting.co.za>


Gerald Dalley <dalleyg at deshaw.com> added the comment:

Another use case: for distributed processing, it's handy to be able to pickle interactive functions and functions that are part of a script.  The user can then remotely execute a broader set of functions than can be pickled by default.  This is especially helpful for interactive exploration of data.

Pickling most types of functions is possible by serializing a function's bytecode, etc. and registering a handler with copy_reg.  Unfortunately, this handler is ignored under some conditions (e.g. copy_reg is ignored when attempting to serialize top-level functions in a script) but the copy_reg handler does get used for lambdas and inner functions.  This patch looks like it will allow FunctionType's pickle handler to be overridden in all cases.

----------
nosy: +dalleyg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7689>
_______________________________________

From report at bugs.python.org  Wed Jun 16 22:51:39 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Jun 2010 20:51:39 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1276721499.14.0.599148657397.issue9009@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's an updated version of the parsing patch, with rewritten comments, but no significant code changes.

----------
Added file: http://bugs.python.org/file17689/dtoa_parsing2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Wed Jun 16 23:08:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 16 Jun 2010 21:08:59 +0000
Subject: [issue7689] Pickling of classes with a metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <1276722539.96.0.789943824687.issue7689@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your report and patch. I?m editing the versions field: New features and bug fixes go to the active branch, py3k (future 3.2), while only security and documentation fixes are allowed to go in stable branches (2.6 and 3.1). Current trunk (2.7) is frozen, since it?s in release candidate stage; if your bug is fixed in py3k really soon, we?ll ask the release manager Benjamin Peterson if he agrees to let it into 2.7. Thanks again!

----------
keywords: +needs review
nosy: +merwok
stage:  -> patch review
versions:  -Python 2.5, Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7689>
_______________________________________

From report at bugs.python.org  Thu Jun 17 00:21:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jun 2010 22:21:07 +0000
Subject: [issue850997] mbcs encoding ignores errors
Message-ID: <1276726867.25.0.979254546243.issue850997@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch version 4:
 - encode_mbcs() uses WC_NO_BEST_FIT_CHARS flag in strict mode. Examples: ? and ? are not more replaced by g and l
 - encode_mbcs() doesn't set *repr to NULL on encode error: the caller does anyway destroy it
 - write more documentation about mbcs, especially about the error handlers and the changes in Python 3.2

----------
Added file: http://bugs.python.org/file17690/mbcs_errors-py3k-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue850997>
_______________________________________

From report at bugs.python.org  Thu Jun 17 00:23:36 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 22:23:36 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1276727016.3.0.0250302433562.issue9009@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Mark,

It is great to see you doing this.  I looked at this code on several occasions before and each time ran away scared!  I sincerely hope I will understand how it works after your rewrite.

Just a small suggestion at this point: can you give longer names to args and local variables?  The current alphabet soup is a bit confusing:

c, s, s0, s1, se, s00(!), e, nd, nd0, pnd, pnd0 ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Thu Jun 17 00:24:22 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 16 Jun 2010 22:24:22 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1276727062.42.0.379838324137.issue4953@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Could this be related to issue 8077?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jun 17 00:25:35 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 16 Jun 2010 22:25:35 +0000
Subject: [issue8077] cgi handling of POSTed files is broken
In-Reply-To: <1267839820.97.0.586792235494.issue8077@psf.upfronthosting.co.za>
Message-ID: <1276727135.92.0.855636148201.issue8077@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Could this be related to issue 4953?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8077>
_______________________________________

From report at bugs.python.org  Thu Jun 17 00:40:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 22:40:03 +0000
Subject: [issue9012] Separate compilation of time and datetime modules
In-Reply-To: <1276703214.18.0.763658156575.issue9012@psf.upfronthosting.co.za>
Message-ID: <1276728003.92.0.710882565439.issue9012@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r82034.

----------
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9012>
_______________________________________

From report at bugs.python.org  Thu Jun 17 00:46:46 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 16 Jun 2010 22:46:46 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1276728406.15.0.0867121139387.issue4953@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/issue4953>
_______________________________________

From report at bugs.python.org  Thu Jun 17 00:49:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jun 2010 22:49:33 +0000
Subject: [issue9012] Separate compilation of time and datetime modules
In-Reply-To: <1276703214.18.0.763658156575.issue9012@psf.upfronthosting.co.za>
Message-ID: <1276728573.39.0.771982636711.issue9012@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Reopen: r82034 broke Windows build

http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/802/steps/compile/logs/stdio

-------
Build started: Project: pythoncore, Configuration: Debug|Win32
Linking...
   Creating library D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\PCbuild\python32_d.lib and object D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\PCbuild\python32_d.exp
datetimemodule.obj : error LNK2019: unresolved external symbol __PyTime_DoubleToTimet referenced in function _date_local_from_time_t
timemodule.obj : error LNK2001: unresolved external symbol __PyTime_DoubleToTimet
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\PCbuild\\python32_d.dll : fatal error LNK1120: 1 unresolved externals
Build log was saved at "file://D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\PCbuild\Win32-temp-Debug\pythoncore\BuildLog.htm"
-------

----------
nosy: +haypo
resolution: accepted -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9012>
_______________________________________

From report at bugs.python.org  Thu Jun 17 01:14:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jun 2010 23:14:24 +0000
Subject: [issue9012] Separate compilation of time and datetime modules
In-Reply-To: <1276703214.18.0.763658156575.issue9012@psf.upfronthosting.co.za>
Message-ID: <1276730064.39.0.163927501143.issue9012@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Reopen: r82034 broke Windows build

Fixed by r82035.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9012>
_______________________________________

From report at bugs.python.org  Thu Jun 17 01:20:46 2010
From: report at bugs.python.org (Bill Steinmetz)
Date: Wed, 16 Jun 2010 23:20:46 +0000
Subject: [issue9015] array.array.tofile cannot write arrays of sizes > 4GB,
	even compiled for amd64
In-Reply-To: <1276730446.48.0.255465495583.issue9015@psf.upfronthosting.co.za>
Message-ID: <1276730446.48.0.255465495583.issue9015@psf.upfronthosting.co.za>


New submission from Bill Steinmetz <bill.steinmetz at gmail.com>:

Here's my Python version info:
Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32


Here's my code that won't return (Start with a file > 4GB "hugefile.bin"):

siz = (1<<32)

print "making array (%d) bytes" % siz
fin = open("hugefile.bin","rb")
a = array.array("B")
a.fromfile(fin, siz)
fin.close()

print "writing array (%d) bytes" % siz
fout = open("foo.bin","wb")
a.tofile(fout)
print "wrote 2^32 bytes with array.tofile"



I never get the third print statement :(

----------
components: Extension Modules
messages: 107964
nosy: Bill.Steinmetz
priority: normal
severity: normal
status: open
title: array.array.tofile cannot write arrays of sizes > 4GB, even compiled for amd64
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9015>
_______________________________________

From report at bugs.python.org  Thu Jun 17 01:35:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jun 2010 23:35:10 +0000
Subject: [issue850997] mbcs encoding ignores errors
Message-ID: <1276731310.19.0.0496135567646.issue850997@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited the last patch to py3k: r82037. Let see how the buildbots react :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue850997>
_______________________________________

From report at bugs.python.org  Thu Jun 17 01:53:17 2010
From: report at bugs.python.org (Bill Steinmetz)
Date: Wed, 16 Jun 2010 23:53:17 +0000
Subject: [issue9015] array.array.tofile cannot write arrays of sizes > 4GB,
	even compiled for amd64
In-Reply-To: <1276730446.48.0.255465495583.issue9015@psf.upfronthosting.co.za>
Message-ID: <1276732397.38.0.898216206717.issue9015@psf.upfronthosting.co.za>


Bill Steinmetz <bill.steinmetz at gmail.com> added the comment:

Looks like the issue is Microsoft's fwrite

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9015>
_______________________________________

From report at bugs.python.org  Thu Jun 17 02:13:11 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 00:13:11 +0000
Subject: [issue2475] Popen.poll always returns None
In-Reply-To: <1206392349.51.0.854683862843.issue2475@psf.upfronthosting.co.za>
Message-ID: <1276733591.82.0.507377272093.issue2475@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Should this be closed or is this still a problem in 2.7 (release candidate out now, final soon) or 3.1?

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2475>
_______________________________________

From report at bugs.python.org  Thu Jun 17 02:16:12 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 17 Jun 2010 00:16:12 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1276733772.23.0.55658850106.issue8857@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> FreeBSD/Qemu: ipv6 is ok, but this fails:
[...]

That failure refers to this test:

        # by specifying "http" we expect all returned sockets have
        # STREAM type
        infos = socket.getaddrinfo(HOST, "http")
        for _, socktype, _, _, _ in infos:
             self.assertEqual(socktype, socket.SOCK_STREAM)

...and means that getaddrinfo() consider UDP (socket.SOCK_DGRAM == 1) a valid transfer protocol for HTTP.
By googling around it seems this might actually be true:
http://stackoverflow.com/questions/323351/does-http-use-udp

Changing the string to "ftp" should solve the problem.
As for the IPv6 failure I added some extra code which executes the test only after verifying that binding an IPv6 socket is actually possible.

Btw, socket.has_ipv6 documentation should be more clear about the fact that having it == True doesn't necessarily mean IPv6 is actually supported.

----------
Added file: http://bugs.python.org/file17691/getaddrinfotest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Thu Jun 17 02:16:19 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 17 Jun 2010 00:16:19 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1276733779.48.0.962960722429.issue8857@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


Removed file: http://bugs.python.org/file17516/getaddrinfotest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Thu Jun 17 02:22:08 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 17 Jun 2010 00:22:08 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1276734128.15.0.91062235355.issue8857@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


Removed file: http://bugs.python.org/file17691/getaddrinfotest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Thu Jun 17 02:22:16 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 17 Jun 2010 00:22:16 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1276734136.14.0.708474128664.issue8857@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


Added file: http://bugs.python.org/file17692/getaddrinfotest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Thu Jun 17 02:32:52 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 17 Jun 2010 00:32:52 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1276734772.76.0.108336831988.issue8857@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Forgot to include socket.gaierror in the list of exceptions.
New patch in attachment.

----------
Added file: http://bugs.python.org/file17693/getaddrinfotest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Thu Jun 17 02:34:46 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 00:34:46 +0000
Subject: [issue3687] Popen() object stdout attribute reassignment behaviour
In-Reply-To: <1219766265.83.0.904411616188.issue3687@psf.upfronthosting.co.za>
Message-ID: <1276734886.97.0.121176450793.issue3687@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

While it could be argued that it is 'obvious' that changing the stdin, stdout, stderr, and pid of a processes cannot work, I agree that a small addition would be good. In 17.1.2. Popen Objects, after "The following attributes are also available", insert " (do not try to change them)" before ':'.

Actually, it seems to me that the attributes should actually be read-only (in 3.2) if possible (via custom Popen.__setattr__), in which case the only doc change needed (for 3.2) would be insertion of 'read-only' before 'attributes'.

Georg, if you know the id of the subprocess maintainer (if there is one now), could you add him to the nosy list for an opinion or comment?

----------
nosy: +tjreedy
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3687>
_______________________________________

From report at bugs.python.org  Thu Jun 17 02:44:43 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 00:44:43 +0000
Subject: [issue3765] [patch] allow mmap take file offset as argument
In-Reply-To: <1220475316.49.0.690011061298.issue3765@psf.upfronthosting.co.za>
Message-ID: <1276735483.25.0.983803392883.issue3765@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This request is slightly confusing. The first sentence implies that you want offset to be a requirement (as opposed to being an option). That would not be acceptable. Later it seems that you want it added as an option (as opposed to not available). That seems sensible, and indeed, in 3.1, offset *is* an option (with a default of 0). So I am closing this as out-of-date (because fixed).

For future submissions, upload patches to the tracker as a file attached to the issue. The url you gave now gives 404 not found error.

----------
nosy: +tjreedy
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3765>
_______________________________________

From report at bugs.python.org  Thu Jun 17 02:55:33 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 00:55:33 +0000
Subject: [issue3874] documentation bug: HTMLParser needs to document
	unknown_decl
In-Reply-To: <1221515609.61.0.396859142368.issue3874@psf.upfronthosting.co.za>
Message-ID: <1276736133.13.0.311860455742.issue3874@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Documentation issues should be component: documentation rather than library. When submitting one, please at least indicate the module or class concerned. I have never heard of 'unknown_decl' function.

Preferably, indicate the specific section you want modified, by version, number and name. Best is to submit a suggested text to be inserted.  You may know better than most issue reviewers what should be said. Someone else will add markup and possibly edit.

If you respond, this will be reopened. Please indicate whether this issue applies to 3.x and add 3.1 and 3.2 if it does.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, tjreedy
status: open -> pending
versions: +Python 2.6, Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3874>
_______________________________________

From report at bugs.python.org  Thu Jun 17 02:58:10 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 00:58:10 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1276736290.74.0.274490865031.issue3709@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Does this issue apply to 3.1/2?

----------
nosy: +tjreedy
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Thu Jun 17 03:03:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Jun 2010 01:03:41 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1276736621.1.0.347473740716.issue9011@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Thu Jun 17 03:04:18 2010
From: report at bugs.python.org (Terrence Cole)
Date: Thu, 17 Jun 2010 01:04:18 +0000
Subject: [issue8814] functools.WRAPPER_ASSIGNMENTS should include
	__annotations__
In-Reply-To: <1274736059.05.0.616257463555.issue8814@psf.upfronthosting.co.za>
Message-ID: <1276736658.87.0.898178132063.issue8814@psf.upfronthosting.co.za>


Terrence Cole <terrence at zettabytestorage.com> added the comment:

Alright, I've added several tests.  I also modified update_wrapper to not copy missing attributes (like __annotations__ on builtin methods) -- see issue 1576241.

(I also finally see what you mean with removing 3.3 from the versions list.  Sorry I didn't grok that before.)

----------
Added file: http://bugs.python.org/file17694/functools-wrapper-assign-annotations.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8814>
_______________________________________

From report at bugs.python.org  Thu Jun 17 03:09:40 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 01:09:40 +0000
Subject: [issue3841] IDLE: quirky behavior when displaying strings longer than
	4093 characters
In-Reply-To: <1221158494.97.0.26052991619.issue3841@psf.upfronthosting.co.za>
Message-ID: <1276736980.32.0.274193436908.issue3841@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

3.1, WinXP, works fine.
I am inclined to close this as idiosyncratic to a particular 2.5 installation, which is beyond patching now anyway.

OP, respond if you have a problem with new 2.7, and include version splash line like "Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on win32"

----------
nosy: +tjreedy
resolution:  -> works for me
status: open -> pending
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3841>
_______________________________________

From report at bugs.python.org  Thu Jun 17 03:10:15 2010
From: report at bugs.python.org (Legoll Vincent)
Date: Thu, 17 Jun 2010 01:10:15 +0000
Subject: [issue3687] Popen() object stdout attribute reassignment behaviour
In-Reply-To: <1276734886.97.0.121176450793.issue3687@psf.upfronthosting.co.za>
Message-ID: <AANLkTil7-cPluJMjYsnS_yDMMj52i53yWY7SVHINiA0o@mail.gmail.com>


Legoll Vincent <vincent.legoll at gmail.com> added the comment:

On Thu, Jun 17, 2010 at 2:34 AM, Terry J. Reedy <report at bugs.python.org> wrote:
> While it could be argued that it is 'obvious'

What is obvious for someone maybe is not for others, if I tried to modify it,
that was on the (false) assumption that it will do what I wanted (whatever
that is)...

Adding more precision to documentation or making the interface fool proof
will make life of dumb devs like me easier by not having to guess or try.

Thanks for taking care of this.

----------
nosy: +vlegoll

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3687>
_______________________________________

From report at bugs.python.org  Thu Jun 17 03:11:57 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 01:11:57 +0000
Subject: [issue3290] python-config --cflags includes irrelevant flags
In-Reply-To: <1215284947.23.0.370691849564.issue3290@psf.upfronthosting.co.za>
Message-ID: <1276737117.89.0.349174448631.issue3290@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Is this still an issue for current trunks?

----------
nosy: +tjreedy
versions: +Python 2.7, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3290>
_______________________________________

From report at bugs.python.org  Thu Jun 17 03:13:57 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 01:13:57 +0000
Subject: [issue1593035] readline problem on ia64-unknown-linux-gnu
Message-ID: <1276737237.33.0.318236335817.issue1593035@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In the absence of a claim otherwise, I am assuming that this is now either fixed or out-of-date

----------
nosy: +tjreedy
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1593035>
_______________________________________

From report at bugs.python.org  Thu Jun 17 03:14:43 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 01:14:43 +0000
Subject: [issue3990] The Linux2 platform definition is incorrect for alpha,
	hppa, mips, sparc
In-Reply-To: <1222622636.83.0.91904211749.issue3990@psf.upfronthosting.co.za>
Message-ID: <1276737283.77.0.975628561051.issue3990@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.4, Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3990>
_______________________________________

From report at bugs.python.org  Thu Jun 17 03:18:06 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 01:18:06 +0000
Subject: [issue3862] test_array fails on FreeBSD7 amd64
In-Reply-To: <1221355819.02.0.121896067033.issue3862@psf.upfronthosting.co.za>
Message-ID: <1276737486.71.0.851909058338.issue3862@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Was the fix forward ported or is this an issue for 3.1/2?

----------
nosy: +tjreedy
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3862>
_______________________________________

From report at bugs.python.org  Thu Jun 17 03:18:41 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 01:18:41 +0000
Subject: [issue1633863] AIX: configure ignores $CC
Message-ID: <1276737521.2.0.331866581768.issue1633863@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1633863>
_______________________________________

From report at bugs.python.org  Thu Jun 17 03:21:24 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 01:21:24 +0000
Subject: [issue4099] dir on a compiled re does not show pattern as a part of
	the list
In-Reply-To: <1223642241.74.0.837602325601.issue4099@psf.upfronthosting.co.za>
Message-ID: <1276737684.55.0.0828335095007.issue4099@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4099>
_______________________________________

From report at bugs.python.org  Thu Jun 17 03:26:18 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 01:26:18 +0000
Subject: [issue1107887] Speed up function calls/can add more introspection info
Message-ID: <1276737978.07.0.0364180443612.issue1107887@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This appears to be a feature request that could now go into 3.2 at the earliest, or even 3.3 if it were to violate the core change moratorium. But I do not know if it even applies to the 3.x series.

----------
nosy: +tjreedy
type:  -> feature request
versions: +Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1107887>
_______________________________________

From report at bugs.python.org  Thu Jun 17 03:35:00 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 01:35:00 +0000
Subject: [issue4202] Multiple interpreters and readline module hook functions.
In-Reply-To: <1224903164.25.0.50876142409.issue4202@psf.upfronthosting.co.za>
Message-ID: <1276738500.5.0.0825409590215.issue4202@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The be an issue, tests with currents interpreters are needed. You may be right, but it may be that no one ever uses readline with subinterpreters.

----------
nosy: +tjreedy
status: open -> pending
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4202>
_______________________________________

From report at bugs.python.org  Thu Jun 17 03:46:35 2010
From: report at bugs.python.org (Collin Winter)
Date: Thu, 17 Jun 2010 01:46:35 +0000
Subject: [issue1107887] Speed up function calls/can add more introspection info
Message-ID: <1276739195.55.0.751112713063.issue1107887@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

I tried making this work early last year as part of Unladen Swallow, and even though I got it working and it does speed up certain builtin calls, it didn't move overall application performance at all. I believe this was due to cache effects, branch mispredicts or something else. Based on that experience, I don't believe this is really worth pursuing on its own.

That said, something like this is included in Unladen Swallow, which uses it to make direct calls to certain C functions. I'm going to close this accordingly.

----------
resolution:  -> later
status: open -> closed
type: feature request -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1107887>
_______________________________________

From report at bugs.python.org  Thu Jun 17 03:48:58 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 01:48:58 +0000
Subject: [issue4253] Maildir dumpmessage on
In-Reply-To: <1225700324.91.0.938996340802.issue4253@psf.upfronthosting.co.za>
Message-ID: <1276739338.05.0.716706252548.issue4253@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This report is a bit hard to interpret. In 3.1, the mailbox module has a Maildir class with a private _dump_message method. Since the method is undocumented and not part of the public API, there cannot be a conflict between the doc and behavior ;-).

So you need to show with minimal but complete code, and now, with 2.7 or 3.1, that there is a bug in a public method caused by its use of the private method.

I do not see what the code line has to do with the report.

----------
nosy: +tjreedy
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4253>
_______________________________________

From report at bugs.python.org  Thu Jun 17 03:53:01 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 01:53:01 +0000
Subject: [issue4280] Version Checker
In-Reply-To: <1226087702.6.0.0754542760086.issue4280@psf.upfronthosting.co.za>
Message-ID: <1276739581.96.0.583318284441.issue4280@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +Demos and Tools -Tests
versions: +Python 3.2 -Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4280>
_______________________________________

From report at bugs.python.org  Thu Jun 17 04:01:07 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 02:01:07 +0000
Subject: [issue4452] Incorrect docstring of os.setpgrp
In-Reply-To: <1227882211.37.0.737329471777.issue4452@psf.upfronthosting.co.za>
Message-ID: <1276740067.28.0.872477801371.issue4452@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

os.setpgrp is unix only, I am windows only ;-(.
However, the 3.1 manual says "Call the system call setpgrp() or setpgrp(0, 0)() depending on which version is implemented (if any). "

Given the name of the function and the above, I suspect the OP is correct. The change is small enough that I might not bother with 2.6 and 3.1.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, tjreedy
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.4, Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4452>
_______________________________________

From report at bugs.python.org  Thu Jun 17 04:05:06 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 02:05:06 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1276740306.32.0.739649214249.issue4370@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Martin said: I also wonder whether it is really necessary to complicate the code just so that gcc 2.95 stops producing some warnings. So I propose to close this as "won't fix".

Is 2.95 still used much? If not, the above sounds good.

----------
nosy: +tjreedy
versions: +Python 3.2 -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Thu Jun 17 04:06:48 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 02:06:48 +0000
Subject: [issue4502] Allowing get_pre_input_hook from Readline
In-Reply-To: <1228268977.11.0.20813106029.issue4502@psf.upfronthosting.co.za>
Message-ID: <1276740408.42.0.73311147029.issue4502@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4502>
_______________________________________

From report at bugs.python.org  Thu Jun 17 04:07:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Jun 2010 02:07:23 +0000
Subject: [issue8720] undo findsource regression/change
In-Reply-To: <1273877995.17.0.0354087541128.issue8720@psf.upfronthosting.co.za>
Message-ID: <1276740443.74.0.0104313060923.issue8720@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've applied the patch to trunk in r82039, to py3k in r82041, and 3.1 in r82042.

Holger, I'm not really familiar with the linecache module and its uses, so I'm not sure what your proposal is aimed at.  Perhaps you could flesh out your proposal in a new ticket?

----------
assignee:  -> r.david.murray
resolution:  -> fixed
stage: patch review -> committed/rejected
status: pending -> closed
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8720>
_______________________________________

From report at bugs.python.org  Thu Jun 17 04:08:01 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 02:08:01 +0000
Subject: [issue2102] New style vs. old style classes __ror__() operator
	overloading
In-Reply-To: <1202914275.65.0.0408321545289.issue2102@psf.upfronthosting.co.za>
Message-ID: <1276740481.11.0.916633644168.issue2102@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2102>
_______________________________________

From report at bugs.python.org  Thu Jun 17 04:24:12 2010
From: report at bugs.python.org (Rick Harris)
Date: Thu, 17 Jun 2010 02:24:12 +0000
Subject: [issue1675951] [gzip] Performance for small reads and fix seek problem
Message-ID: <1276741452.08.0.381745015025.issue1675951@psf.upfronthosting.co.za>


Rick Harris <rconradharris at gmail.com> added the comment:

Are compatibility concerns the main reason this patch has yet to be applied?

If so, could we allay those fears by keeping the default seek-y behavior and only introducing the new seek-less style when a 'noseek' flag is passed?

----------
nosy: +rharris

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675951>
_______________________________________

From report at bugs.python.org  Thu Jun 17 04:27:20 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 02:27:20 +0000
Subject: [issue1215] Python hang when catching a segfault
In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za>
Message-ID: <1276741640.58.0.992116456313.issue1215@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

>From the comments, it seems like this should be changed to a doc issue.

Given that I do not know a 'synchronous' from an 'asynchronous' signal, I would want an expanded list if I were using this module.

Strengthening 'little sense' to 'do not do it' makes sense, at least for 2.7 and 3.2.

----------
nosy: +tjreedy
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1215>
_______________________________________

From report at bugs.python.org  Thu Jun 17 04:42:34 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 17 Jun 2010 02:42:34 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1276742554.55.0.43040911469.issue3709@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Yes, it is applicable to 3.1 and 3.2 as well. This is definitely a good to have performance improvement.

----------
nosy: +orsenthil
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Thu Jun 17 06:05:36 2010
From: report at bugs.python.org (Jon Seger)
Date: Thu, 17 Jun 2010 04:05:36 +0000
Subject: [issue9016] IDLE won't launch (Win XP)
In-Reply-To: <1276747536.03.0.234603288057.issue9016@psf.upfronthosting.co.za>
Message-ID: <1276747536.03.0.234603288057.issue9016@psf.upfronthosting.co.za>


New submission from Jon Seger <seger at biology.utah.edu>:

I upgraded from 2.5.2 to 2.6.5 on a WinXP system.  Console interpreter worked fine, but IDLE would not launch (quit without displaying anything on screen).  Same with 2.6.4.  Finally tried 2.5.4, which works as expected (like the old 2.5.2).

----------
components: IDLE
messages: 107990
nosy: jonseger
priority: normal
severity: normal
status: open
title: IDLE won't launch (Win XP)
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9016>
_______________________________________

From report at bugs.python.org  Thu Jun 17 08:22:28 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 17 Jun 2010 06:22:28 +0000
Subject: [issue9016] IDLE won't launch (Win XP)
In-Reply-To: <1276747536.03.0.234603288057.issue9016@psf.upfronthosting.co.za>
Message-ID: <1276755748.32.0.869782090558.issue9016@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please run "python.exe Lib/idlelib/idle.py" in a console window, and report any errors that you get.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9016>
_______________________________________

From report at bugs.python.org  Thu Jun 17 08:27:39 2010
From: report at bugs.python.org (Tal Einat)
Date: Thu, 17 Jun 2010 06:27:39 +0000
Subject: [issue9016] IDLE won't launch (Win XP)
In-Reply-To: <1276747536.03.0.234603288057.issue9016@psf.upfronthosting.co.za>
Message-ID: <1276756059.31.0.494063940281.issue9016@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

Also, try renaming/moving the directory C:\Documents and Settings\<username>\.idlerc, and then try to start IDLE.

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9016>
_______________________________________

From report at bugs.python.org  Thu Jun 17 09:38:51 2010
From: report at bugs.python.org (Tal Einat)
Date: Thu, 17 Jun 2010 07:38:51 +0000
Subject: [issue459007] Document sys.path on Windows
Message-ID: <1276760331.4.0.863818606847.issue459007@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

Wow, this has been on hold for ages! I know I could have used this information in the past, and several people have asked me about this.

Perhaps there should be a place in the documentations which explains how sys.path is populated, with detailed explanations for different platforms?

With some guidance as per the right place in the docs for this, I'll gladly work on this. Note that I'm not an expert on this issue, I just plan to gather information form several places and write up a single nice documentation page.

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue459007>
_______________________________________

From report at bugs.python.org  Thu Jun 17 10:10:30 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 17 Jun 2010 08:10:30 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1276762230.04.0.601669597198.issue8857@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

> Btw, socket.has_ipv6 documentation should be more clear about the fact
> that having it == True doesn't necessarily mean IPv6 is actually
> supported.

Strange indeed. socket.has_ipv6 checks whether ENABLE_IPV6 was defined at
compile time. But why is that an attribute of a socket object? It can be
checked in sysconfig.



Unfortunately, the socktype test still fails on FreeBSD/Qemu:

======================================================================
FAIL: testGetaddrinfo (__main__.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_socket.py", line 591, in testGetaddrinfo
    self.assertEqual(socktype, socket.SOCK_STREAM)
AssertionError: 2 != 1

----------------------------------------------------------------------
Ran 101 tests in 11.504s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_socket.py", line 1463, in <module>
    test_main()
  File "Lib/test/test_socket.py", line 1459, in test_main
    test_support.run_unittest(*tests)
  File "/usr/home/stefan/svn/trunk/Lib/test/test_support.py", line 1055, in run_unittest
    _run_suite(suite)
  File "/usr/home/stefan/svn/trunk/Lib/test/test_support.py", line 1038, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_socket.py", line 591, in testGetaddrinfo
    self.assertEqual(socktype, socket.SOCK_STREAM)
AssertionError: 2 != 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Thu Jun 17 10:25:35 2010
From: report at bugs.python.org (Florian Festi)
Date: Thu, 17 Jun 2010 08:25:35 +0000
Subject: [issue1675951] [gzip] Performance for small reads and fix seek problem
Message-ID: <1276763135.05.0.863898419816.issue1675951@psf.upfronthosting.co.za>


Florian Festi <florianfesti at users.sourceforge.net> added the comment:

There are no compatibility concerns I am aware of. The new implementation does no longer need a seek()able file. Of course an implemented seek() method won't hurt anyone. The additional tests are only there to point out the problems of the old implementation.

So there is no flag needed to maintain compatibility. The patch just has to be reviewed and then to be applied. If there are any concerns or questions I'll be glad to assist.

Florian

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675951>
_______________________________________

From report at bugs.python.org  Thu Jun 17 10:43:50 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 17 Jun 2010 08:43:50 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1276764230.95.0.804423178214.issue8857@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

> But why is that an attribute of a socket object?

Please pretend I did not write this. ;)


Anyway, getaddrinfo() on FreeBSD/Qemu gives this:

 >>> socket.getaddrinfo('localhost', 21)
[(2, 2, 17, '', ('127.0.0.1', 21)), (2, 1, 6, '', ('127.0.0.1', 21)), (2, 5, 132, '', ('127.0.0.1', 21)), (28, 2, 17, '', ('::1', 21, 0, 0)), (28, 1, 6, '', ('::1', 21, 0, 0)), (28, 5, 132, '', ('::1', 21, 0, 0))]
>>> socket.getaddrinfo('localhost', 22)
[(2, 2, 17, '', ('127.0.0.1', 22)), (2, 1, 6, '', ('127.0.0.1', 22)), (2, 5, 132, '', ('127.0.0.1', 22)), (28, 2, 17, '', ('::1', 22, 0, 0)), (28, 1, 6, '', ('::1', 22, 0, 0)), (28, 5, 132, '', ('::1', 22, 0, 0))]
>>> socket.getaddrinfo('localhost', 80)
[(2, 2, 17, '', ('127.0.0.1', 80)), (2, 1, 6, '', ('127.0.0.1', 80)), (2, 5, 132, '', ('127.0.0.1', 80)), (28, 2, 17, '', ('::1', 80, 0, 0)), (28, 1, 6, '', ('::1', 80, 0, 0)), (28, 5, 132, '', ('::1', 80, 0, 0))]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Thu Jun 17 10:49:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jun 2010 08:49:09 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1276764549.25.0.623728596408.issue9011@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/issue9011>
_______________________________________

From report at bugs.python.org  Thu Jun 17 10:54:17 2010
From: report at bugs.python.org (Nils Philippsen)
Date: Thu, 17 Jun 2010 08:54:17 +0000
Subject: [issue1675951] [gzip] Performance for small reads and fix seek problem
Message-ID: <1276764857.28.0.434785825466.issue1675951@psf.upfronthosting.co.za>


Changes by Nils Philippsen <nils at redhat.com>:


----------
nosy: +nils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675951>
_______________________________________

From report at bugs.python.org  Thu Jun 17 11:09:13 2010
From: report at bugs.python.org (Ruben Bakker)
Date: Thu, 17 Jun 2010 09:09:13 +0000
Subject: [issue9010] Infinite loop in imaplib.IMAP4_SSL when used with Gmail
In-Reply-To: <1276704765.38.0.582722428279.issue9010@psf.upfronthosting.co.za>
Message-ID: <AANLkTimT56hnZI7sW34FqAAyksU733otjbnRyRfY7yd8@mail.gmail.com>


Ruben Bakker <ruben.bakker1 at gmail.com> added the comment:

I installed Python 2.7RC1 on Mac OS X 10.6.3 and tried my script and it
worked for me. Imaplib throws the right exception instead of looping
forever:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "imapmail/explore/test2.py", line 30, in f
    server.select("INBOX")
  File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/imaplib.py",
line 642, in select
    typ, dat = self._simple_command(name, mailbox)
  File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/imaplib.py",
line 1060, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/imaplib.py",
line 890, in _command_complete
    raise self.abort('command: %s => %s' % (name, val))
imaplib.abort: command: SELECT => socket error: EOF
>>>

On Wed, Jun 16, 2010 at 6:12 PM, Shashwat Anand <report at bugs.python.org>wrote:

>
> Shashwat Anand <anand.shashwat at gmail.com> added the comment:
>
> "import imaplib
>
> HOST="imap.gmail.com"
> PORT=993
> USERNAME="username at gmail.com"
> PASSWORD="password"
>
> server = imaplib.IMAP4_SSL(host=HOST, port=PORT)
> server.login(USERNAME, PASSWORD)
>
> def f():
>        print server.select("INBOX")
>        print server.uid("FETCH", "1:*", "(UID FLAGS BODY.PEEK[HEADER.FIELDS
> (Subject)])")
>
> Call the f() function and then wait about about an hour. Call f() again and
> server.select() will not return but take all CPU."
>
> Tried to reproduce this on Python 2.7RC1. Seemed Ok to me. Took some 3
> seconds to call f() not only once, but twice, thrice.
>
> ----------
> nosy: +l0nwlf
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue9010>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file17695/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9010>
_______________________________________
-------------- next part --------------
I installed Python 2.7RC1 on Mac OS X 10.6.3 and tried my script and it worked for me. Imaplib throws the right exception instead of looping forever:<div><br></div><div><div>&gt;&gt;&gt; f()</div><div>Traceback (most recent call last):</div>

<div>????File &quot;&lt;stdin&gt;&quot;, line 1, in &lt;module&gt;</div><div>????File &quot;imapmail/explore/test2.py&quot;, line 30, in f</div><div>???? ??server.select(&quot;INBOX&quot;)</div><div>????File &quot;/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/imaplib.py&quot;, line 642, in select</div>

<div>???? ??typ, dat = self._simple_command(name, mailbox)</div><div>????File &quot;/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/imaplib.py&quot;, line 1060, in _simple_command</div><div>???? ??return self._command_complete(name, self._command(name, *args))</div>

<div>????File &quot;/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/imaplib.py&quot;, line 890, in _command_complete</div><div>???? ??raise self.abort(&#39;command: %s =&gt; %s&#39; % (name, val))</div><div>imaplib.abort: command: SELECT =&gt; socket error: EOF</div>

<div>&gt;&gt;&gt;??</div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Wed, Jun 16, 2010 at 6:12 PM, Shashwat Anand <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>
Shashwat Anand &lt;<a href="mailto:anand.shashwat at gmail.com">anand.shashwat at gmail.com</a>&gt; added the comment:<br>
<div class="im"><br>
&quot;import imaplib<br>
<br>
HOST=&quot;<a href="http://imap.gmail.com" target="_blank">imap.gmail.com</a>&quot;<br>
PORT=993<br>
USERNAME=&quot;<a href="mailto:username at gmail.com">username at gmail.com</a>&quot;<br>
PASSWORD=&quot;password&quot;<br>
<br>
server = imaplib.IMAP4_SSL(host=HOST, port=PORT)<br>
server.login(USERNAME, PASSWORD)<br>
<br>
def f():<br>
 ?? ?? ?? ??print server.select(&quot;INBOX&quot;)<br>
 ?? ?? ?? ??print server.uid(&quot;FETCH&quot;, &quot;1:*&quot;, &quot;(UID FLAGS BODY.PEEK[HEADER.FIELDS (Subject)])&quot;)<br>
<br>
Call the f() function and then wait about about an hour. Call f() again and server.select() will not return but take all CPU.&quot;<br>
<br>
</div>Tried to reproduce this on Python 2.7RC1. Seemed Ok to me. Took some 3 seconds to call f() not only once, but twice, thrice.<br>
<br>
----------<br>
nosy: +l0nwlf<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/issue9010" target="_blank">http://bugs.python.org/issue9010</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Ruben Bakker<br>uncomplex gmbh<br><a href="http://mailplaneapp.com">http://mailplaneapp.com</a><br>
</div></div>

From report at bugs.python.org  Thu Jun 17 11:21:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jun 2010 09:21:05 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1276766465.13.0.0737700482017.issue9011@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Confirmed in trunk and py3k, both of which raise ValueError on the second compile:

Python 2.7rc1+ (trunk:82042, Jun 17 2010, 09:52:12) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import parser
>>> st = parser.expr("-3")
>>> st.compile()
<code object <module> at 0x450448, file "<syntax-tree>", line 1>
>>> st.compile()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not convert string to float: --3

This looks nasty; unless there's some rule that says that you're not supposed to hang on to AST objects after compiling them.  (Is there?)

Benjamin, would it be worth just getting rid of this optimization for 2.7, and trying to reinstate a correct version for 2.7.1?

[Removing 2.5 from the versions list since there's nothing we can do about it there (2.5 is only getting security fixes at this point).]

See also issue 1441486.

----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Thu Jun 17 11:29:21 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jun 2010 09:29:21 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1276766961.83.0.521588474337.issue9011@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Thu Jun 17 12:07:21 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 17 Jun 2010 10:07:21 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1276769241.84.0.705621537031.issue7384@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Committed a conservative version implementing part 1) in r82017 (2.6) and
r82019 (3.1). Part 2) can be enabled by uncommenting a couple of lines in
setup.py.

The buildbots look good, but I'm setting this to 'pending' in case
someone would like part 2) of the fix in the releases.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Thu Jun 17 12:49:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Jun 2010 10:49:13 +0000
Subject: [issue1675951] [gzip] Performance for small reads and fix seek problem
Message-ID: <1276771753.81.0.668105032361.issue1675951@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch could only be applied to 3.2 (2.7 is frozen now). But the gzip code has changed quite a bit and I would advocate creating a new patch if you are interested.
Do notice that performance should also be much better in 3.2, and it is possible to wrap a gzip object in a io.BufferedReader object so as to reach even better performance.

----------
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675951>
_______________________________________

From report at bugs.python.org  Thu Jun 17 13:16:01 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jun 2010 11:16:01 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1276773361.24.0.114306613225.issue9011@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

N.B.  That if block isn't pure optimization:  removing it gives a minor change in behaviour:

Currently (Python 2.7, on a 64-bit machine):

>>> -9223372036854775808
-9223372036854775808

And with the optimization removed:

>>> -9223372036854775808
-9223372036854775808L

I actually consider the second behaviour more correct than the first, since it follows clearly from the language rules (numeric literals have no sign, so the above *should* be interpreted as the unary minus operator applied to a literal, and that literal really is a PyLong).  But obviously the contributors to issue 1441486 either disagree, or didn't want to introduce a regression from 2.4.

I still consider that removing that if block is the right thing to do for 2.7.  The change in behaviour really shouldn't affect any reasonable code---anywhere that an int is acceptable, a long should be too.



Neil, any comments?

----------
nosy: +nascheme
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Thu Jun 17 13:36:11 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jun 2010 11:36:11 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1276774571.2.0.405531177617.issue9011@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Results from Jython:

newton:jython2.5.1 dickinsm$ ./jython
Jython 2.5.1 (Release_2_5_1:6813, Sep 26 2009, 13:47:54) 
[Java HotSpot(TM) 64-Bit Server VM (Apple Inc.)] on java1.6.0_20
Type "help", "copyright", "credits" or "license" for more information.
>>> -2147483648
-2147483648L

On the other hand, IronPython appears to detect this special case and produces an int instead of a long.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Thu Jun 17 13:55:44 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 17 Jun 2010 11:55:44 +0000
Subject: [issue8937] SimpleHTTPServer should contain usage example
In-Reply-To: <1275975534.8.0.563527396515.issue8937@psf.upfronthosting.co.za>
Message-ID: <1276775744.49.0.973194166053.issue8937@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Thank you. The wording can surely be improved, but it is much better than nothing. 

I'd reword the first para further:

> The :func:`test` function in the :mod:`SimpleHTTPServer` module is an example of using :class:`SimpleHTTPRequestHandler` with :class:`BaseHTTPServer` class.

BTW, it is still bad, because:
1. I'd assume that test function is described in documentation and not located in module source
2. users usually don't know where to look for the module source - doc should be self-sufficient
3. SimpleHTTPServer.test() is a proxy call for BaseHTTPServer.test()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8937>
_______________________________________

From report at bugs.python.org  Thu Jun 17 14:22:51 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 17 Jun 2010 12:22:51 +0000
Subject: [issue8937] SimpleHTTPServer should contain usage example
In-Reply-To: <1275975534.8.0.563527396515.issue8937@psf.upfronthosting.co.za>
Message-ID: <20100617120956.GA19305@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Yes, I felt the same way and that is the reason for providing extra
example snippets in the same Documentation. I hope you checked that
one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8937>
_______________________________________

From report at bugs.python.org  Thu Jun 17 14:29:23 2010
From: report at bugs.python.org (Adam Groszer)
Date: Thu, 17 Jun 2010 12:29:23 +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: <1276777763.41.0.704098120459.issue6884@psf.upfronthosting.co.za>


Adam Groszer <agroszer at gmail.com> added the comment:

This seems to be a major flaw, noone caring about it?

----------
components: +Distutils
nosy: +Adam.Groszer
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Thu Jun 17 14:35:19 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 17 Jun 2010 12:35:19 +0000
Subject: [issue9008] CGIHTTPServer support for arbitrary CGI scripts
In-Reply-To: <1276696712.34.0.308813921281.issue9008@psf.upfronthosting.co.za>
Message-ID: <AANLkTil77fEqps_Y64ECNk7qn1Tvyn6yhmHxDAD_zkD8@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

>> Conflict resolution takes a lot of time
>> and I can't afford maintaining a separate copy of Python checkout for
>> every patch
>
> Then try various hg features such as named branches, or bookmarks, or mq, or pbranch, etc.
> (or any SVN-facing tool you would like, including git-svn, bzr-svn, etc.)

pbranch is the next in my list, still do not have time to dig all these tools.
For now I have these unsolved workflow problems:
1. patches are not tied to specific bug ticket (can only be manually uploaded)
2. I would like to receive feedback on patches inline (like in Mercurial list)
3. I would like to see all the code related to patch (source, tests,
docs) in one place
4. Edit, preview and update docs patches online
5. Download patched source and test in one step, execute in the other

>> To be a maintainer I need:
> [snip]
>
> Most people in most open source projects seem perfectly content without such an artillery of sophisticated tools/gadgets.

You account only people who found they way to be able to contribute.
Most people didn't. If you can calculate an average indicator of
active Python contributors, I will say that it can be improved by 50%
only by means of well aligned toolset.

> While the workflow can always be improved, it is not obvious to me that your requirements are in any way reasonable, or even serious ("serious" as in "this is the only reasonable way one can work efficiently on Python" -- plenty of people, almost all of them unpaid volunteers, seem to disagree).

I never said "this is the only reasonable way one can work efficiently
on Python". I said that "there is no  reasonable way one can work
efficiently on Python and I am trying to find one". Feel the
difference.

> By the way, the first thing needed to qualify as a maintainer would be to *prove* that you are up to the task. Not to have a bunch of nifty tools. In other words, you can't just come and say "hey, I'd like to be a maintainer" and expect this request to be granted automatically.

Ok. Let me try to express it in English once more:
search: To be a maintainer I need:
replace: To be willing to become a maintainer I need:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9008>
_______________________________________

From report at bugs.python.org  Thu Jun 17 14:40:19 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jun 2010 12:40:19 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1276778419.67.0.700224218468.issue9011@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in r82043 (py3k) and r82044 (release31-maint), simply by removing the relevant 'if' block.

For 2.x, Antoine (on IRC) pointed out that there might well be third party code that depends on -0x80000000 being an int rather than a long (32-bit machine), so changing that behaviour could cause breakage.

Can anyone propose a fix that doesn't change behaviour?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Thu Jun 17 14:40:27 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jun 2010 12:40:27 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1276778427.74.0.750715292869.issue9011@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Thu Jun 17 14:42:13 2010
From: report at bugs.python.org (harobed)
Date: Thu, 17 Jun 2010 12:42:13 +0000
Subject: [issue9017] What do you think about an Option Flags to enable/disable
	some chunk of doctest file ?
In-Reply-To: <1276778533.38.0.325280903618.issue9017@psf.upfronthosting.co.za>
Message-ID: <1276778533.38.0.325280903618.issue9017@psf.upfronthosting.co.za>


New submission from harobed <stephane at harobed.org>:

Hi,

in some doctest, I need to stop doctest from a position because the following test is a draft, not implemented.

I dream something like this :

   >>> test_a()
   True

   >>> test_b()
   False

   #doctest: +DISABLE

   >>> test_c()
   True

   >>> test_d()
   False

   #doctest: +ENABLE

   >>> test_e()
   True

   >>> test_f()
   False

Here, test_c and test_d aren't executed.

What do you think about this idea ? If it is a good idea, I can implement it.

Thanks for your comments,
Stephane

----------
components: Tests
messages: 108008
nosy: harobed
priority: normal
severity: normal
status: open
title: What do you think about an Option Flags to enable/disable some chunk of doctest file ?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9017>
_______________________________________

From report at bugs.python.org  Thu Jun 17 14:44:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Jun 2010 12:44:24 +0000
Subject: [issue9008] CGIHTTPServer support for arbitrary CGI scripts
In-Reply-To: <AANLkTil77fEqps_Y64ECNk7qn1Tvyn6yhmHxDAD_zkD8@mail.gmail.com>
Message-ID: <1276778660.3158.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> pbranch is the next in my list, still do not have time to dig all these tools.
> For now I have these unsolved workflow problems:
> [...]

That's a lot of things which others do not perceive as important or even
desireable. Chances are you are going to have to implement them yourself
if you really want them. In any case, just complaining won't change
anything.

> Ok. Let me try to express it in English once more:
> search: To be a maintainer I need:
> replace: To be willing to become a maintainer I need:

Nobody proposed you to become a maintainer, so this is still besides the
point. First contribute significantly, and then we'll see.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9008>
_______________________________________

From report at bugs.python.org  Thu Jun 17 15:03:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Jun 2010 13:03:58 +0000
Subject: [issue9010] Infinite loop in imaplib.IMAP4_SSL when used with Gmail
In-Reply-To: <1276701085.45.0.35769519286.issue9010@psf.upfronthosting.co.za>
Message-ID: <1276779838.91.0.688092019341.issue9010@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, this is out of date, then.  Nosy people, sorry for the noise.

----------
resolution:  -> out of date
stage: unit test needed -> committed/rejected
status: open -> closed
superseder:  -> IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9010>
_______________________________________

From report at bugs.python.org  Thu Jun 17 15:04:14 2010
From: report at bugs.python.org (Alex Samuel)
Date: Thu, 17 Jun 2010 13:04:14 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276778419.67.0.700224218468.issue9011@psf.upfronthosting.co.za>
Message-ID: <4C1A1D4A.4090200@alexsamuel.net>


Alex Samuel <alex at alexsamuel.net> added the comment:

How about saving the original value of STR(pnum) and restoring it after 
calling ast_for_atom()?

This is not thread-safe, but I don't understand Python's threading model 
well enough to know whether the GIL is held in this function.

On 6/17/2010 8:40 AM, Mark Dickinson wrote:
>
> Mark Dickinson<dickinsm at gmail.com>  added the comment:
>
> Fixed in r82043 (py3k) and r82044 (release31-maint), simply by removing the relevant 'if' block.
>
> For 2.x, Antoine (on IRC) pointed out that there might well be third party code that depends on -0x80000000 being an int rather than a long (32-bit machine), so changing that behaviour could cause breakage.
>
> Can anyone propose a fix that doesn't change behaviour?
>
> ----------
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue9011>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Thu Jun 17 15:22:49 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 17 Jun 2010 13:22:49 +0000
Subject: [issue9008] CGIHTTPServer support for arbitrary CGI scripts
In-Reply-To: <1276778660.3158.7.camel@localhost.localdomain>
Message-ID: <AANLkTikIsN57ATkpzobp3hX-NpmR5-Wpy8dilSxb7d4b@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

> That's a lot of things which others do not perceive as important or even
> desireable. Chances are you are going to have to implement them yourself
> if you really want them. In any case, just complaining won't change
> anything.

I am just trying to answer why I can't contribute patches myself. Hope
the idea to put workflow first after getting enough experience over
past year was clear. I work on this workflow alone. If smb. would also
feel that is it a more important problem than immediate patch - I'd be
glad to collaborate.

>> Ok. Let me try to express it in English once more:
>> search: To be a maintainer I need:
>> replace: To be willing to become a maintainer I need:
>
> Nobody proposed you to become a maintainer, so this is still besides the
> point. First contribute significantly, and then we'll see.

Can you estimate my contributions so far?
I suspect I should stop wasting time if there are aren't any.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9008>
_______________________________________

From report at bugs.python.org  Thu Jun 17 15:29:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Jun 2010 13:29:16 +0000
Subject: [issue9008] CGIHTTPServer support for arbitrary CGI scripts
In-Reply-To: <AANLkTikIsN57ATkpzobp3hX-NpmR5-Wpy8dilSxb7d4b@mail.gmail.com>
Message-ID: <1276781351.3158.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 17 juin 2010 ? 13:22 +0000, anatoly techtonik a ?crit :
> 
> > That's a lot of things which others do not perceive as important or even
> > desireable. Chances are you are going to have to implement them yourself
> > if you really want them. In any case, just complaining won't change
> > anything.
> 
> I am just trying to answer why I can't contribute patches myself.

Thank you, I think you have made your point.
Now I suggest you propose patches to improve the workflow on the
relevant mailing-list(s) or issue tracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9008>
_______________________________________

From report at bugs.python.org  Thu Jun 17 15:31:44 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jun 2010 13:31:44 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1276781504.33.0.585437074366.issue9011@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

That sounds like a reasonable quick fix.

Here's a patch.

----------
keywords: +patch
stage:  -> commit review
Added file: http://bugs.python.org/file17696/issue9011.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Thu Jun 17 15:36:58 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 17 Jun 2010 13:36:58 +0000
Subject: [issue8937] SimpleHTTPServer should contain usage example
In-Reply-To: <1275975534.8.0.563527396515.issue8937@psf.upfronthosting.co.za>
Message-ID: <1276781818.6.0.117926476667.issue8937@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

The example is really helpful. I was surprised to learn that SimpleHTTPServer can be called from command line with port argument. I thought it is only for testing. Another missed aspect is that it is possible to use SimpleHTTPRequestHandler with TCPServer, so HTTPServer is not required. But now I wonder about compatibility of handlers vs servers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8937>
_______________________________________

From report at bugs.python.org  Thu Jun 17 15:40:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Jun 2010 13:40:16 +0000
Subject: [issue9018] os.path.normcase(None) does not raise an error on linux
	and should
In-Reply-To: <1276782016.7.0.192519527211.issue9018@psf.upfronthosting.co.za>
Message-ID: <1276782016.7.0.192519527211.issue9018@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

os.path.normcase(None) raises an error on Windows but returns None on linux.  os.path.abspath(None) raises an error in both cases.  os.path.normcase(None) should raise an error on linux.

I've only marked this for 3.2 because I suspect there may be linux code out there that this will break, so the fix should probably only be applied to 3.2.  (I discovered this because a unit test someone else wrote passed on linux but failed on windows.)

----------
keywords: easy
messages: 108016
nosy: r.david.murray
priority: normal
severity: normal
stage: unit test needed
status: open
title: os.path.normcase(None) does not raise an error on linux and should
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9018>
_______________________________________

From report at bugs.python.org  Thu Jun 17 15:41:22 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 17 Jun 2010 13:41:22 +0000
Subject: [issue9018] os.path.normcase(None) does not raise an error on linux
	and should
In-Reply-To: <1276782016.7.0.192519527211.issue9018@psf.upfronthosting.co.za>
Message-ID: <1276782082.47.0.193731920535.issue9018@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/issue9018>
_______________________________________

From report at bugs.python.org  Thu Jun 17 15:46:28 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 17 Jun 2010 13:46:28 +0000
Subject: [issue9017] doctest option flag to enable/disable some chunk of
	doctests?
In-Reply-To: <1276778533.38.0.325280903618.issue9017@psf.upfronthosting.co.za>
Message-ID: <1276782388.41.0.441426706861.issue9017@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Library (Lib) -Tests
stage:  -> unit test needed
title: What do you think about an Option Flags to enable/disable some chunk of doctest file ? -> doctest option flag to enable/disable some chunk of doctests?
type:  -> feature request
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9017>
_______________________________________

From report at bugs.python.org  Thu Jun 17 15:59:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Jun 2010 13:59:01 +0000
Subject: [issue7370] BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1276783141.64.0.50288401754.issue7370@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The HTTP RFCs reference the email RFCs for the date format, so the email package is the logical place for this function: email is the correct responsible party.  In any case, the function resides in email.utils, which has no dependencies on anything else in the email package.  Of course, it does have dependencies on other parts of the python standard library, but I hardly think you'd want every module re-implementing every stdlib function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Thu Jun 17 16:21:37 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 17 Jun 2010 14:21:37 +0000
Subject: [issue9018] os.path.normcase(None) does not raise an error on linux
	and should
In-Reply-To: <1276782016.7.0.192519527211.issue9018@psf.upfronthosting.co.za>
Message-ID: <1276784497.95.0.0106938810329.issue9018@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/issue9018>
_______________________________________

From report at bugs.python.org  Thu Jun 17 16:21:57 2010
From: report at bugs.python.org (Tim Golden)
Date: Thu, 17 Jun 2010 14:21:57 +0000
Subject: [issue850997] mbcs encoding ignores errors
In-Reply-To: <1276300920.01.0.0622409400114.issue850997@psf.upfronthosting.co.za>
Message-ID: <4C1A2F81.3000605@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

I'm unlikely to get to it soon. If there's no urgency I can
look at it later. FWIW, it's not something I'm especially
familiar with.

On 12/06/2010 01:02, STINNER Victor wrote:
>
> STINNER Victor<victor.stinner at haypocalc.com>  added the comment:
>
> Tim: are you interested in testing this patch?
>
> ----------
> nosy: +tim.golden
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue850997>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue850997>
_______________________________________

From report at bugs.python.org  Thu Jun 17 16:24:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Jun 2010 14:24:25 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276784665.96.0.495097984522.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I would like to move this forward.  The PyPy implementation at

http://codespeak.net/pypy/dist/pypy/lib/datetime.py

claims to be based on the original CPython datetime implementation from the time when datetime was a python module.  I looked through the code and it seems to be very similar to datetime.c.  Some docstings and comments are literal copies.  I think it will not be hard to port that to 3.x.

I have a few questions, though.

1. I remember seeing python-dev discussion that concluded that the best way to distribute parallel C and Python implementations was to have module.py with the following:

# pure python implementation

def foo():
    pass

def bar():
    pass

# ..

try:
    from _module import *
except ImportError:
    pass

Is this still the state of the art?  What about parsing overhead?

2. Is there a standard mechanism to ensure that unitests run both python and C code?  I believe sys.module['_module'] = None will prevent importing _module.  Is there direct regrtest support for this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 16:31:35 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 17 Jun 2010 14:31:35 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1276784665.96.0.495097984522.issue7989@psf.upfronthosting.co.za>
Message-ID: <4C1A31C3.5080202@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> I would like to move this forward.  The PyPy implementation at
> 
> http://codespeak.net/pypy/dist/pypy/lib/datetime.py
> 
> claims to be based on the original CPython datetime implementation from the time when datetime was a python module.  I looked through the code and it seems to be very similar to datetime.c.  Some docstings and comments are literal copies.  I think it will not be hard to port that to 3.x.
> 
> I have a few questions, though.
> 
> 1. I remember seeing python-dev discussion that concluded that the best way to distribute parallel C and Python implementations was to have module.py with the following:
> 
> # pure python implementation
> 
> def foo():
>     pass
> 
> def bar():
>     pass
> 
> # ..
> 
> try:
>     from _module import *
> except ImportError:
>     pass
> 
> Is this still the state of the art?  What about parsing overhead?

That approached was used for modules where the C bits replaced the Python
ones. The Python bites were then typically removed altogether.

To avoid the wasted memory and import time, it's better to use:

try:
    from _cmodule import *
except ImportError:
    from _pymodule import *

> 2. Is there a standard mechanism to ensure that unitests run both python and C code?  I believe sys.module['_module'] = None will prevent importing _module.  Is there direct regrtest support for this?

Why not import the two modules directly ?

import _cmodule as module
and
import _pymodule as module

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 16:32:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Jun 2010 14:32:19 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276785139.1.0.556544341467.issue7989@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Is this still the state of the art?  What about parsing overhead?

The io module has three modules:
- io.py just imports everything from _io
- _io is the default C implementation
- _pyio.py must be imported explicitly to get the pure Python implementation

=> no parsing overhead for the default case of importing the C implementation

> Is there direct regrtest support for this?

You can take a look at test_io, test_memoryio or test_heapq for inspiration.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 16:36:02 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 17 Jun 2010 14:36:02 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1276785362.42.0.145737391898.issue8857@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> Anyway, getaddrinfo() on FreeBSD/Qemu gives this

It seems SOCK_DGRAM is always returned which, as far as I know, doesn't make sense with FTP and SSH protocols. 
At this point, assuming getaddrinfo() correctly binds the original C function, I'd be for just removing this test since it's unreliable across all platforms.
New patch is in attachment.

----------
Added file: http://bugs.python.org/file17697/getaddrinfo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Thu Jun 17 16:36:10 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 17 Jun 2010 14:36:10 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1276785370.09.0.154999787186.issue8857@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


Removed file: http://bugs.python.org/file17692/getaddrinfotest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Thu Jun 17 16:36:13 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 17 Jun 2010 14:36:13 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1276785373.13.0.0598762509901.issue8857@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


Removed file: http://bugs.python.org/file17693/getaddrinfotest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Thu Jun 17 16:45:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Jun 2010 14:45:23 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276785923.86.0.644517738208.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Jun 17, 2010 at 10:31 AM, Marc-Andre Lemburg <report at bugs.python.org> wrote:
..
> To avoid the wasted memory and import time, it's better to use:
>
> try:
> ? ?from _cmodule import *
> except ImportError:
> ? ?from _pymodule import *
>

Hmm, I cannot find the relevant thread, but I thought this was rejected at some point.  Personally, I don't like this at all for the following reasons:

1. This introduces two _.. names instead of one.

2. This departs from established convention that C (or native) implementation for modulename is in _modulename, not _cmodulename.  Non-C implementations may still provide native _modulename, but would not want to call it _cmodulename.

3. Hiding python code in _pymodule makes it harder to find it.

..
> Why not import the two modules directly ?
>
> import _cmodule as module
> and
> import _pymodule as module
>

Because this requires having two modules in the first place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 16:49:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Jun 2010 14:49:16 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276786156.3.0.931625302259.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> To avoid the wasted memory and import time, it's better to use:
>
> try:
>    from _cmodule import *
> except ImportError:
>    from _pymodule import *
>

.. also this makes it harder to prototype things in Python or have mixed Python/C modules.  The goal is to use Python implementation unless native implementation exists on per function/class basis.  The syntax above makes it all or nothing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 16:55:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Jun 2010 14:55:32 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276786532.31.0.995437745416.issue7989@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think we have no standard for this yet, though it has been discussed.  If you can't find a python-dev thread about it, you should probably start a new one.

As one example, heapq does:

  try:
      from _heapq import *
  except ImportError:
       pass

after having defined the python.  Which does not incur parsing overhead in most real-world situations since most distributions generate the .pyc files during install, but does incur the execution overhead on first import.

On the other hand, io doesn't fall back to _pyio at all (perhaps this is a bug).

As for the tests, the way this is typically done is that you define a base test class that is *not* a TestCase, and then you define two subclasses that are TestCases and mix in the base class.  You then assign the appropriate module (or function or whatever) under test as attributes of the subclasses, and the base class uses those attributes to run the tests.  That way you know all the tests are run for both the Python and the C implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 16:59:02 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 17 Jun 2010 14:59:02 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1276785923.86.0.644517738208.issue7989@psf.upfronthosting.co.za>
Message-ID: <4C1A3832.7000902@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> On Thu, Jun 17, 2010 at 10:31 AM, Marc-Andre Lemburg <report at bugs.python.org> wrote:
> ..
>> To avoid the wasted memory and import time, it's better to use:
>>
>> try:
>>    from _cmodule import *
>> except ImportError:
>>    from _pymodule import *
>>
> 
> Hmm, I cannot find the relevant thread, but I thought this was rejected at some point.  Personally, I don't like this at all for the following reasons:
> 
> 1. This introduces two _.. names instead of one.
> 
> 2. This departs from established convention that C (or native) implementation for modulename is in _modulename, not _cmodulename.  Non-C implementations may still provide native _modulename, but would not want to call it _cmodulename.
> 
> 3. Hiding python code in _pymodule makes it harder to find it.

Well, you wanted to have two implementation of the same thing in the
stdlib :-) I personally don't think that's a good idea. We've had
trouble in the past of keeping pickle.py and cPickle.c in sync, it's
not going to be much different with those two datetime implementations.

In any case, we shouldn't make regular CPython use of datetime slower
and use more memory, just to make life easier for PyPy.

>> Why not import the two modules directly ?
>>
>> import _cmodule as module
>> and
>> import _pymodule as module
>>
> 
> Because this requires having two modules in the first place.

Where's the problem ? Disk space ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 17:00:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Jun 2010 15:00:10 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276786810.62.0.24661608039.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Jun 17, 2010 at 10:32 AM, Antoine Pitrou <report at bugs.python.org> wrote:
..
>> Is there direct regrtest support for this?
>
> You can take a look at test_io, test_memoryio or test_heapq for inspiration.
>

I looked at test_io and don't like that approach.  It seems to require subclassing each TestCase twice for C and Python.  There is no mechanism to assure that all tests are replicated that way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 17:02:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Jun 2010 15:02:35 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1276786810.62.0.24661608039.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276786951.3158.11.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I looked at test_io and don't like that approach.  It seems to require
> subclassing each TestCase twice for C and Python.  There is no
> mechanism to assure that all tests are replicated that way.

Subclassing /is/ the mechanism :)
Furthermore, some rare tests are Py-specific and some rare others are
C-specific: you want specific test classes for them anyway.

The only alternative is to manually duplicate tests, these leads to very
poor test coverage because of the average developer's laziness (json is
an example).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 17:03:33 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 17 Jun 2010 15:03:33 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1276786156.3.0.931625302259.issue7989@psf.upfronthosting.co.za>
Message-ID: <4C1A3941.2080100@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
>> To avoid the wasted memory and import time, it's better to use:
>>
>> try:
>>    from _cmodule import *
>> except ImportError:
>>    from _pymodule import *
>>
> 
> .. also this makes it harder to prototype things in Python or have mixed Python/C modules.  The goal is to use Python implementation unless native implementation exists on per function/class basis.  The syntax above makes it all or nothing.

Why ?

You can have the Python parts that are used by both implementation
defined in the datetime.py module.

Alternatively, you could write:

try:
    # Use the faster C version
    from _module import *
except ImportError:
    # Use Python
    class datetime:
        ...

I find that rather ugly, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 17:35:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Jun 2010 15:35:12 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276788912.15.0.431056625048.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> The only alternative is to manually duplicate tests, these leads to very
> poor test coverage because of the average developer's laziness (json is
> an example).

No, here is another alternative:


==> _example.py <==
def foo():
    print(__name__)

==> example.py <==
def foo():
    print(__name__)
try:
    from _example import *
except ImportError:
    pass

==> test_example.py <==
import sys
sys.modules['_example'] = None
import example
example.foo()
del sys.modules['_example']
import _example as example
example.foo()

With the code above,

$ ./python.exe test_example.py
example
_example


If we move import to setUp(), we can run each test case twice: with and without native code.  Tests that are specific to one implementation can be run once or skipped conditionally on per test method basis.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 18:32:35 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 17 Jun 2010 16:32:35 +0000
Subject: [issue4452] Incorrect docstring of os.setpgrp
In-Reply-To: <1227882211.37.0.737329471777.issue4452@psf.upfronthosting.co.za>
Message-ID: <1276792355.67.0.614415531659.issue4452@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Yes, its valid doc change request. Thought it means the same, the minor docstring improvement can be done.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4452>
_______________________________________

From report at bugs.python.org  Thu Jun 17 18:40:50 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jun 2010 16:40:50 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276792850.34.0.371778124175.issue6641@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Doc nit: "When ``%z`` directive" -> "When the ``%z`` directive"

The _strptime._strptime docstring is inaccurate:  it claim to return a time struct, but actually returns tuple, int;  please could you also add docstrings for _strptime_time and _strptime_datetime?

Spacing in datetimemodule.c:  "if( module == NULL)" -> "if (module == NULL)".  Also, is there any particular reason for initializing 'result' to NULL?  (Or even for using result at all;  you could just do "return PyObject_CallMethod(... ").

I'm mildly distressed by the inability of strptime to parse UTC offsets in the +HH:MM form that str(timezone) produces, but I'm not sure what the solution to that is.

Otherwise, this all looks good to my non-expert eye.

----------
assignee: mark.dickinson -> belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Thu Jun 17 18:43:53 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jun 2010 16:43:53 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276793033.59.0.262631814151.issue6641@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm. Hold on a sec;  I'm getting test failures...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Thu Jun 17 18:44:57 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jun 2010 16:44:57 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276793097.76.0.46494914946.issue6641@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

In test_datetime:


======================================================================
ERROR: test_strptime (__main__.TestDateTime)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_datetime.py", line 1741, in test_strptime
    dt = strptime("-0500 EST", "%z %Z")
  File "/Users/dickinsm/python/svn/py3k/Lib/_strptime.py", line 483, in _strptime_datetime
    tt, fraction = _strptime(data_string, format)
  File "/Users/dickinsm/python/svn/py3k/Lib/_strptime.py", line 336, in _strptime
    (data_string, format))
ValueError: time data '-0500 EST' does not match format '%z %Z'

======================================================================
ERROR: test_strptime (__main__.TestDateTimeTZ)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_datetime.py", line 1741, in test_strptime
    dt = strptime("-0500 EST", "%z %Z")
  File "/Users/dickinsm/python/svn/py3k/Lib/_strptime.py", line 483, in _strptime_datetime
    tt, fraction = _strptime(data_string, format)
  File "/Users/dickinsm/python/svn/py3k/Lib/_strptime.py", line 336, in _strptime
    (data_string, format))
ValueError: time data '-0500 EST' does not match format '%z %Z'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Thu Jun 17 18:46:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Jun 2010 16:46:30 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276793190.78.0.661578040039.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Porting PyPy implementation to 2.7 was fairly easy.  I am posting the patch which makes PyPy datetime.py pass regression tests when dropped in the trunk.

I expect 3.x port to be uneventful as well.  Raising the priority because I would like to check this in before other datetime feature requests.

----------
keywords: +patch
priority: low -> high
Added file: http://bugs.python.org/file17698/PyPy-2.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 18:53:00 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 17 Jun 2010 16:53:00 +0000
Subject: [issue4452] Incorrect docstring of os.setpgrp
In-Reply-To: <1227882211.37.0.737329471777.issue4452@psf.upfronthosting.co.za>
Message-ID: <1276793580.21.0.741056786507.issue4452@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

The docstring "Make this process the process group leader" is proper for setpgrp. Fixed in r82047, r82048, r82049 and r82050.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4452>
_______________________________________

From report at bugs.python.org  Thu Jun 17 19:48:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Jun 2010 17:48:09 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276796889.1.0.809830443832.issue7989@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't see how "moving the import to setUp" is going to avoid having to explicitly run each set of tests twice, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 19:52:50 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jun 2010 17:52:50 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276797170.29.0.860241044863.issue7989@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/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 19:53:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Jun 2010 17:53:51 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276797231.81.0.954270467281.issue6641@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

issue6641a.diff fixes the nits that Mark found and makes the tests robust with respect to change of timezones.  Tested with all timezones avalilable on OSX including TZ="Eire".  (Ever heard of Ouagadougou?)

Parsing RFC 3339's HH:MM format is a separate issue. I am +1 on either adding %:z specifier or simply allow HH:MM for %z.

----------
resolution:  -> accepted
Added file: http://bugs.python.org/file17699/issue6641a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Thu Jun 17 19:54:12 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jun 2010 17:54:12 +0000
Subject: [issue8469] struct - please make sizes explicit
In-Reply-To: <1271766650.13.0.432849451622.issue8469@psf.upfronthosting.co.za>
Message-ID: <1276797252.07.0.256648050861.issue8469@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8469>
_______________________________________

From report at bugs.python.org  Thu Jun 17 20:00:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jun 2010 18:00:31 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276797631.36.0.0150433453241.issue6641@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Thu Jun 17 20:26:28 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jun 2010 18:26:28 +0000
Subject: [issue7261] Document 2.x -> 3.x round changes in "What's New"
	documents.
In-Reply-To: <1257330793.87.0.85024867948.issue7261@psf.upfronthosting.co.za>
Message-ID: <1276799188.59.0.595734239107.issue7261@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied in r82051 (py3k) and r82052 (release31-maint).

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7261>
_______________________________________

From report at bugs.python.org  Thu Jun 17 20:32:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Jun 2010 18:32:48 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276799568.69.0.175312913902.issue6641@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r82053.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Thu Jun 17 20:33:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Jun 2010 18:33:17 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276799597.49.0.0633453059931.issue6641@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Thu Jun 17 20:34:17 2010
From: report at bugs.python.org (Marcel Hellkamp)
Date: Thu, 17 Jun 2010 18:34:17 +0000
Subject: [issue9019] wsgiref.headers.Header() does not update headers list it
	was created with.
In-Reply-To: <1276799657.02.0.296941207361.issue9019@psf.upfronthosting.co.za>
Message-ID: <1276799657.02.0.296941207361.issue9019@psf.upfronthosting.co.za>


New submission from Marcel Hellkamp <defnull at gmail.com>:

The current (3.x) implementation of wsgiref.headers.Headers() does not match the documentation.

Documented behaviour:
"Any changes made to the new Headers object will directly update the headers list it was created with." (/Doc/library/wsgiref.rst)

Actual behaviour:
The initial headers list is not updated.

The error was introduced with revision 68205. See http://svn.python.org/view/python/branches/py3k/Lib/wsgiref/headers.py?view=diff&r1=68204&r2=68205

Revision 68204::
    >>> from wsgiref.headers import Headers
    >>> l = []
    >>> h = Headers(l)
    >>> h.add_header('Test','Test')
    >>> l
    [('Test', 'Test')]

Revision 68205::
    >>> from wsgiref.headers import Headers
    >>> l = []
    >>> h = Headers(l)
    >>> h.add_header('Test','Test')
    >>> l
    []

----------
components: Library (Lib)
messages: 108042
nosy: Marcel.Hellkamp
priority: normal
severity: normal
status: open
title: wsgiref.headers.Header() does not update headers list it was created with.
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9019>
_______________________________________

From report at bugs.python.org  Thu Jun 17 20:36:04 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jun 2010 18:36:04 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1276799764.36.0.85733556735.issue2775@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/issue2775>
_______________________________________

From report at bugs.python.org  Thu Jun 17 20:37:19 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 17 Jun 2010 18:37:19 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1276799839.44.0.151788291444.issue4370@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

According to http://gcc.gnu.org/releases.html, gcc 2.95.3 is about 9 years old, so we don't need to care about warnings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Thu Jun 17 20:42:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Jun 2010 18:42:21 +0000
Subject: [issue5023] Segfault in datetime.time.strftime("%z")
In-Reply-To: <1232556285.78.0.999173961019.issue5023@psf.upfronthosting.co.za>
Message-ID: <1276800141.34.0.55538575741.issue5023@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Since this does not seem to be reproducible anymore, I am going to close this soon.

----------
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5023>
_______________________________________

From report at bugs.python.org  Thu Jun 17 20:47:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Jun 2010 18:47:18 +0000
Subject: [issue1726687] Bug found in datetime for Epoch time = -1
Message-ID: <1276800438.95.0.339067453955.issue1726687@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Is this important enough to try to get in 2.7 before rc2?  Victor?

----------
components: +Extension Modules -None
type:  -> behavior
versions: +Python 3.2 -Python 2.5, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1726687>
_______________________________________

From report at bugs.python.org  Thu Jun 17 20:49:03 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jun 2010 18:49:03 +0000
Subject: [issue4370] warning: unknown conversion type character `z' in format
In-Reply-To: <1227205239.88.0.419191399789.issue4370@psf.upfronthosting.co.za>
Message-ID: <1276800543.36.0.742663895757.issue4370@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I agree.

----------
nosy: +mark.dickinson
resolution:  -> wont fix
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4370>
_______________________________________

From report at bugs.python.org  Thu Jun 17 20:54:07 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 17 Jun 2010 18:54:07 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276800847.88.0.609071962306.issue7989@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

A couple of things about all of this.

One, we should not blindly pull in the PyPy code without some core PyPy developer being in on this; just common courtesy and I don't think anyone participating in this discussion is a PyPy developer (but I could be wrong).

Two, as David pointed out, parsing overhead is pretty minor thing to be worrying about thanks to bytecode. The import * solution at the end of the main file is the agreed-upon approach (it has been discussed at some point).

Three, for testing you can also look at test_warnings (the creation of _warnings led to the discussion of best practices for all of this). Basically you use test.support.import_fresh_module to get the pure Python version and the C-enhanced one, write your tests with the module being tested set on the class, and then subclass with the proper modules as a class attribute. I understand your worry, Alexander, about accidentally missing a test class for a module, but in practice that will be rare as people will be watching for that, and you just do the subclass first. There is in practice no need to get too fancy, and you have to make sure your tests are discoverable anyway by test runners that simply look for classes that inherit from unittest.TestCase.

Best alternative you could do is a metaclass that searches for tests that start with 'test' *and* take an argument for the module to test, and then auto-create methods that take *no* arguments and then call the test methods directly (after renaming them so that test runners don't try to use them). Then you can pass in the modules to test as arguments to the metaclass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 21:12:35 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 17 Jun 2010 19:12:35 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276801955.46.0.336440772302.issue7989@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> One, we should not blindly pull in the PyPy code 
> without some core PyPy developer being in on this

I concur.  Much of PyPy code is written for a restricted subset of Python instead of clean, idiomatic modern Python.

Also, this should not be marked as high priority.  It may be a personal priority for you, but it is by no means essential for Py3.2 or something that other developers should prioritize higher than other tasks like fixing bugs.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 21:19:24 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 17 Jun 2010 19:19:24 +0000
Subject: [issue9018] os.path.normcase(None) does not raise an error on linux
	and should
In-Reply-To: <1276782016.7.0.192519527211.issue9018@psf.upfronthosting.co.za>
Message-ID: <1276802364.96.0.224029167526.issue9018@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Right now posixpath returns the argument unchanged, ntpath performs a .replace(), and macpath a .lower(), so when non-string (or non-bytes) are passed to normcase the results are:
posixpath: arg returned as-is;
ntpath: AttributeError (object has no attribute 'replace');
macpath: AttributeError (object has no attribute 'lower');

In posixpath we could reject all the non-string (and non-bytes) args, raising a TypeError. For consistency, the other functions should raise a TypeError too, but I'm not sure it's worth changing it.

Attached a simple testcase that checks that normcase raises a TypeError for invalid values with all the three implementations.

----------
keywords: +patch
stage: unit test needed -> needs patch
Added file: http://bugs.python.org/file17700/issue9018.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9018>
_______________________________________

From report at bugs.python.org  Thu Jun 17 21:20:18 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 17 Jun 2010 19:20:18 +0000
Subject: [issue9018] os.path.normcase(None) does not raise an error on linux
	and should
In-Reply-To: <1276782016.7.0.192519527211.issue9018@psf.upfronthosting.co.za>
Message-ID: <1276802418.76.0.122862172917.issue9018@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords:  -patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9018>
_______________________________________

From report at bugs.python.org  Thu Jun 17 21:23:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Jun 2010 19:23:44 +0000
Subject: [issue9018] os.path.normcase(None) does not raise an error on linux
	and should
In-Reply-To: <1276782016.7.0.192519527211.issue9018@psf.upfronthosting.co.za>
Message-ID: <1276802624.48.0.189042777264.issue9018@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I've only marked this for 3.2 because I suspect there may be linux code 
> out there that this will break,

It should be noticed that Linux-only code has absolutely no point in using normcase(), since it's a no-op there.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9018>
_______________________________________

From report at bugs.python.org  Thu Jun 17 21:31:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Jun 2010 19:31:04 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276803064.19.0.979765644185.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> Also, this should not be marked as high priority.  It may be a
> personal priority for you, ...

Reverting priority.  I thought once an issue is assigned, the priority becomes the priority that assignee places on the issue. Sorry for the confusion.

----------
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 21:33:42 2010
From: report at bugs.python.org (jeff)
Date: Thu, 17 Jun 2010 19:33:42 +0000
Subject: [issue3874] documentation bug: HTMLParser needs to document
	unknown_decl
In-Reply-To: <1276736133.13.0.311860455742.issue3874@psf.upfronthosting.co.za>
Message-ID: <AANLkTilwn_Np9AKx4cijzrXBDpNzdRrySMWcihZ2rRCd@mail.gmail.com>


jeff <freyley at gmail.com> added the comment:

On Wed, Jun 16, 2010 at 5:55 PM, Terry J. Reedy <report at bugs.python.org> wrote:
>
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
>
> Documentation issues should be component: documentation rather than library. When submitting one, please at least indicate the module or class concerned. I have never heard of 'unknown_decl' function.

It's your bug tracker. This sort of statement that says that I should
know exactly how you want bugs reported only serves to tell people
like me not to even try. In addition, it's inaccurate in this case, as
the title of the bug is that HTMLParser, which is a module in the
standard library, needs a function documented.

HTMLParser runs over HTML and calls internal functions when certain
events occur. unknown_decl is called when an unknown declaration is
found, and by default, it throws an exception. Thus, to correctly use
HTMLParser, when subclassing it, you need to override unknown_decl if
there are any unknown declarations in your HTML (or if you think there
might be).

> Preferably, indicate the specific section you want modified, by version, number and name. Best is to submit a suggested text to be inserted. ?You may know better than most issue reviewers what should be said. Someone else will add markup and possibly edit.

It's been almost 2 years since I submitted this bug. I don't know if
it applies to Python 3, and at this point I find it difficult to care.

Thanks,

Jeff

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3874>
_______________________________________

From report at bugs.python.org  Thu Jun 17 21:37:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Jun 2010 19:37:57 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276803477.78.0.363015927147.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

>> One, we should not blindly pull in the PyPy code
>> without some core PyPy developer being in on this
>
> I concur. ?Much of PyPy code is written for a restricted subset of
> Python instead of clean, idiomatic modern Python.

Raymond, I think you misread Brett's comment the same way as I did when I first saw it.  Brett wrote "core PyPy developer", not "core CPython developer".  Of course this will go through normal patch review process and will be looked at by at least two cpython developers before it goes it.  I also agree with Brett that it would be great to get input from PyPy developers and they may see benefit from 2.7 and 3.x ports of their code.  I am just not familiar with PyPy community and will have to research how to approach them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 21:43:55 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 17 Jun 2010 19:43:55 +0000
Subject: [issue3874] documentation bug: HTMLParser needs to document
	unknown_decl
In-Reply-To: <1221515609.61.0.396859142368.issue3874@psf.upfronthosting.co.za>
Message-ID: <1276803835.29.0.670497132722.issue3874@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at acm.org>:


----------
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3874>
_______________________________________

From report at bugs.python.org  Thu Jun 17 21:44:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jun 2010 19:44:18 +0000
Subject: [issue1726687] Bug found in datetime for Epoch time = -1
Message-ID: <1276803858.18.0.767949098931.issue1726687@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Is this important enough to try to get in 2.7 before rc2?

I prefer to not include this patch in 2.7. I don't think that many people have this problem and it can be fixed later. It's too late for 2.7. Should it be fixed in 2.7.1 or only in 3.2 (and maybe in 3.1)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1726687>
_______________________________________

From report at bugs.python.org  Thu Jun 17 21:47:20 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 17 Jun 2010 19:47:20 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276804040.74.0.703804496332.issue7989@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I would simply email their developer mailing list (find it at http://pypy.org/contact.html) and say that you are willing to work on this. Maciej and I have discussed this before, so this won't be a total shock to them.

As for Raymond's comment, I think he understood what I meant. What he is worried about is that datetime as PyPy has implemented it is done in RPython which is a custom subset of Python, and not a "normal" Python implementation. But if they have simply been maintaining the pure Python version that Tim wrote way back in the day then I suspect it's not in RPython.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 21:47:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Jun 2010 19:47:26 +0000
Subject: [issue1726687] Bug found in datetime for Epoch time = -1
Message-ID: <1276804046.44.0.555069550134.issue1726687@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
priority: normal -> low
stage: patch review -> unit test needed
versions: +Python 3.1 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1726687>
_______________________________________

From report at bugs.python.org  Thu Jun 17 22:14:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Jun 2010 20:14:07 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276805647.0.0.493291783319.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching datetime-sandbox-pypy.diff, a plain diff between six-year-old sandbox and pypy versions.  (Plain diff is cleaner than unified diff.)

You can see that the differences are trivial.  I notice, however that original datetime implementation was returning subclass instances from operations on datetime subclass instances.  Brett, this is off-topic hear, but I would appreciate your take on msg107410.

BTW, in order to preserve history, it may be a good idea to develop this in a branch off datetime sandbox and merge it back when ready.

----------
Added file: http://bugs.python.org/file17701/datetime-sandbox-pypy.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 22:17:09 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 17 Jun 2010 20:17:09 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>
Message-ID: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

I first noticed this when `test_compare_function_objects` was taking forever to run. The culprit is that the following statement just hangs forever. Note that "eval(2)", for instance, runs fine, but when a builtin object is used (eg: None, True), it hangs.

  python -c "eval('None')"

This is reproducible on Python 2.7 (rc1 and latest trunk) and AIX 5.1.

This is regression, as it used to work on 2.6.

----------
components: Interpreter Core, Tests
messages: 108057
nosy: srid
priority: normal
severity: normal
status: open
title: 2.7: eval hangs on AIX
type: resource usage
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Thu Jun 17 22:18:37 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 17 Jun 2010 20:18:37 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>
Message-ID: <1276805917.52.0.599441683086.issue9020@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

eval('ghjsdjhgh') too hangs, btw.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Thu Jun 17 22:23:54 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 17 Jun 2010 20:23:54 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276806234.16.0.796517886816.issue7989@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I would not worry about the history too much; the code has been forked and pulling it back in means there is already some history missing. Just do what is easiest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Thu Jun 17 22:30:57 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 17 Jun 2010 20:30:57 +0000
Subject: [issue2267] datetime.datetime operator methods are not
	subclass-friendly
In-Reply-To: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za>
Message-ID: <1276806657.13.0.890991194849.issue2267@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

There is a difference between methods and overridden operators (slightly) in terms of cognitive understanding. I mean creating a new instance from a timestamp seems like an operation on the object by the object. Addition, though, seems like a creation of a new object by the two objects working together, which suggests contravariance.

Best I can think of. Otherwise ask on python-dev since Guido called the operator overriding expectation.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2267>
_______________________________________

From report at bugs.python.org  Thu Jun 17 22:52:19 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Jun 2010 20:52:19 +0000
Subject: [issue2267] datetime.datetime operator methods are not
	subclass-friendly
In-Reply-To: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za>
Message-ID: <1276807939.05.0.565867731541.issue2267@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I had understood that the rule was that alternate constructors should be classmethods, for consistency with __new__.  (Well, except that __new__ is actually a staticmethod, of course... )

E.g., after "class MyDecimal(Decimal): pass", MyDecimal('2.3') produces a MyDecimal instance, and by analogy MyDecimal.from_float(2.3) should also produce a MyDecimal instance.  It's exactly the same type of function as the class constructor.

I don't think it would do any harm to get clarification from python-dev on the underlying reasons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2267>
_______________________________________

From report at bugs.python.org  Thu Jun 17 23:11:00 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 17 Jun 2010 21:11:00 +0000
Subject: [issue5115] Extend subprocess.kill to be able to kill process groups
In-Reply-To: <1233370260.58.0.70597374825.issue5115@psf.upfronthosting.co.za>
Message-ID: <1276809060.32.0.0976836793169.issue5115@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

A strong +1 on adding this feature.

I was wondering... what if process A runs a subprocess B which runs a subprocess C. Is C still considered a children of A and gets killed as well?

Does os.setpgid() takes care of such a thing? What about Windows instead?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5115>
_______________________________________

From report at bugs.python.org  Thu Jun 17 23:11:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jun 2010 21:11:45 +0000
Subject: [issue6543] traceback presented in wrong encoding
In-Reply-To: <1248247915.99.0.198197502387.issue6543@psf.upfronthosting.co.za>
Message-ID: <1276809105.5.0.0281343292329.issue6543@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Update and improve the patch:
 - Update the patch to py3k (replace tabs by spaces)
 - check if _PyUnicode_AsString() result is NULL
 - _Py_FindSourceFile() returns the file instead of NULL on success!
 - use directly "utf-8" instead of calling PyUnicode_GetDefaultEncoding() for the default source code encoding (which is constant)
 - use PyUnicode_FromFormat() instead of PyOS_snprintf() in tb_displayline() to avoid conversion from unicode to utf-8 and then convert utf-8 back to unicode (in PyFile_WriteString). name type is now PyObject*
 - reindent also PyTracebackObject structure in traceback.h, just because I hate tabs :-)

----------
Added file: http://bugs.python.org/file17702/traceback-encoding-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6543>
_______________________________________

From report at bugs.python.org  Thu Jun 17 23:19:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Jun 2010 21:19:47 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>
Message-ID: <1276809587.19.0.071720723959.issue9020@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since it works fine on Linux, maybe you could do some bisecting on the revision history to try to identify what rev broke it on AIX?

How does it behave with the head of the current 2.6 maintenance branch, by the way?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Thu Jun 17 23:46:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jun 2010 21:46:07 +0000
Subject: [issue8203] IDLE about dialog credits raises UnicodeDecodeError
In-Reply-To: <1269291921.68.0.001122865499.issue8203@psf.upfronthosting.co.za>
Message-ID: <1276811167.5.0.0960374919546.issue8203@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited in Python 3.1 (r82058) and 3.2 (r82057).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8203>
_______________________________________

From report at bugs.python.org  Thu Jun 17 23:46:46 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 17 Jun 2010 21:46:46 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>
Message-ID: <1276811206.48.0.530486807933.issue9020@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

I traced the "infinite loop" to tokenizer.c:tok_get around line 1368:

        while (Py_ISALNUM(c) || c == '_') {
            c = tok_nextc(tok);
        }

Adding a `printf` statement at the beginning of the loop:

            printf("tok_get: third while: c = %c (%d) ... Py_ISALNUM=%d\n", c, c, Py_ISALNUM(c));

Output:

tok_get: third while: c = ? (-1) ... Py_ISALNUM=2
tok_get: third while: c = ? (-1) ... Py_ISALNUM=2
tok_get: third while: c = ? (-1) ... Py_ISALNUM=2
tok_get: third while: c = ? (-1) ... Py_ISALNUM=2
tok_get: third while: c = ? (-1) ... Py_ISALNUM=2
tok_get: third while: c = ? (-1) ... Py_ISALNUM=2
tok_get: third while: c = ? (-1) ... Py_ISALNUM=2
tok_get: third while: c = ? (-1) ... Py_ISALNUM=2
[...]


I may not spend much time on this bug, unless someone can hint at what might have gone wrong here?

As for 2.6-maint, I will find that out sometime this week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Fri Jun 18 00:08:31 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 17 Jun 2010 22:08:31 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>
Message-ID: <1276812511.8.0.969995810184.issue9020@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Py_CHARMASK(c) = 4294967295

And I think I found the problem: from Include/Python.h

/* Convert a possibly signed character to a nonnegative int */
/* XXX This assumes characters are 8 bits wide */
#ifdef __CHAR_UNSIGNED__
#define Py_CHARMASK(c)		(c)
#else
#define Py_CHARMASK(c)		((unsigned char)((c) & 0xff))
#endif

__CHAR_UNSIGNED__ is defined to 1, but when I printed the value of sizeof(c) in the above while loop, it printed 4. Therefore .. c is 32 bits side.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Fri Jun 18 00:30:32 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 22:30:32 +0000
Subject: [issue3874] documentation bug: HTMLParser needs to document
	unknown_decl
In-Reply-To: <1221515609.61.0.396859142368.issue3874@psf.upfronthosting.co.za>
Message-ID: <1276813832.54.0.751318282558.issue3874@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I understand that getting no response to a submission is not pleasant. I do not like it either. That is partly why I have started reviewing old issues. In the past couple of weeks, I have gotten old two orphaned patches applied by updating the headers, reading the patch, and adding a first-response approval message that got the attention of someone with code-commit privileges. I hope you agree that late is better than never.

I just discovered the nosy-count box on the search page. 351 open issues with a nosy count of 1 (which means no response unless someone responded and then removed themself) is too many. We need more issue reviewers.

As to your message: this is *our* tracker, not my tracker. My participation is as much voluntary as yours. I hope you do not really give up on improving Python and its documentation.

I did not expect that you *should* have known submission details. That is why I tried to inform you. In particular, when an issue is marked as 'documentation', it is automatically assigned to 'docs at python', a pseudo-user standing in for people who handle doc revisions. Now they will see this issue, whereas they would not have before.

Please excuse me for not remembering the title as I responded to the message. It is best if message text stands alone. Again, I hope you would agree that an somewhat ignorant response may be better than none.

In order for the doc maintainers to add an entry, someone knowledgeable must write it. Your paragraph of explanation is a start, but more editing is needed.

Looking at dir(html.parser.HTMLParser) and help(...), I see that there are several public internal methods. Some have doc strings that show up with help(), some do not. I thing all should. Some are defined on HTMLParser and some inherited from the undocumented (I believe) _markupbase.ParserBase.

I see that there are also several (completely undocumented except fir dir()) private ('_xyz') internal methods. This implies to me that the public internal methods were made public rather than private because there might be reason to override them. If so, perhaps there should be a new subsection on public internal methods to explain what is what with them. What do you think? Document just one, some, or all?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3874>
_______________________________________

From report at bugs.python.org  Fri Jun 18 01:18:33 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 17 Jun 2010 23:18:33 +0000
Subject: [issue9021] no copy.copy problem description
In-Reply-To: <1276816713.34.0.416523004663.issue9021@psf.upfronthosting.co.za>
Message-ID: <1276816713.34.0.416523004663.issue9021@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

`copy` module covers very important aspect of Python programming. However its documentation doesn't provide any intro or overview of this problem starting right from details. When people meet `copy` construction in the code - the refer to module documentation and its doesn't completely answer two basic questions they have:

1. why copy module is needed (i.e. what's the problem with var assignment)
2. when and where it should be used

----------
assignee: docs at python
components: Documentation
messages: 108069
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: no copy.copy problem description
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9021>
_______________________________________

From report at bugs.python.org  Fri Jun 18 01:24:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jun 2010 23:24:02 +0000
Subject: [issue6543] traceback presented in wrong encoding
In-Reply-To: <1248247915.99.0.198197502387.issue6543@psf.upfronthosting.co.za>
Message-ID: <1276817042.79.0.273704225287.issue6543@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I tested the last patch on Windows: it does fix the bug, the traceback is displayed correctly in my terminal charset (cp850).

I commited the fix to Python 3.1 (r82063) and 3.2 (r82059+r82061).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6543>
_______________________________________

From report at bugs.python.org  Fri Jun 18 01:25:22 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 17 Jun 2010 23:25:22 +0000
Subject: [issue8362] Add Misc/maintainers.rst to 2.x branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1276817122.43.0.831611111856.issue8362@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Just stumbled upon this stuff. Good job. I can already see how it can be useful.

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8362>
_______________________________________

From report at bugs.python.org  Fri Jun 18 01:54:04 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 17 Jun 2010 23:54:04 +0000
Subject: [issue8937] SimpleHTTPServer should contain usage example
In-Reply-To: <1275975534.8.0.563527396515.issue8937@psf.upfronthosting.co.za>
Message-ID: <1276818844.21.0.930516898599.issue8937@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

And I am not RDM. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8937>
_______________________________________

From report at bugs.python.org  Fri Jun 18 01:57:08 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 17 Jun 2010 23:57:08 +0000
Subject: [issue9021] no copy.copy problem description
In-Reply-To: <1276816713.34.0.416523004663.issue9021@psf.upfronthosting.co.za>
Message-ID: <1276819028.13.0.376253029057.issue9021@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/issue9021>
_______________________________________

From report at bugs.python.org  Fri Jun 18 01:59:17 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 17 Jun 2010 23:59:17 +0000
Subject: [issue3687] Popen() object stdout attribute reassignment behaviour
In-Reply-To: <1219766265.83.0.904411616188.issue3687@psf.upfronthosting.co.za>
Message-ID: <1276819157.32.0.666877081822.issue3687@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/issue3687>
_______________________________________

From report at bugs.python.org  Fri Jun 18 02:03:26 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 18 Jun 2010 00:03:26 +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: <1276819406.93.0.930221148628.issue1452@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/issue1452>
_______________________________________

From report at bugs.python.org  Fri Jun 18 02:14:23 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 18 Jun 2010 00:14:23 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1276820063.86.0.146687611555.issue1731717@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/issue1731717>
_______________________________________

From report at bugs.python.org  Fri Jun 18 02:25:47 2010
From: report at bugs.python.org (David)
Date: Fri, 18 Jun 2010 00:25:47 +0000
Subject: [issue9022] TypeError in wsgiref.handlers when using CGIHandler
In-Reply-To: <1276820747.2.0.467969862682.issue9022@psf.upfronthosting.co.za>
Message-ID: <1276820747.2.0.467969862682.issue9022@psf.upfronthosting.co.za>


New submission from David <toxicdav3 at gmail.com>:

The following code produces a type error, but from what I can tell it does comply with PEP333. This issue appeared using Python 3.1.1 and 3.1.2 on both Windows and Ubuntu. I have only tried the 32 bit versions. Works fine in Python 2.6.5.12 but I guess thats irrelevant.

-----
def application(environ, start_response):
	start_response('200 OK',[('Content-type','text/html')])
	return ['<html><body>Hello World!</body></html>']
	
from wsgiref.handlers import CGIHandler
CGIHandler().run(application)
-----
Traceback (most recent call last):
  File "C:\Python31\lib\wsgiref\handlers.py", line 75, in run
    self.finish_response()
  File "C:\Python31\lib\wsgiref\handlers.py", line 116, in finish_response
    self.write(data)
  File "C:\Python31\lib\wsgiref\handlers.py", line 210, in write
    self.send_headers()
  File "C:\Python31\lib\wsgiref\handlers.py", line 266, in send_headers
    self.send_preamble()
  File "C:\Python31\lib\wsgiref\handlers.py", line 196, in send_preamble
    self._write('Status: %s\r\n' % self.status)
  File "C:\Python31\lib\wsgiref\handlers.py", line 402, in _write
    self.stdout.write(data)
TypeError: must be str, not bytes
-----

----------
components: Library (Lib)
messages: 108073
nosy: toxicdav3
priority: normal
severity: normal
status: open
title: TypeError in wsgiref.handlers when using CGIHandler
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9022>
_______________________________________

From report at bugs.python.org  Fri Jun 18 03:31:48 2010
From: report at bugs.python.org (Hari Krishna Dara)
Date: Fri, 18 Jun 2010 01:31:48 +0000
Subject: [issue6966] Ability to refer to arguments in TestCase.fail* methods
In-Reply-To: <1253611687.96.0.247846871836.issue6966@psf.upfronthosting.co.za>
Message-ID: <1276824708.08.0.590522106404.issue6966@psf.upfronthosting.co.za>


Changes by Hari Krishna Dara <haridara at gmail.com>:


----------
nosy: +haridsv

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6966>
_______________________________________

From report at bugs.python.org  Fri Jun 18 03:43:09 2010
From: report at bugs.python.org (Hari Krishna Dara)
Date: Fri, 18 Jun 2010 01:43:09 +0000
Subject: [issue6966] Ability to refer to arguments in TestCase.fail* methods
In-Reply-To: <1253611687.96.0.247846871836.issue6966@psf.upfronthosting.co.za>
Message-ID: <1276825389.45.0.946851207178.issue6966@psf.upfronthosting.co.za>


Hari Krishna Dara <haridara at gmail.com> added the comment:

Changing unittest.TestCase.failUnlessEqual() to something like this will be very useful:


    def failUnlessEqual(self, first, second, msg=None):
        """Fail if the two objects are unequal as determined by the '=='
           operator. Argument msg could optionally include string format
           operators named "lhs" and "rhs" (e.g., "%(lhs)r")
        """
        if not first == second:
            raise self.failureException, \
                  (msg or "%(lhs)r != %(rhs)r") % dict(lhs=10, rhs=20)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6966>
_______________________________________

From report at bugs.python.org  Fri Jun 18 03:44:37 2010
From: report at bugs.python.org (Hari Krishna Dara)
Date: Fri, 18 Jun 2010 01:44:37 +0000
Subject: [issue6966] Ability to refer to arguments in TestCase.fail* methods
In-Reply-To: <1253611687.96.0.247846871836.issue6966@psf.upfronthosting.co.za>
Message-ID: <1276825477.12.0.951688242432.issue6966@psf.upfronthosting.co.za>


Hari Krishna Dara <haridara at gmail.com> added the comment:

Oops... the dict part should have been "dict(lhs=first, rhs=second)":

    def failUnlessEqual(self, first, second, msg=None):
        """Fail if the two objects are unequal as determined by the '=='
           operator. Argument msg could optionally include string format
           operators named "lhs" and "rhs" (e.g., "%(lhs)r")
        """
        if not first == second:
            raise self.failureException, \
                  (msg or "%(lhs)r != %(rhs)r") % dict(lhs=first, rhs=second)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6966>
_______________________________________

From report at bugs.python.org  Fri Jun 18 05:01:40 2010
From: report at bugs.python.org (Heikki Toivonen)
Date: Fri, 18 Jun 2010 03:01:40 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1276830100.14.0.212836058317.issue8998@psf.upfronthosting.co.za>


Heikki Toivonen <hjtoi-bugzilla at comcast.net> added the comment:

More or less random opinions on things presented before:

 * I prefer having secure defaults to over documentation, because, well, people don't read documentation.
 * If not secure defaults, then pointing out in documentation the secure way AND providing examples that always show the secure way of doing things.
 * I can't comment on aes 192 vs 256 as I have not really kept up with that, but it would be good to ask the opinion(s) of the real experts in this field before choosing the defaults/recommending them. Of course, if you can point to an article where the experts already voice their (recent) recommendations, fine.
 * When I have thought about Python crypto in the stdlib, I've considered modeling it after hashlib, so you would get cipher = cryptolib.AES(bits=192, ...) etc. (Caveat: haven't thought it through.)
 * I'd prefer if the crypto API didn't become OpenSSL specific (like the SSL one is), which would theoretically allow switching in other crypto provider(s).
 * The library should make it easy to do the most common operations with as few steps as practically possible.
 * It would be nice if the library could provide the means to tweak lower level things if you needed to. Unfortunately this has a tendency to get messy quick, because crypto stuff tends to have lots of options to tweak.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Fri Jun 18 05:49:31 2010
From: report at bugs.python.org (geremy condra)
Date: Fri, 18 Jun 2010 03:49:31 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276830100.14.0.212836058317.issue8998@psf.upfronthosting.co.za>
Message-ID: <AANLkTin6oIbeFNFeOO6q30fFQhMRrrzjb1BjcFKlL1Sn@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Thu, Jun 17, 2010 at 8:01 PM, Heikki Toivonen <report at bugs.python.org> wrote:
>
> Heikki Toivonen <hjtoi-bugzilla at comcast.net> added the comment:
>
> More or less random opinions on things presented before:
>
> ?* I prefer having secure defaults to over documentation, because, well, people don't read documentation.

Wholeheartedly agree.

> ?* If not secure defaults, then pointing out in documentation the secure way AND providing examples that always show the secure way of doing things.

Not as big a fan, honestly. Most domain-specific projects can count on
those reading the documentation to have a good idea of what it is that
they actually want to do; in crypto this does not seem to be the case
very often, and that's a tricky problem to fix that in the scope of a
recipe or piece of documentation.

> ?* I can't comment on aes 192 vs 256 as I have not really kept up with that, but it would be good to ask the opinion(s) of the real experts in this field before choosing the defaults/recommending them. Of course, if you can point to an article where the experts already voice their (recent) recommendations, fine.

http://eprint.iacr.org/2009/317.pdf
http://eprint.iacr.org/2009/374.pdf
http://eprint.iacr.org/2009/241.pdf

Bruce Schneier's take:
http://www.schneier.com/blog/archives/2009/07/another_new_aes.html

The only cryptosystem/padding/etc choice in evpy I'm uncomfortable
with (at the moment ;) ) is the use of ad-hoc padding rather than
OAEP, and I only do that because that's what evp does. Of course, if
you have any other concerns I'd appreciate hearing about them.

> ?* When I have thought about Python crypto in the stdlib, I've considered modeling it after hashlib, so you would get cipher = cryptolib.AES(bits=192, ...) etc. (Caveat: haven't thought it through.)

I'm not opposed to this, but I suspect that focusing on what the
algorithms are for rather than what they are reduces the cognitive
load somewhat. Perhaps a two-tier api?

> ?* I'd prefer if the crypto API didn't become OpenSSL specific (like the SSL one is), which would theoretically allow switching in other crypto provider(s).

I agree in theory, although I'm not sure how important this is likely
to be in practice.

> ?* The library should make it easy to do the most common operations with as few steps as practically possible.
> ?* It would be nice if the library could provide the means to tweak lower level things if you needed to. Unfortunately this has a tendency to get messy quick, because crypto stuff tends to have lots of options to tweak.

100% agree. If you have any ideas- or if anyone else does- on how best
to do this, I'd be very happy to discuss it.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Fri Jun 18 08:19:15 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 18 Jun 2010 06:19:15 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <AANLkTin6oIbeFNFeOO6q30fFQhMRrrzjb1BjcFKlL1Sn@mail.gmail.com>
Message-ID: <4C1B0FDF.2050909@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>>   * I'd prefer if the crypto API didn't become OpenSSL specific (like the SSL one is), which would theoretically allow switching in other crypto provider(s).
>
> I agree in theory, although I'm not sure how important this is likely
> to be in practice.

I always wanted to drop OpenSSL from the Windows binaries, and use MS 
CryptoAPI instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Fri Jun 18 08:39:21 2010
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 18 Jun 2010 06:39:21 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1276843161.23.0.47658836964.issue8998@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

>  * When I have thought about Python crypto in the stdlib, I've considered modeling it after hashlib, so you would get cipher = cryptolib.AES(bits=192, ...) etc. (Caveat: haven't thought it through.)

I think there is a relevant PEP: PEP 272 -- API for Block Encryption Algorithms v1.0 (http://www.python.org/dev/peps/pep-0272/ )
It describes an API somewhat similar to hashlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Fri Jun 18 08:44:23 2010
From: report at bugs.python.org (geremy condra)
Date: Fri, 18 Jun 2010 06:44:23 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <4C1B0FDF.2050909@v.loewis.de>
Message-ID: <AANLkTinlDUJT8op3qlN0NgolxMn_aT9HNnMcD3pM4j2J@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Fri, Jun 18, 2010 at 2:19 AM, Martin v. L?wis <report at bugs.python.org> wrote:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
>>> ? * I'd prefer if the crypto API didn't become OpenSSL specific (like the SSL one is), which would theoretically allow switching in other crypto provider(s).
>>
>> I agree in theory, although I'm not sure how important this is likely
>> to be in practice.
>
> I always wanted to drop OpenSSL from the Windows binaries, and use MS
> CryptoAPI instead.

My familiarity with the CryptoAPI is limited, but I think doing this
for something like evpy would be possible. I also suspect that doing
it for anything that exposed much more than evpy does would grow very
quickly in complexity where it was possible at all.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Fri Jun 18 08:46:51 2010
From: report at bugs.python.org (geremy condra)
Date: Fri, 18 Jun 2010 06:46:51 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276843161.23.0.47658836964.issue8998@psf.upfronthosting.co.za>
Message-ID: <AANLkTimiwnwxDtcUddKfWClCX7AFuzE4eUuBhIXRgLGE@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Fri, Jun 18, 2010 at 2:39 AM, Daniel Urban <report at bugs.python.org> wrote:
>
> Daniel Urban <urban.dani+py at gmail.com> added the comment:
>
>> ?* When I have thought about Python crypto in the stdlib, I've considered modeling it after hashlib, so you would get cipher = cryptolib.AES(bits=192, ...) etc. (Caveat: haven't thought it through.)
>
> I think there is a relevant PEP: PEP 272 -- API for Block Encryption Algorithms v1.0 (http://www.python.org/dev/peps/pep-0272/ )
> It describes an API somewhat similar to hashlib.

Again, I'm not entirely opposed to this, but I think it represents a
lower-level API than most developers can really be safely trusted to
handle.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Fri Jun 18 09:09:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Jun 2010 07:09:04 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <AANLkTimiwnwxDtcUddKfWClCX7AFuzE4eUuBhIXRgLGE@mail.gmail.com>
Message-ID: <1276844940.3338.11.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le vendredi 18 juin 2010 ? 06:46 +0000, geremy condra a ?crit :
> geremy condra <debatem1 at gmail.com> added the comment:
> 
> On Fri, Jun 18, 2010 at 2:39 AM, Daniel Urban <report at bugs.python.org> wrote:
> >
> > Daniel Urban <urban.dani+py at gmail.com> added the comment:
> >
> >>  * When I have thought about Python crypto in the stdlib, I've considered modeling it after hashlib, so you would get cipher = cryptolib.AES(bits=192, ...) etc. (Caveat: haven't thought it through.)
> >
> > I think there is a relevant PEP: PEP 272 -- API for Block Encryption Algorithms v1.0 (http://www.python.org/dev/peps/pep-0272/ )
> > It describes an API somewhat similar to hashlib.
> 
> Again, I'm not entirely opposed to this, but I think it represents a
> lower-level API than most developers can really be safely trusted to
> handle.

If there is a contention or disagreement between different API styles,
it may be wise to seek opinions on python-dev or python-ideas.

I'd point out that the "ssl" module itself seems to have evolved from a
trivial wrapper API (in the 2.5 docs I can only find a single
3-parameter function, socket.ssl()) to a more comprehensive API in 3.2,
because people ultimately need the functionalities.
(and yet the ssl API in 3.2 is still much less featureful than M2Crypto
or pyOpenSSL are)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Fri Jun 18 09:20:26 2010
From: report at bugs.python.org (geremy condra)
Date: Fri, 18 Jun 2010 07:20:26 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276844940.3338.11.camel@localhost.localdomain>
Message-ID: <AANLkTimm_baro-1XAT8Y05CLOL1quQ1y79zpa_XqtOlZ@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Fri, Jun 18, 2010 at 3:09 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Le vendredi 18 juin 2010 ? 06:46 +0000, geremy condra a ?crit :
>> geremy condra <debatem1 at gmail.com> added the comment:
>>
>> On Fri, Jun 18, 2010 at 2:39 AM, Daniel Urban <report at bugs.python.org> wrote:
>> >
>> > Daniel Urban <urban.dani+py at gmail.com> added the comment:
>> >
>> >> ?* When I have thought about Python crypto in the stdlib, I've considered modeling it after hashlib, so you would get cipher = cryptolib.AES(bits=192, ...) etc. (Caveat: haven't thought it through.)
>> >
>> > I think there is a relevant PEP: PEP 272 -- API for Block Encryption Algorithms v1.0 (http://www.python.org/dev/peps/pep-0272/ )
>> > It describes an API somewhat similar to hashlib.
>>
>> Again, I'm not entirely opposed to this, but I think it represents a
>> lower-level API than most developers can really be safely trusted to
>> handle.
>
> If there is a contention or disagreement between different API styles,
> it may be wise to seek opinions on python-dev or python-ideas.

I'm not sure there's a disagreement here except what the top-level API
should be. If someone is really determined to use the lower-level API
I have no issue with it, and (within the bounds of time and ability)
am willing to write the code to support it.

> I'd point out that the "ssl" module itself seems to have evolved from a
> trivial wrapper API (in the 2.5 docs I can only find a single
> 3-parameter function, socket.ssl()) to a more comprehensive API in 3.2,
> because people ultimately need the functionalities.
> (and yet the ssl API in 3.2 is still much less featureful than M2Crypto
> or pyOpenSSL are)

I'm not sure I'm understanding what you mean. Are you saying it should
start as a comprehensive wrapper because that's what ssl is headed
towards or that it should start simply because such functionality will
evolve organically as the need arises?

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Fri Jun 18 09:28:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Jun 2010 07:28:00 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <AANLkTimm_baro-1XAT8Y05CLOL1quQ1y79zpa_XqtOlZ@mail.gmail.com>
Message-ID: <1276846075.3338.18.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > I'd point out that the "ssl" module itself seems to have evolved from a
> > trivial wrapper API (in the 2.5 docs I can only find a single
> > 3-parameter function, socket.ssl()) to a more comprehensive API in 3.2,
> > because people ultimately need the functionalities.
> > (and yet the ssl API in 3.2 is still much less featureful than M2Crypto
> > or pyOpenSSL are)
> 
> I'm not sure I'm understanding what you mean. Are you saying it should
> start as a comprehensive wrapper because that's what ssl is headed
> towards or that it should start simply because such functionality will
> evolve organically as the need arises?

The former. Evolving organically has quite a few issues, because the
original API may be far from ideal to build on, and yet you have to
ensure compatibility with that API.
("comprehensive" doesn't have to equate "exhaustive" of course. But any
API which tries to simplify things too much might also be a roadblock
when it comes to exposing more features)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Fri Jun 18 10:47:31 2010
From: report at bugs.python.org (Greg Hazel)
Date: Fri, 18 Jun 2010 08:47:31 +0000
Subject: [issue9023] distutils relative path errors
In-Reply-To: <1276850851.53.0.471987336824.issue9023@psf.upfronthosting.co.za>
Message-ID: <1276850851.53.0.471987336824.issue9023@psf.upfronthosting.co.za>


New submission from Greg Hazel <ghazel at users.sourceforge.net>:

Probably applies to more versions, but I only tested on 2.5.2 and 2.6.5.

Distutils incorrectly constructs paths for the build/temp directory when relative paths are used in the "sources" list. This can result in failing to make the build/temp directory at all, and placing files in outside of the build/temp directory.

Consider the following example:

gah at duma:~$ mkdir libfoo
gah at duma:~$ cd libfoo
gah at duma:~/libfoo$ echo > foo.c
gah at duma:~/libfoo$ mkdir pyfoo
gah at duma:~/libfoo$ cd pyfoo
gah at duma:~/libfoo/pyfoo$ echo "from setuptools import setup, Library; setup(name='foo', ext_modules=[Library(name='foo',sources=['../foo.c'])])" > setup.py
gah at duma:~/libfoo/pyfoo$ python setup.py build
running build
running build_ext
building 'foo' extension
creating build
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.5 -c ../foo.c -o build/temp.linux-i686-2.5/../foo.o
Assembler messages:
Fatal error: can't create build/temp.linux-i686-2.5/../foo.o: No such file or directory
error: command 'gcc' failed with exit status 1


Using os.path.abspath('../foo.c') in the sources causes distutils to create build/temp.linux-i686-2.5/home/gah/libfoo/foo.o which is fine. However as a user, this situation is quite surprising, since distutils is responsible for managing the build and temp directories itself.

----------
assignee: tarek
components: Distutils
messages: 108085
nosy: ghazel, tarek
priority: normal
severity: normal
status: open
title: distutils relative path errors
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9023>
_______________________________________

From report at bugs.python.org  Fri Jun 18 10:48:49 2010
From: report at bugs.python.org (Tim Golden)
Date: Fri, 18 Jun 2010 08:48:49 +0000
Subject: [issue9024] PyDateTime_IMPORT macro incorrectly marked up
In-Reply-To: <4C1B32EB.6020900@timgolden.me.uk>
Message-ID: <4C1B32EB.6020900@timgolden.me.uk>


New submission from Tim Golden <mail at timgolden.me.uk>:

The reference to PyDateTime_IMPORT in the C API datetime docs is marked 
up as cfunction, giving it a pair of brackets which render it invalid. 
There is also no indication of where in the code it should be invoked. 
Patch attached.

----------
files: pydatetime_import.patch
keywords: patch
messages: 108086
nosy: tim.golden
priority: normal
severity: normal
status: open
title: PyDateTime_IMPORT macro incorrectly marked up
Added file: http://bugs.python.org/file17703/pydatetime_import.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9024>
_______________________________________
-------------- next part --------------
Index: c-api/datetime.rst
===================================================================
--- c-api/datetime.rst	(revision 82013)
+++ c-api/datetime.rst	(working copy)
@@ -8,9 +8,9 @@
 Various date and time objects are supplied by the :mod:`datetime` module.
 Before using any of these functions, the header file :file:`datetime.h` must be
 included in your source (note that this is not included by :file:`Python.h`),
-and the macro :cfunc:`PyDateTime_IMPORT` must be invoked.  The macro puts a
-pointer to a C structure into a static variable,  ``PyDateTimeAPI``, that is
-used by the following macros.
+and the macro :cmacro:`PyDateTime_IMPORT` must be invoked, usually as part of
+the module initialisation function.  The macro puts a pointer to a C structure
+into a static variable,  ``PyDateTimeAPI``, that is used by the following macros.
 
 Type-check macros:
 

From report at bugs.python.org  Fri Jun 18 10:50:29 2010
From: report at bugs.python.org (geremy condra)
Date: Fri, 18 Jun 2010 08:50:29 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276846075.3338.18.camel@localhost.localdomain>
Message-ID: <AANLkTikZX5q9J2r9slfMz8mc45GLj1AeVcqpEXz37qw7@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Fri, Jun 18, 2010 at 3:28 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> > I'd point out that the "ssl" module itself seems to have evolved from a
>> > trivial wrapper API (in the 2.5 docs I can only find a single
>> > 3-parameter function, socket.ssl()) to a more comprehensive API in 3.2,
>> > because people ultimately need the functionalities.
>> > (and yet the ssl API in 3.2 is still much less featureful than M2Crypto
>> > or pyOpenSSL are)
>>
>> I'm not sure I'm understanding what you mean. Are you saying it should
>> start as a comprehensive wrapper because that's what ssl is headed
>> towards or that it should start simply because such functionality will
>> evolve organically as the need arises?
>
> The former. Evolving organically has quite a few issues, because the
> original API may be far from ideal to build on, and yet you have to
> ensure compatibility with that API.
> ("comprehensive" doesn't have to equate "exhaustive" of course. But any
> API which tries to simplify things too much might also be a roadblock
> when it comes to exposing more features)

Well, like I say, I'm willing to contribute what time and ability
allow. Are you thinking of adding a comprehensive wrapper to the ssl
module?

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Fri Jun 18 10:53:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Jun 2010 08:53:49 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <AANLkTikZX5q9J2r9slfMz8mc45GLj1AeVcqpEXz37qw7@mail.gmail.com>
Message-ID: <1276851225.3338.20.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Well, like I say, I'm willing to contribute what time and ability
> allow. Are you thinking of adding a comprehensive wrapper to the ssl
> module?

Hmm, no, I was just providing an existing datapoint to help us deciding
on a crypto API.  AFAICT this issue hasn't much to do with the ssl
module, except perhaps for (positive or negative) inspiration ;-)
(and except that it will also - most likely - interface with OpenSSL)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Fri Jun 18 10:54:52 2010
From: report at bugs.python.org (Tim Golden)
Date: Fri, 18 Jun 2010 08:54:52 +0000
Subject: [issue9024] PyDateTime_IMPORT macro incorrectly marked up
In-Reply-To: <4C1B32EB.6020900@timgolden.me.uk>
Message-ID: <1276851292.96.0.344151555397.issue9024@psf.upfronthosting.co.za>


Changes by Tim Golden <mail at timgolden.me.uk>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> patch review
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9024>
_______________________________________

From report at bugs.python.org  Fri Jun 18 11:16:25 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 18 Jun 2010 09:16:25 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276852585.3.0.462870985215.issue7989@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

>> One, we should not blindly pull in the PyPy code
>> without some core PyPy developer being in on this

You can count me among the PyPy developers.

> I concur.  Much of PyPy code is written for a restricted subset of
> Python instead of clean, idiomatic modern Python.

Not this part. The module datetime.py is meant to be imported by the interpreter, and has no limitation (we call it "application-level" code, opposed to interpreter-level code which is translated to C and which indeed has serious constraints)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Fri Jun 18 11:18:31 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 18 Jun 2010 09:18:31 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276852711.88.0.637032826715.issue7989@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

If both implementations can exist in the same interpreter, how will they cooperate?
For example, Time instances created with datetime.py won't pass PyTime_Check().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Fri Jun 18 11:25:30 2010
From: report at bugs.python.org (geremy condra)
Date: Fri, 18 Jun 2010 09:25:30 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276851225.3338.20.camel@localhost.localdomain>
Message-ID: <AANLkTikDzsT12AbUb7zaQilonFofzqNqYQEsDQr8MtBO@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Fri, Jun 18, 2010 at 4:53 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> Well, like I say, I'm willing to contribute what time and ability
>> allow. Are you thinking of adding a comprehensive wrapper to the ssl
>> module?
>
> Hmm, no, I was just providing an existing datapoint to help us deciding
> on a crypto API. ?AFAICT this issue hasn't much to do with the ssl
> module, except perhaps for (positive or negative) inspiration ;-)
> (and except that it will also - most likely - interface with OpenSSL)

The question in my mind then is whether anybody willing to contribute
time knows enough about the CryptoAPI, or NSS, or what-have-you, to
help craft an API that makes the waterfall model look manageable. If
not, I would suggest that we focus on defining and building a
lower-level interface along the lines of the PEP noted earlier,
integrating that with evpy, and getting it in shape to go into the
stdlib. At that point, if demand arises for an even lower level API,
we already have the wrapping functions for a lot of the calls into
OpenSSL or whatever, and we can build on those in the aforementioned
evolutionary fashion. If somebody does, then perhaps a four-tiered
model makes more sense, with the bottom one being the raw wrappers
around the various libs, the second from the bottom being
compatibility shims, and the top two matching the other proposal.
Having said that, it's not something I could take on alone.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Fri Jun 18 11:37:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Jun 2010 09:37:31 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <AANLkTikDzsT12AbUb7zaQilonFofzqNqYQEsDQr8MtBO@mail.gmail.com>
Message-ID: <1276853848.3338.22.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I would suggest that we focus on defining and building a
> lower-level interface along the lines of the PEP noted earlier,
> integrating that with evpy, and getting it in shape to go into the
> stdlib.

That sounds reasonable to me.
(although I would be also content with the lower-level interface
alone :-))

> If somebody does, then perhaps a four-tiered
> model makes more sense, with the bottom one being the raw wrappers
> around the various libs, the second from the bottom being
> compatibility shims, and the top two matching the other proposal.

That sounds much too complicated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Fri Jun 18 11:57:36 2010
From: report at bugs.python.org (geremy condra)
Date: Fri, 18 Jun 2010 09:57:36 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276853848.3338.22.camel@localhost.localdomain>
Message-ID: <AANLkTilOF8lK7n-Cj2_pZc74d62OijavVWbx2vuZe3oY@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Fri, Jun 18, 2010 at 5:37 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> I would suggest that we focus on defining and building a
>> lower-level interface along the lines of the PEP noted earlier,
>> integrating that with evpy, and getting it in shape to go into the
>> stdlib.
>
> That sounds reasonable to me.

Great, I'm thinking more-or-less the API proposed in PEP 272- the
exception I'm thinking of is that 'strings' should be substituted for
'bytes'- for AES and DES. It gets trickier when talking about public
key crypto, though. Perhaps something along the lines of
RSA.new(public_key=None, private_key=None,...), with the resulting
object supporting encrypt/decrypt/sign/verify operations?

> (although I would be also content with the lower-level interface
> alone :-))

>> If somebody does, then perhaps a four-tiered
>> model makes more sense, with the bottom one being the raw wrappers
>> around the various libs, the second from the bottom being
>> compatibility shims, and the top two matching the other proposal.
>
> That sounds much too complicated.

If we're likely to have openssl taken out from under us it could save
us a lot of hassle to plan for that up front. If not, then why worry,
and ISTM we should go the simpler route.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Fri Jun 18 12:05:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Jun 2010 10:05:20 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <AANLkTilOF8lK7n-Cj2_pZc74d62OijavVWbx2vuZe3oY@mail.gmail.com>
Message-ID: <1276855514.3338.26.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Great, I'm thinking more-or-less the API proposed in PEP 272- the
> exception I'm thinking of is that 'strings' should be substituted for
> 'bytes'- for AES and DES. It gets trickier when talking about public
> key crypto, though. Perhaps something along the lines of
> RSA.new(public_key=None, private_key=None,...), with the resulting
> object supporting encrypt/decrypt/sign/verify operations?

I don't have any opinion right now. I think a concrete proposal should
be initiated and we can iterate from that.
(that's assuming other people agree on the principle, of course)

> If we're likely to have openssl taken out from under us it could save
> us a lot of hassle to plan for that up front.

It doesn't seem very likely in the middle term. In particular, the ssl
module itself is quite tied to OpenSSL's socket wrapping semantics
(including error codes and non-blocking behaviour), so OpenSSL will
probably still be required for SSL sockets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Fri Jun 18 12:20:52 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Jun 2010 10:20:52 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Not a serious bug, but worth noting:

The result of randrange(n) is not even close to uniform for large n.  Witness the obvious skew in the following (this takes a minute or two to run, so you might want to reduce the range argument):

Python 3.2a0 (py3k:81980, Jun 14 2010, 11:23:36)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from random import randrange
>>> from collections import Counter
>>> Counter(randrange(6755399441055744) % 3 for _ in range(100000000))
Counter({1: 37508130, 0: 33323818, 2: 29168052})

(The actual probabilities here are, as you might guess from the above numbers:  {0: 1/3, 1: 3/8, 2: 7/24}.)

The cause:  for n < 2**53, randrange(n) is effectively computed as int(random() * n).  For small n, there's a tiny bias involved, but this is still an effective method.  However, as n increases towards 2**53, the bias increases significantly.  (For n >= 2**53, the random module uses a different strategy that *does* produce uniformly distributed results.)

A solution would be to lower the cutoff point where randrange() switches from using int(random() * n) to using the _randbelow method.

----------
components: Library (Lib)
messages: 108095
nosy: mark.dickinson, rhettinger
priority: low
severity: normal
status: open
title: Non-uniformity in randrange for large arguments.
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Fri Jun 18 12:24:39 2010
From: report at bugs.python.org (Javier)
Date: Fri, 18 Jun 2010 10:24:39 +0000
Subject: [issue9026] [argparse] Subcommands not printed in the same order they
	were added
In-Reply-To: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za>
Message-ID: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za>


New submission from Javier <javier.collado at gmail.com>:

What steps will reproduce the problem?
1. Run 'python subcommands.py -h' (attached file)
2. Check the ordering of the subcommands in the output:
----
subcommands:
  {a,c,b,e,d}
    a          a subcommand help
    b          b subcommand help
    c          c subcommand help
    d          d subcommand help
    e          e subcommand help
----

The ordering between brackets is different than the ordering in the one-line help for each command below. This could be a little confusing to the user.


What is the expected output? What do you see instead?
The expected output would be to use the same ordering in both places. In particular the same ordering that was used in the code when using the _SubParsersAction.add_parser method:
----
subcommands:
  {a,b,c,d,e}
    a          a subcommand help
    b          b subcommand help
    c          c subcommand help
    d          d subcommand help
    e          e subcommand help
----


What version of the product are you using? On what operating system?
OS: Ubuntu
Version: source code (rev. 87)
Python: 2.6.5

Please provide any additional information below.
Please have a look at the attached diff. It contains a patch that worked for me to preserve the ordering used in the code.

To make that possible it uses action._choices_actions (a list) instead of action.choices (a dictionary).

----------
components: Library (Lib)
files: subcommands.py
messages: 108096
nosy: jcollado
priority: normal
severity: normal
status: open
title: [argparse] Subcommands not printed in the same order they were added
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17704/subcommands.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9026>
_______________________________________

From report at bugs.python.org  Fri Jun 18 12:24:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Jun 2010 10:24:56 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1276856696.48.0.796055863646.issue9025@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Note: the number 6755399441055744 is special:  it's 0.75 * 2**53, and was deliberately chosen so that the non-uniformity is easily exhibited by looking at residues modulo 3.  For other numbers of this size, the non-uniformity is just as bad, but demonstrating the non-uniformity clearly would have taken a little more work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Fri Jun 18 12:26:26 2010
From: report at bugs.python.org (Javier)
Date: Fri, 18 Jun 2010 10:26:26 +0000
Subject: [issue9026] [argparse] Subcommands not printed in the same order they
	were added
In-Reply-To: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za>
Message-ID: <1276856786.43.0.952229974027.issue9026@psf.upfronthosting.co.za>


Javier <javier.collado at gmail.com> added the comment:

It contains a patch that worked for me to preserve the ordering used in the code.

To make that possible it uses action._choices_actions (a list) instead of action.choices (a dictionary).

----------
keywords: +patch
Added file: http://bugs.python.org/file17705/ordered_subcommands.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9026>
_______________________________________

From report at bugs.python.org  Fri Jun 18 13:16:51 2010
From: report at bugs.python.org (Chris Withers)
Date: Fri, 18 Jun 2010 11:16:51 +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: <1276859811.26.0.22626852898.issue6884@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

I guess not... Maybe try catching Tarek on irc or drop him a mail?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Fri Jun 18 13:32:55 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 18 Jun 2010 11:32:55 +0000
Subject: [issue9026] [argparse] Subcommands not printed in the same order they
	were added
In-Reply-To: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za>
Message-ID: <1276860775.97.0.771163772408.issue9026@psf.upfronthosting.co.za>


Changes by Steven Bethard <steven.bethard at gmail.com>:


----------
assignee:  -> bethard
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9026>
_______________________________________

From report at bugs.python.org  Fri Jun 18 14:20:15 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 18 Jun 2010 12:20:15 +0000
Subject: [issue9027] add test_support.run_unittest command line options and
	arguments
In-Reply-To: <1276863615.44.0.266652400766.issue9027@psf.upfronthosting.co.za>
Message-ID: <1276863615.44.0.266652400766.issue9027@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Need --help, --list options and TestSute.testcase args for test_support.run_unittest


User story:
I am covering CGIHTTPServer with tests according to http://www.rfc-editor.org/rfc/rfc3875.txt speccy and want to run a single test in a cycle. I am running test cases like:

> python test_httpservers.py

I want to get all available tests in file and execute only the one I need, but test_support.run_unittest doesn't accept any params.

> python test_httpservers.py --help

just runs the test.


I propose to:

1. add list option
-l, --list    list the names of test to be executed and exit
example:
> python test_httpservers.py --list
BaseHTTPServer::command
BaseHTTPServer::handler

I omit `test_` prefix and `TestCase` suffixes as they don't bear any value and just clutter the console. This is my idealistic view.

2. add arguments of test names with wildcards
> python test_httpservers.py --list BaseHTTP*
BaseHTTPServer::command
BaseHTTPServer::handler
> python test_httpservers.py --list *auth*
BaseHTTPServer::handler

----------
components: Tests
messages: 108100
nosy: techtonik
priority: normal
severity: normal
status: open
title: add test_support.run_unittest command line options and arguments
versions: Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9027>
_______________________________________

From report at bugs.python.org  Fri Jun 18 14:22:12 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Jun 2010 12:22:12 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1276863732.9.0.202368142527.issue9025@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's an example patch that removes any bias from randrange(n) (except for bias resulting from the imperfectness of the core MT generator).  I added a small private method to Modules/_randommodule.c to aid the computation.

This only fixes one instance of int(random() * n) in the Lib/random.py source;  the other instances should be modified accordingly.

With this patch, randrange is a touch faster than before (20-30% speedup) for small arguments.

Is this worth pursuing?

----------
keywords: +patch
Added file: http://bugs.python.org/file17706/issue9025.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Fri Jun 18 14:23:23 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 18 Jun 2010 12:23:23 +0000
Subject: [issue9027] add test_support.run_unittest command line options and
	arguments
In-Reply-To: <1276863615.44.0.266652400766.issue9027@psf.upfronthosting.co.za>
Message-ID: <1276863803.96.0.59113281222.issue9027@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

3. The final goal is to be able to run single test as:

> python test_httpservers.py BaseHTTPServer::handler

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9027>
_______________________________________

From report at bugs.python.org  Fri Jun 18 14:55:33 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 18 Jun 2010 12:55:33 +0000
Subject: [issue9027] add test_support.run_unittest command line options and
	arguments
In-Reply-To: <1276863615.44.0.266652400766.issue9027@psf.upfronthosting.co.za>
Message-ID: <1276865733.63.0.863496209141.issue9027@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

The example in first post should read:

> python test_httpservers.py --list *auth*
CGIHTTPServerTestCase::authorization

(several distractions a minute can drive anyone mad)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9027>
_______________________________________

From report at bugs.python.org  Fri Jun 18 15:03:44 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 18 Jun 2010 13:03:44 +0000
Subject: [issue9028] test_support.run_unittest cmdline options and arguments
In-Reply-To: <1276866224.2.0.777930943128.issue9028@psf.upfronthosting.co.za>
Message-ID: <1276866224.2.0.777930943128.issue9028@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Need --help, --list options and TestSute::testcase args for test_support.run_unittest


User story:
I am covering CGIHTTPServer with tests according to http://www.rfc-editor.org/rfc/rfc3875.txt speccy and want to run a single test in a cycle. I am running test cases like:

> python test_httpservers.py

I want to get all available tests in file and execute only the one, but test_support.run_unittest doesn't accept any params.

> python test_httpservers.py --help

just runs all the tests.


I propose to:

1. add list option
-l, --list    list the names of test to be executed and exit

> python test_httpservers.py --list
BaseHTTPServer::command
BaseHTTPServer::handler
CGIHTTPServerTestCase::authorization

I omit `test_` prefix and `TestCase` suffixes as they don't hold any value and just clutter the console. My idealistic vision thinks it is better this way.

2. add arguments of test names with wildcards
> python test_httpservers.py --list BaseHTTP*
BaseHTTPServer::command
BaseHTTPServer::handler
> python test_httpservers.py --list *auth*
CGIHTTPServerTestCase::authorization

3. The final goal is to be able to run single test as:
> python test_httpservers.py BaseHTTPServer::handler
CGIHTTPServer::url_collapse_path_split ... ok

This format will allow to copy/paste single test name for easy execution, which is impossible with current format:
test_url_collapse_path_split (__main__.CGIHTTPServerTestCase) ... ok


One step to make stdlib module debug more intuitive.

----------
components: Tests
messages: 108104
nosy: techtonik
priority: normal
severity: normal
status: open
title: test_support.run_unittest cmdline options and arguments
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9028>
_______________________________________

From report at bugs.python.org  Fri Jun 18 15:05:30 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 18 Jun 2010 13:05:30 +0000
Subject: [issue9028] test_support.run_unittest cmdline options and arguments
In-Reply-To: <1276866224.2.0.777930943128.issue9028@psf.upfronthosting.co.za>
Message-ID: <1276866330.27.0.22984015322.issue9028@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Damn. I still failed to forge last use case. In should of course read:

> python test_httpservers.py CGIHTTPServer::url_collapse_path_split
CGIHTTPServer::url_collapse_path_split ... ok

Wave develops bad habits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9028>
_______________________________________

From report at bugs.python.org  Fri Jun 18 15:06:26 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 18 Jun 2010 13:06:26 +0000
Subject: [issue9027] add test_support.run_unittest command line options and
	arguments
In-Reply-To: <1276863615.44.0.266652400766.issue9027@psf.upfronthosting.co.za>
Message-ID: <1276866386.34.0.937253289633.issue9027@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Too many errors in description. Please close this ticket with #9028 as a superceder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9027>
_______________________________________

From report at bugs.python.org  Fri Jun 18 15:20:30 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 18 Jun 2010 13:20:30 +0000
Subject: [issue9028] test_support.run_unittest cmdline options and arguments
In-Reply-To: <1276866224.2.0.777930943128.issue9028@psf.upfronthosting.co.za>
Message-ID: <1276867230.36.0.463244169328.issue9028@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

These sound more like features for the unittest runner (one of which is implemented already).  Also, please don't propagate "::" as a namespace separator in Python.  That's what "." is for.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9028>
_______________________________________

From report at bugs.python.org  Fri Jun 18 15:47:14 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Jun 2010 13:47:14 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1276868834.9.0.0441513946777.issue9025@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The nonuniformity of randrange has a knock-on effect in other random module functions.  For example, take a sample of 100 elements from range(6004799503160661), and take the smallest element from that sample.  Then the exact distribution of that smallest element is somewhat complicated, but you'd expect it to be even with probability very close to 50%.  But it turns out that it's roughly twice as likely to be even as to be odd.

>>> from random import sample
>>> from collections import Counter
>>> population = range(6004799503160661)
>>> Counter(min(sample(population, 100)) % 2 for _ in range(100000))
Counter({0: 66810, 1: 33190})

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Fri Jun 18 15:55:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Jun 2010 13:55:15 +0000
Subject: [issue9028] test_support.run_unittest cmdline options and arguments
In-Reply-To: <1276866224.2.0.777930943128.issue9028@psf.upfronthosting.co.za>
Message-ID: <1276869315.58.0.670063185393.issue9028@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, running individual tests has already been implemented as part of unittest (where it belongs):

./python -m unittest test.test_httpservers.BaseHTTPServerTestCase.test_handler
.
----------------------------------------------------------------------
Ran 1 test in 0.102s

OK

The 'TestCase' marks classes that are actually test cases rather than helper classes, and test_ is how unittest determines which methods are test methods and which are support methods.  These strings are not fixed from test file to test file, so it is necessary to specify the full name (and should be).

the --list option that prints the test name in a cut and paste friendly fashion is somewhat interesting, perhaps you could open a new issue to propose adding that to unittest.  If you do open an issue, make michael.foord nosy on it.

----------
nosy: +r.david.murray
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9028>
_______________________________________

From report at bugs.python.org  Fri Jun 18 15:56:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Jun 2010 13:56:58 +0000
Subject: [issue9027] add test_support.run_unittest command line options and
	arguments
In-Reply-To: <1276863615.44.0.266652400766.issue9027@psf.upfronthosting.co.za>
Message-ID: <1276869418.0.0.841654645301.issue9027@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
superseder:  -> test_support.run_unittest cmdline options and arguments

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9027>
_______________________________________

From report at bugs.python.org  Fri Jun 18 16:00:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Jun 2010 14:00:59 +0000
Subject: [issue9026] [argparse] Subcommands not printed in the same order they
	were added
In-Reply-To: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za>
Message-ID: <1276869659.57.0.340980840432.issue9026@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It would be simpler to use an OrderedDict.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9026>
_______________________________________

From report at bugs.python.org  Fri Jun 18 16:11:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 18 Jun 2010 14:11:40 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1276870300.64.0.716578220811.issue9025@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Fri Jun 18 16:46:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jun 2010 14:46:39 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1276872399.13.0.151948245406.issue9025@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/issue9025>
_______________________________________

From report at bugs.python.org  Fri Jun 18 17:01:04 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Jun 2010 15:01:04 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1276873264.59.0.908232149298.issue9025@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a more careful Python-only patch that fixes the bias in randrange and randint (but not in shuffle, choice or sample).  It should work well both for Mersenne Twister and for subclasses of Random that use a poorer PRNG with badly-behaved low-order bits.

----------
Added file: http://bugs.python.org/file17707/issue9025_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Fri Jun 18 17:07:21 2010
From: report at bugs.python.org (Javier)
Date: Fri, 18 Jun 2010 15:07:21 +0000
Subject: [issue9026] [argparse] Subcommands not printed in the same order they
	were added
In-Reply-To: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za>
Message-ID: <1276873641.73.0.939938065688.issue9026@psf.upfronthosting.co.za>


Javier <javier.collado at gmail.com> added the comment:

While the ordered dict is a nice option, the one-line patch that is attached to the report works in python < 2.7 without adding any external dependency.

In my opininion, that's interesting for those using argparse with earlier versions of python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9026>
_______________________________________

From report at bugs.python.org  Fri Jun 18 17:14:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Jun 2010 15:14:32 +0000
Subject: [issue9026] [argparse] Subcommands not printed in the same order they
	were added
In-Reply-To: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za>
Message-ID: <1276874072.2.0.313495821763.issue9026@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Sorry, "simpler" was the wrong choice of word :)

Anyway, it's up to Steven.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9026>
_______________________________________

From report at bugs.python.org  Fri Jun 18 17:16:39 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 18 Jun 2010 15:16:39 +0000
Subject: [issue1368368] prompt_user_passwd() in FancyURLopener masks 401
	Unauthorized error page
Message-ID: <1276874199.0.0.468152168598.issue1368368@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r82068 and r82069. As mentioned in msg107883, this functionality is should not be relied upon. It is present for legacy apps. I have added a NEWS note mentioning that there is a change in behavior (if legacy apps owners can catch it)

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1368368>
_______________________________________

From report at bugs.python.org  Fri Jun 18 17:43:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 18 Jun 2010 15:43:39 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276875819.5.0.890328123721.issue6641@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Reopening because the patch introduced a regression with respect to datetime subclasses:


>>> class DT(datetime): pass
... 
>>> DT.strptime('', '')
datetime.datetime(1900, 1, 1, 0, 0)


a DT instance expected.  Need tests covering subclasses.

----------
stage: committed/rejected -> unit test needed
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Fri Jun 18 18:10:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 18 Jun 2010 16:10:20 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276877420.66.0.662061312236.issue6641@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attaching issue6641b.diff that fixes subclassing issue.  Added tests for datetime subclass only to keep the patch focused. Adding tests for datetime and time subclasses will be natural in issue 1100942.

----------
Added file: http://bugs.python.org/file17708/issue6641b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Fri Jun 18 19:03:13 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 18 Jun 2010 17:03:13 +0000
Subject: [issue9028] test_support.run_unittest cmdline options and arguments
In-Reply-To: <1276866224.2.0.777930943128.issue9028@psf.upfronthosting.co.za>
Message-ID: <1276880593.42.0.814532625325.issue9028@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/issue9028>
_______________________________________

From report at bugs.python.org  Fri Jun 18 19:06:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 18 Jun 2010 17:06:23 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276880783.9.0.684302005942.issue6641@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Replacing issue6641b.diff after fixing some spelling errors.  Thanks, Ezio.

----------
Added file: http://bugs.python.org/file17709/issue6641b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Fri Jun 18 19:06:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 18 Jun 2010 17:06:33 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276880793.34.0.983344996585.issue6641@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17708/issue6641b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Fri Jun 18 19:07:01 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Jun 2010 17:07:01 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1276880821.89.0.390004402529.issue9025@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Fri Jun 18 19:09:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 18 Jun 2010 17:09:07 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276880947.42.0.0801495163869.issue6641@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17710/issue6641b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Fri Jun 18 19:09:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 18 Jun 2010 17:09:13 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276880953.12.0.47009821431.issue6641@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17709/issue6641b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Fri Jun 18 19:56:40 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Jun 2010 17:56:40 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1276883800.62.0.130438155599.issue9025@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Will take a look at this in the next few days.
Am tempted to just either provide a recipe
or provide a new method.  That way sequences generated
by earlier python's are still reproducible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Fri Jun 18 19:59:04 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 18 Jun 2010 17:59:04 +0000
Subject: [issue9020] 2.7: eval hangs on AIX because sizeof(char) == 32
In-Reply-To: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>
Message-ID: <1276883944.72.0.220911695405.issue9020@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Ok, I now have a fix for this issue. The reason for sizeof(c) being 4 bytes is because it is defined as `register int` ... and yet `Py_CHARMASK` fails to type-cast `c` to a `char` type, which is exactly what the attached patch does.

----------
keywords: +patch
title: 2.7: eval hangs on AIX -> 2.7: eval hangs on AIX because sizeof(char) == 32
Added file: http://bugs.python.org/file17711/tok_get_infinite_loop_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Fri Jun 18 20:02:35 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 18 Jun 2010 18:02:35 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1276884155.29.0.86009644074.issue9025@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I would prefer to see correct algorithm in stdlib and a recipe for how to reproduce old sequences for the users who care.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Fri Jun 18 20:11:44 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 18 Jun 2010 18:11:44 +0000
Subject: [issue9020] 2.7: eval hangs on AIX because sizeof(char) == 32
In-Reply-To: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>
Message-ID: <1276884704.39.0.317166161007.issue9020@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

David, to answer your question "How does it behave with the head of the current 2.6 maintenance branch, by the way?", since this bug appears to be in Include/pyctype.h, which file was available only in 2.7+ and 3.x, I don't believe it will reproduce in 2.6 maint branch that doesn't even have pyctype.h.

I am also adding Eric Smith, the original author of pyctype.h that got added as a fix for issue5793, to this bug. 

Eric, I've attached a patch ... can you review it please?

----------
nosy: +eric.smith
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Fri Jun 18 20:12:56 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 18 Jun 2010 18:12:56 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>
Message-ID: <1276884776.29.0.882953500675.issue9020@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
title: 2.7: eval hangs on AIX because sizeof(char) == 32 -> 2.7: eval hangs on AIX

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Fri Jun 18 20:18:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Jun 2010 18:18:03 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>
Message-ID: <1276885083.91.0.0291140383735.issue9020@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis
stage:  -> patch review
type: resource usage -> crash
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Fri Jun 18 20:24:46 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Jun 2010 18:24:46 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276885486.55.0.842204179392.issue7989@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I've been thinking about this feature request and am starting to question whether it is necessary.  Usually we need a pure python version when 1) the python module is developed first, with the subsequent C code needing to match, or 2) we expect a porting issue, or 3) for pedagogical purposes (i.e. showing how heaps work).

For example, sets.py preceded setobject.c and ultimately we dropped sets.py.  In the case of heapq.py, it was kept because of its teaching value and because some other implementations like Jython used it.  In other cases like collections.deque, the pure python version is maintained off-line in an ASPN recipe and we may provide a link to it in the docs.

For the datetime module, I don't think we get much value from having pure python and C version in the distribution.  The semantics were worked out a long time ago, the algorithms aren't interesting, and other implementations already have their own conforming versions.  ISTM, a pure python version in our standard distribution would never be run and rarely looked at.  

While it may seem like a cool thing to do, no one has actually requested
this "feature" (I use quotes here because no new functionality is added).  The addition would be mostly harmless but it would increase the maintenance burden (I know because I've actively maintained pure python equivalents for itertools and it has been a PITA).

If this is a step in your development process, I recommend keeping it in a sandbox or publishing it on PyPI.

If we were to invest some efforts in writing pure python equivalents, I would like to see the docs include an equivalent of str.split() whose behavior is difficult to fully and correctly describe in plain English.  In contrast, the availability of a pure python version of datetime wouldn't add much that isn't already covered in the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Fri Jun 18 20:34:09 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Jun 2010 18:34:09 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1276886049.24.0.758749499292.issue9025@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, we spent ten years maintaining the ability to reproduce sequences.  It has become an implicit promise.
I'll take a look at the patch in the next few days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Fri Jun 18 20:39:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 18 Jun 2010 18:39:37 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276886377.03.0.208178978667.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Let me just add a story to show how an alternate python implementation may be useful for users.  As I was porting datetime.py to 3.x, I saw many failures from pickle tests.  It was not easy to figure out what was going on because C pickle code was calling buggy Python and pdb was unable to trace the full chain of calls.  To work around that, I added sys.modules['_pickle'] = None to my test run and there you go - the problem was found in minutes.   I am sure that someone debugging his tzinfo implementation, for example, may find datetime.py easier to work with.

The story may be a bit self-serving, but I was against this "feature" myself, but now I see enough use that I am actually working on it.

Yes, the work is in the sandbox, but I want to have py3k working version before I announce it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Fri Jun 18 20:47:44 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 18 Jun 2010 18:47:44 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>
Message-ID: <1276886864.69.0.246387150718.issue9020@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I suppose that's correct, although I have no way to test it.

I haven't spent a lot of time looking at the code in tokenizer.c, but if there's a problem with sign-extending signed chars, it wouldn't surprise me if it shows up in more than one place.

Does anyone know what other compilers use signed chars? I would think this would be a problem on those platforms, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Fri Jun 18 20:49:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Jun 2010 18:49:22 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276886962.06.0.654868320051.issue7989@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

My understanding is that the desire to have pure python versions of standard library modules is to decouple the standard library from dependency on CPython as far as practical.  Perhaps all existing Python implementations have dealt with datetime somehow, but what about new implementations?  Having a pure Python version would help developers of new implementations get started, even if they later decided to reimplement it more natively (as CPython has done).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Fri Jun 18 20:49:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 18 Jun 2010 18:49:25 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276886965.97.0.00204089625997.issue6641@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r82073.

----------
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Fri Jun 18 20:49:59 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 18 Jun 2010 18:49:59 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>
Message-ID: <1276886999.29.0.622055117498.issue9020@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

It would also be good to get a test case for this. I realize it's difficult, but that's the sort of change that might get undone some day by someone going through and "optimizing" the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Fri Jun 18 21:34:07 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Jun 2010 19:34:07 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276889647.34.0.271438558157.issue7989@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> My understanding is that the desire to have pure 
> python versions of standard library modules is 
> to decouple the standard library from dependency 
> on CPython as far as practical.

That is a bit of a broad brush.  I do not know
of an approved project to give all C modules
a pure python equivalent (in fact modules like
pickle presented a long-term maintenance problem
in that the two versions differed and modules
like sets.py were dropped entirelly).

Looking at svn.python.org/view/python/trunk/Modules/
I see some which are good candidates and many which
aren't.  We need to show judgment on which one to do
and recognize that maintaining dual code is a 
heavy maintenance burden and only do so where
there is a clear value add.

In my judgment, something like str.split() would
benefit quite a bit from a pure python equivalent
because its spec is somewhat opaque and hidden
in C code and because both docs and the test 
coverage are incomplete.

In contrast, I believe that dual code for datetime 
is a net loss.  There is a reason that Uncle Timmy 
didn't put it in in the first place.  

Also, for those who haven't tried it before, it is
not always easy to get good pure python equivalents
(i.e. C iterators check their arguments when first
called and Python versions do their argument checking
when next() is first called; C functions sometimes
do interesting keyword argument handling that cannot be 
done in pure python; and pure python versions differ
in their tracebacks).  Also, it's easy to make a mistake
and misspecify the pure python version.  You're relying
on the test suite to catch all semantic differences.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Fri Jun 18 21:43:49 2010
From: report at bugs.python.org (John Van Praag)
Date: Fri, 18 Jun 2010 19:43:49 +0000
Subject: [issue9029] errors='replace' works in IDLE,
	fails at Windows command line.
In-Reply-To: <1276890229.73.0.493277821026.issue9029@psf.upfronthosting.co.za>
Message-ID: <1276890229.73.0.493277821026.issue9029@psf.upfronthosting.co.za>


New submission from John Van Praag <john at jvp247.com>:

Platforms:
Windows Vista Ultimate 64 bit
Python v3.1.2

Goal is to read a tab-separated CSV file. Some records have garbage characters in them.

The following code fragment works when the program is run in IDLE, but fails when run from the Windows command line.

...
	fh_read = open(company_info, encoding='utf_8', errors='replace')
	fh_write = open(quotes_file, 'w')
	count = 0
	try:
		rdr = csv.reader(fh_read, delimiter='\t')
		wrt = csv.writer(fh_write, delimiter='\t', quotechar='"', lineterminator='\n')
		for row in rdr:
...

Within IDLE the code works with or without the encoding='utf_8' declaration; and it fails with or without the declaration when run from the Windows command line.

The error message from the Windows command line is as follows:

'charmap' codec can't encode character '\u2019' in position 207: character maps to <undefined>

----------
components: Windows
messages: 108130
nosy: jvanpraag
priority: normal
severity: normal
status: open
title: errors='replace' works in IDLE, fails at Windows command line.
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9029>
_______________________________________

From report at bugs.python.org  Fri Jun 18 21:45:57 2010
From: report at bugs.python.org (shypike)
Date: Fri, 18 Jun 2010 19:45:57 +0000
Subject: [issue8972] subprocess.list2cmdline doesn't quote the & character
In-Reply-To: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>
Message-ID: <1276890357.16.0.743559782284.issue8972@psf.upfronthosting.co.za>


shypike <shypike at sabnzbd.org> added the comment:

I see your point about passing a command line as a single string instead of a list. Too bad that Popen doesn't just do the obvious thing (assemble the list into a string in a shell/cmd.exe compatible way).

Issue 1300 should indeed be reversed.

Raising ValueError will result in breaking some existing programs.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8972>
_______________________________________

From report at bugs.python.org  Fri Jun 18 21:50:41 2010
From: report at bugs.python.org (=?utf-8?q?Germ=C3=A1n_L=2E_Osella_Massa?=)
Date: Fri, 18 Jun 2010 19:50:41 +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: <1276890641.29.0.358167000197.issue7951@psf.upfronthosting.co.za>


Germ?n L. Osella Massa <gosella at gmail.com> added the comment:

I finally managed to get the time to finish the patch that allows negative indexes inside square brackets so now they work with the same semantics as in a python expression:

>>> '{0[-1]}'.format(['abc', 'def'])
'def'
>>> '{0[-2]}'.format(['abc', 'def'])
'abc'
>>> '{0[-1][-1]}'.format(['abc', ['def']])
'def'

They work auto-numbered fields too:
>>> '{[-1]}'.format(['abc', 'def'])
'def'

Also, a positive sign is now accepted as part of a valid integer:

>>> '{0[+1]}'.format(['abc', 'def'])
'def'

As a bonus, negatives indexes are also allowed to refer to positional arguments:

>>> '{-1}'.format('abc', 'def')
'def'
>>> '{-2}'.format('abc', 'def')
'abc'

I'm attaching a patch against trunk. I added some tests for this functionality in test_str.py.

By the way, this code doesn't work anymore:

>>> "{[-1]}".format({'-1': 'X'})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: -1L

But now it behaves in the same way as:
>>> "{[1]}".format({'1': 'X'})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 1L

I didn't attempt to ignore whitespaces when trying to parse the index as an integer (to allow that "{ 0 }" can be treated as "{0}" and "{0[1]}" as "{ 0 [ 1 ] }") because I'm not sure if this behavior is desirable.

----------
keywords: +patch
Added file: http://bugs.python.org/file17712/format_negative_indexes-2.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Fri Jun 18 21:52:53 2010
From: report at bugs.python.org (=?utf-8?q?Germ=C3=A1n_L=2E_Osella_Massa?=)
Date: Fri, 18 Jun 2010 19:52:53 +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: <1276890773.39.0.423298539984.issue7951@psf.upfronthosting.co.za>


Changes by Germ?n L. Osella Massa <gosella at gmail.com>:


Added file: http://bugs.python.org/file17713/format_negative_indexes-3.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Fri Jun 18 21:54:03 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 18 Jun 2010 19:54:03 +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: <1276890843.94.0.0658305718024.issue6884@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
components: +Distutils2
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________

From report at bugs.python.org  Fri Jun 18 21:55:18 2010
From: report at bugs.python.org (=?utf-8?q?Germ=C3=A1n_L=2E_Osella_Massa?=)
Date: Fri, 18 Jun 2010 19:55:18 +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: <1276890918.7.0.321780698551.issue7951@psf.upfronthosting.co.za>


Germ?n L. Osella Massa <gosella at gmail.com> added the comment:

I forgot to mention that I also made a patch against py3k (was the same code).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Fri Jun 18 22:04:29 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 18 Jun 2010 20:04:29 +0000
Subject: [issue1300] subprocess.list2cmdline doesn't do pipe symbols
In-Reply-To: <1192729254.96.0.285794085895.issue1300@psf.upfronthosting.co.za>
Message-ID: <1276891469.03.0.851762977874.issue1300@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

I reverted r60115 from trunk (2.7) in r82075 and from py3k in r82076.

----------
nosy: +exarkun
resolution: fixed -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1300>
_______________________________________

From report at bugs.python.org  Fri Jun 18 22:10:32 2010
From: report at bugs.python.org (Pauli Rikula)
Date: Fri, 18 Jun 2010 20:10:32 +0000
Subject: [issue9030] ctypes variable limits
Message-ID: <1276891832.19.0.947205557485.issue9030@psf.upfronthosting.co.za>


Changes by Pauli Rikula <pauli.rikula at gmail.com>:


----------
assignee: theller
components: ctypes
nosy: kumma, theller
priority: normal
severity: normal
status: open
title: ctypes variable limits

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9030>
_______________________________________

From report at bugs.python.org  Fri Jun 18 22:11:32 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 18 Jun 2010 20:11:32 +0000
Subject: [issue8972] subprocess.list2cmdline doesn't quote the & character
In-Reply-To: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>
Message-ID: <1276891892.02.0.373443100298.issue8972@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

I've reverted the issue1300 revision from 2.6, 2.7, 3.1, and 3.2.  I hope 
7839 is resolved soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8972>
_______________________________________

From report at bugs.python.org  Fri Jun 18 22:12:32 2010
From: report at bugs.python.org (Matteo Vescovi)
Date: Fri, 18 Jun 2010 20:12:32 +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: <1276891952.43.0.0434978352487.issue9031@psf.upfronthosting.co.za>


New submission from Matteo Vescovi <matteo.vescovi at yahoo.co.uk>:

Hi,

It seems like distutils passes an invalid "-Wstrict-prototypes" flag when compiling a C++ extension module on Linux (tested on Debian lenny and sid).

running build
running build_py
creating build
creating build/lib.linux-i686-2.6
copying presage.py -> build/lib.linux-i686-2.6
running build_ext
building '_presage' extension
creating build/temp.linux-i686-2.6
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -O2 -g -Wall -O2 -fPIC -I../../src/lib -I/usr/include/python2.6 -c presage_wrap.cpp -o build/temp.linux-i686-2.6/presage_wrap.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -L/usr/local/lib -Wl,--as-needed -g -O2 -g -Wall -O2 build/temp.linux-i686-2.6/presage_wrap.o -L../../src/lib/.libs -lpresage -o build/lib.linux-i686-2.6/_presage.so
running build_scripts
creating build/scripts-2.6
copying and adjusting presage_python_demo -> build/scripts-2.6
changing mode of build/scripts-2.6/presage_python_demo from 644 to 755

I did a bit of digging on this one. It looks like distutils reuses whatever flags python was built with.

matt at burrow:/usr/lib/python2.5/distutils$ python2.5
Python 2.5.2 (r252:60911, Jan 24 2010, 14:53:14)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> sysconfig.get_config_var("CFLAGS")
'-fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes'
>>>

In /usr/lib/python2.5/distutils/unixcompiler.py I found this comment:

# XXX Things not currently handled:
#   * optimization/debug/warning flags; we just use whatever's in Python's
#     Makefile and live with it.  Is this adequate?  If not, we might
#     have to have a bunch of subclasses GNUCCompiler, SGICCompiler,
#     SunCCompiler, and I suspect down that road lies madness.


It would be nice is distutils was smart enough to recognize that a c++ module was being built and to strip the unneeded flags.

Please consider this as a wishlist request, as this causes only a warning, not a failure.


Cheers,
- Matteo

----------
assignee: tarek
components: Distutils
messages: 108136
nosy: matteo.vescovi, tarek
priority: normal
severity: normal
status: open
title: distutils uses invalid "-Wstrict-prototypes" flag when compiling C++ extension module
type: feature request
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9031>
_______________________________________

From report at bugs.python.org  Fri Jun 18 22:16:50 2010
From: report at bugs.python.org (Pauli Rikula)
Date: Fri, 18 Jun 2010 20:16:50 +0000
Subject: [issue9030] ctypes variable limits
In-Reply-To: <1276892210.09.0.679201213154.issue9030@psf.upfronthosting.co.za>
Message-ID: <1276892210.09.0.679201213154.issue9030@psf.upfronthosting.co.za>


New submission from Pauli Rikula <pauli.rikula at gmail.com>:

ctypes should have nice interface from which one could get maximum and minimum values etc information about numeric's data types. for integers this is quite trivial, but at least long double is a bit trickier one.

----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9030>
_______________________________________

From report at bugs.python.org  Fri Jun 18 22:43:10 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Jun 2010 20:43:10 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1276893790.36.0.838429915998.issue9025@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  I hadn't considered the reproducibility problem.

Does the module aim for reproducibility across all platforms *and* all versions of Python?  Or just one of those?

For small n, I think the patched version of randrange(n) produces the same sequence as before with very high probability, but not with certainty.  Since that sounds like a recipe for hard-to-find bugs, it might be better to deliberately perturb the outputs somehow so that the sequence is obviously different from before, rather than subtly different.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Fri Jun 18 22:46:54 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 18 Jun 2010 20:46:54 +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: <1276894014.17.0.0409826025984.issue9031@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
priority: normal -> low
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9031>
_______________________________________

From report at bugs.python.org  Fri Jun 18 22:47:29 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 18 Jun 2010 20:47:29 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276886864.69.0.246387150718.issue9020@psf.upfronthosting.co.za>
Message-ID: <71632AD4-5DEE-4DA1-98D3-D236693808FD@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On 2010-06-18, at 11:47 AM, Eric Smith wrote:

> 
> Eric Smith <eric at trueblade.com> added the comment:
> 
> I suppose that's correct, although I have no way to test it.

I have tested it on Linux 64-bit by running `test.regrtest`. It doesn't seem to break anything.

> I haven't spent a lot of time looking at the code in tokenizer.c, but if there's a problem with sign-extending signed chars, it wouldn't surprise me if it shows up in more than one place.

My conclusive understanding of the problem: `register int` is 4 bytes in size, and this (`c`) is used without any cast as an index to the array _Py_ctype_table (in pyctype.c) ... by passing it to `Py_CHARMASK` which, if CHAR_UNSIGNED is defined (as is the case with AIX compiler), *assumes* that `c` will always be a char. And that assumption is not respected by tokenizer.c:tok_get which (indirectly) passes `register int` to this macro.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Fri Jun 18 22:50:08 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 18 Jun 2010 20:50:08 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276886999.29.0.622055117498.issue9020@psf.upfronthosting.co.za>
Message-ID: <6056D2CB-6560-472E-AE73-7C9CC65E40CA@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On 2010-06-18, at 11:49 AM, Eric Smith wrote:

> It would also be good to get a test case for this. I realize it's difficult, but that's the sort of change that might get undone some day by someone going through and "optimizing" the code.

Running existing tests (some of which use `eval`) on a platform/compiler combination (eg: AIX/xlc_r) where __CHAR_UNSIGNED__ gets defined should be enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Fri Jun 18 23:18:46 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Jun 2010 21:18:46 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1276895926.35.0.0487128103194.issue9009@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r82079:  Apply a version of the parsing patch to pull the parsing code
   out into a separate function.

Alexander, I agree about the names;  I'll do a mass renaming later on.  I'm trying not to mix the significant algorithm-changing commits with trivial renaming/reindenting/commenting commits, to make it easier to review each independent change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Fri Jun 18 23:36:40 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 18 Jun 2010 21:36:40 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1276897000.67.0.52685694677.issue9009@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

It would be easier for me to review if you did it in the other order: fix the variable names first.

Although I'm still pretty busy and won't have much time to review, so my needs shouldn't be your first priority.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Fri Jun 18 23:38:24 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Jun 2010 21:38:24 +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: <1276897104.46.0.364612226806.issue7951@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Perhaps this ought to be discussed on python-ideas or python-dev for a bit.  It is not entirely clear that this is a GoodThingToDo(tm) nor is it clear that we want other Python implementations to have to invest the same effort.

The spirit of the language freeze suggests that we shouldn't add this unless we really need it.  The goal was to let other implementations catch up, not to add to their list of incompatabilites.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Fri Jun 18 23:47:19 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 18 Jun 2010 21:47:19 +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: <1276897639.72.0.288284458895.issue7951@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree with Raymond. I'm not convinced it allows you to write any code that you can't currently write, and I'm fairly sure it violates the moratorium. Implementing this would clearly put a burden on other implementations.

Marking as "after moratorium".

----------
keywords: +after moratorium -patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Fri Jun 18 23:51:42 2010
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Delfosse?=)
Date: Fri, 18 Jun 2010 21:51:42 +0000
Subject: [issue1744] readline module - set/get quote delimiters
In-Reply-To: <1199632447.57.0.76416797802.issue1744@psf.upfronthosting.co.za>
Message-ID: <1276897902.5.0.00724006758796.issue1744@psf.upfronthosting.co.za>


C?dric Delfosse <cedric at delfosse.org> added the comment:

Here is an updated patch against current trunk. It also contains documentation update and a unit test.

----------
nosy: +cdelfosse
Added file: http://bugs.python.org/file17714/trunk-readline.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1744>
_______________________________________

From report at bugs.python.org  Sat Jun 19 00:32:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jun 2010 22:32:26 +0000
Subject: [issue9032] xmlrpc: Transport.request() should also catch
	socket.error(EPIPE)
In-Reply-To: <1276900346.42.0.945858543799.issue9032@psf.upfronthosting.co.za>
Message-ID: <1276900346.42.0.945858543799.issue9032@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Since Python 2.7 / 3.2, httplib supports HTTP(S)/1.1 (keep-alive). This version of HTTP is much faster because the connection is kept between two requests. I'm using it with XML-RPC + SSL (M2Crypto). It works nice.

My problem is when the server closes the connection (eg. the server restarts). If I send a small (XML-RPC) request, sending the request works (I don't understand why, maybe because of a buffer somewhere), but getting the response raises a BadStatusLine because the response is empty (0 byte). If I send a big (XML-RPC) request, sending the request fails with a SSLError(EPIPE, '...') and Transport.request() doesn't retry with a new connection.

I patched my copy of M2Crypto to ensure that SSLError inherits from socket.error, but it's not enough: Transport.request() only catchs errno.ECONNRESET and errno.ECONNABORTED socket errors.

Attached patch catchs also errno.EPIPE. This error is received on sending to the socket whereas the server closed the socket.

----------
components: Library (Lib)
files: xmlrpc_request_epipe.patch
keywords: patch
messages: 108146
nosy: haypo
priority: normal
severity: normal
status: open
title: xmlrpc: Transport.request() should also catch socket.error(EPIPE)
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17715/xmlrpc_request_epipe.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9032>
_______________________________________

From report at bugs.python.org  Sat Jun 19 00:54:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jun 2010 22:54:23 +0000
Subject: [issue9032] xmlrpc: Transport.request() should also catch
	socket.error(EPIPE)
In-Reply-To: <1276900346.42.0.945858543799.issue9032@psf.upfronthosting.co.za>
Message-ID: <1276901663.12.0.0713018653371.issue9032@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also r70643 (from issue #5542): "Remove special logic that closes HTTPConnection socket on EPIPE.

If the socket is closed, the client has no chance to read the response
from the server.  EPIPE means that it isn't possible to write more
data from the socket, but not that it is impossible to read."

This commit didn't updated the following comment. I think that it should be fixed (maybe removed?) because the socket is no more closed on broken pipe error.

# send the data to the server. if we get a broken pipe, then close
# the socket. we want to reconnect when somebody tries to send again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9032>
_______________________________________

From report at bugs.python.org  Sat Jun 19 01:02:28 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 18 Jun 2010 23:02:28 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>
Message-ID: <1276902148.54.0.0520306246326.issue9020@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Does anyone know what other compilers use signed chars?

Most of them do, including gcc, on most platforms. unsigned char is really the uncommon case.

The patch is incorrect; Py_CHARMASK is correct as it stands. It is *not* the objective of Py_CHARMASK to produce a char, but (as the comment above its definition explains) to produce an int.

The question really is why you get a value of -1 into c in the first place. Could it be that you are past the end of file, and reading EOF "characters"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Sat Jun 19 01:24:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jun 2010 23:24:40 +0000
Subject: [issue850997] mbcs encoding ignores errors
Message-ID: <1276903480.23.0.689537698922.issue850997@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Close this issue: nothing special on the buildbots.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue850997>
_______________________________________

From report at bugs.python.org  Sat Jun 19 01:37:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jun 2010 23:37:44 +0000
Subject: [issue4352] imp.find_module() fails with a UnicodeDecodeError when
	called with non-ASCII search paths
In-Reply-To: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za>
Message-ID: <1276904264.02.0.469231955525.issue4352@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I closed issue #850997, mbcs is now really strict by default:

>>> 'h\u00e4kkinen'.encode('mbcs')
UnicodeEncodeError: ...
>>> 'h\u00e4kkinen'.encode('mbcs', 'replace')
"b'hakkinen'"

PyUnicode_EncodeFSDefault(), PyUnicode_DecodeFSDefault() and os.fsencode() use mbcs with strict error handler on Windows. On other OS, these functions use surrogateescape error handler, but mbcs only supports strict and replace (to encode, and strict and ignore to decode).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4352>
_______________________________________

From report at bugs.python.org  Sat Jun 19 01:42:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jun 2010 23:42:47 +0000
Subject: [issue8775] Use locale encoding to decode sys.argv,
	not the file system encoding
In-Reply-To: <1274357365.37.0.0731450159524.issue8775@psf.upfronthosting.co.za>
Message-ID: <1276904567.15.0.184684942649.issue8775@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Attached patch is a draft adding a new encoding: command line encoding. It is used to encode (subprocess) and decode (python) the command line arguments. It adds sys.getcmdlineencoding().

----------
keywords: +patch
Added file: http://bugs.python.org/file17716/cmdline_encoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8775>
_______________________________________

From report at bugs.python.org  Sat Jun 19 01:46:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jun 2010 23:46:34 +0000
Subject: [issue8949] PyArg_Parse*(): "z" should not accept bytes
In-Reply-To: <1276032203.54.0.364398342729.issue8949@psf.upfronthosting.co.za>
Message-ID: <1276904794.69.0.0381162151509.issue8949@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@lemburg: So what is your opinion on this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8949>
_______________________________________

From report at bugs.python.org  Sat Jun 19 01:47:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jun 2010 23:47:00 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1276904820.83.0.263147472728.issue3297@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3297>
_______________________________________

From report at bugs.python.org  Sat Jun 19 01:53:35 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 18 Jun 2010 23:53:35 +0000
Subject: [issue8775] Use locale encoding to encode command line arguments
	(subprocess, os.exec*(), etc.)
In-Reply-To: <1274357365.37.0.0731450159524.issue8775@psf.upfronthosting.co.za>
Message-ID: <1276905215.41.0.989261701106.issue8775@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
title: Use locale encoding to decode sys.argv, not the file system encoding -> Use locale encoding to encode command line arguments (subprocess, os.exec*(), etc.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8775>
_______________________________________

From report at bugs.python.org  Sat Jun 19 01:54:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 18 Jun 2010 23:54:14 +0000
Subject: [issue8775] Use locale encoding to encode command line arguments
	(subprocess, os.exec*(), etc.)
In-Reply-To: <1274357365.37.0.0731450159524.issue8775@psf.upfronthosting.co.za>
Message-ID: <1276905254.52.0.208152430188.issue8775@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm still -1, failing to see the problem that is solved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8775>
_______________________________________

From report at bugs.python.org  Sat Jun 19 01:55:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jun 2010 23:55:57 +0000
Subject: [issue8775] Use locale encoding to encode command line arguments
	(subprocess, os.exec*(), etc.)
In-Reply-To: <1274357365.37.0.0731450159524.issue8775@psf.upfronthosting.co.za>
Message-ID: <1276905357.32.0.708746567287.issue8775@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I'm still -1, failing to see the problem that is solved.

I know (and I agree), but I don't want to loose the patch :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8775>
_______________________________________

From report at bugs.python.org  Sat Jun 19 02:06:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 19 Jun 2010 00:06:45 +0000
Subject: [issue8939] Use C type names (PyUnicode etc;) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276906005.74.0.880806301573.issue8939@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r82084 (in 3.2 and r82085 in 3.1) fixes some of the reported issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8939>
_______________________________________

From report at bugs.python.org  Sat Jun 19 02:25:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 19 Jun 2010 00:25:28 +0000
Subject: [issue8863] Segfault handler: display Python backtrace on segfault
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1276907128.61.0.5120683121.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New version of the patch:
 - catch also SIGFPE
 - add segfault.o to Makefile.pre.in
 - use abort() to quit instead of _exit(1)
 - call DebugBreak() on Windows before the abort(), as done by Py_FatalError()

TODO: Patch configure to only enable segfault handler if sigaltstack() is available. The alternate stack is maybe not needed for the SIGFPE handler.

----------
Added file: http://bugs.python.org/file17717/segfault_handler-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Sat Jun 19 02:55:42 2010
From: report at bugs.python.org (geremy condra)
Date: Sat, 19 Jun 2010 00:55:42 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276855514.3338.26.camel@localhost.localdomain>
Message-ID: <AANLkTila7wm_4BPir7ffUqe9p0G9OZCz2hYGnMV_qOOt@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Fri, Jun 18, 2010 at 6:05 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> Great, I'm thinking more-or-less the API proposed in PEP 272- the
>> exception I'm thinking of is that 'strings' should be substituted for
>> 'bytes'- for AES and DES. It gets trickier when talking about public
>> key crypto, though. Perhaps something along the lines of
>> RSA.new(public_key=None, private_key=None,...), with the resulting
>> object supporting encrypt/decrypt/sign/verify operations?
>
> I don't have any opinion right now. I think a concrete proposal should
> be initiated and we can iterate from that.
> (that's assuming other people agree on the principle, of course)

I assume that by "a concrete proposal" you're talking about code? Or
API docs? Also, what more needs to be done to ensure that other people
agree on the principle?

>> If we're likely to have openssl taken out from under us it could save
>> us a lot of hassle to plan for that up front.
>
> It doesn't seem very likely in the middle term. In particular, the ssl
> module itself is quite tied to OpenSSL's socket wrapping semantics
> (including error codes and non-blocking behaviour), so OpenSSL will
> probably still be required for SSL sockets.

I'm fine with doing it the simpler way and adding in support for other
systems PRN. Having said that, Martin, if this is high priority for
you let me know.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sat Jun 19 03:03:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 19 Jun 2010 01:03:56 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276909436.03.0.243550323661.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I was probably misled by Brett's assertion that 'it's not a matter of "if" but "when" datetime will get a pure Python version.' (msg106498)  It looks like this is not a universally shared opinion.

I am not ready to form a final opinion on datetime.py.  I have ported it to 3.2 to the point where it passes the regression tests, but did not attempt to clean up the code in any way or match C implementation on the level of doc strings and error messages.  I am attaching the diff between PyPy-2.7 and 3.2 port as issue7989-2.7-3.2.diff here. You can find the full source in the sandbox/py3k-datetime at r82083.  I think having a working implementation will help making a decision here.

Here are some random thoughts based on the experience with datetime.py.  

The datetime module have seen very little development in the last six years.  Tracker RFEs and bug reports were languishing for years while people have been ranting about how much better other languages handle date/time than Python.  Python-dev discussions would run into dozens of posts with an inevitable conclusion that the situation is a mess and cannot be fixed.

It is posible that one of the reasons for the current state of affairs was that people with the problem domain expertise did not have C skills and people with the requisite C skills were conditioned by the C approach to time which is an even bigger mess than what we have.  I cannot rule out that if datetime.py was easily available, we would see more patches proposed and more informed discussions about desired features.

Raymond argues that datetime documentation is good enough and python implementation will not add to it.  I disagree.  Consider this passage from tzinfo documentation: "When a datetime object is passed in response to a datetime method, dt.tzinfo is the same object as self. tzinfo methods can rely on this, unless user code calls tzinfo methods directly."  Is this as clear as the following code that makes use of this?

    def fromutc(self, dt):
        ..
        if dt.tzinfo is not self:
            raise ValueError("dt.tzinfo is not self")

Documentation for datetime module is indeed extensive.  The reST file is over 1700 lines long.  This is comparable to about 1900 lines in datetime.py (not counting a long treatise on timezone calculations at the end of the file.)  It may be easier to find an answer in the code than in the documentation.  After all you cannot step through documentation in a debugger.

I am still between -0 and +0 about including datetime.py in the main tree.  For my own development purposes having sandbox version is adequate and maintaining it there is easier than in-tree.  It would be great, however if this discussion would lead to clear guidelines about cases when parallel C and Python implementations are desired and how to maintain such arrangements

----------
Added file: http://bugs.python.org/file17718/issue7989-2.7-3.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Sat Jun 19 03:05:27 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 19 Jun 2010 01:05:27 +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: <1276909527.26.0.777804196976.issue8990@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Summary: real bug, needs test, patch provided, looks plausible but I am not qualified to even read-review it, let alone apply and test.

(I am removing 3.3 because that is only listed for syntax feature requests that cannot go into 3.2 because of its moratorium on such.)

I agree that this is a bug. For 3.1, the '8.6. array' doc says
"class array.array(typecode[, initializer]) 
A new array whose items are restricted by typecode, and initialized from the optional initializer value, which must be a list, object supporting the buffer interface, or iterable over elements of the appropriate type."

I believe bytearray 'supports the buffer interface', whatever that means in 3.x. 'Readonly' is definitely *not* specified. Even if bytearray did not qualify on that, instances are *definitely* iterable.

The doc goes on: "If given a list or string, the initializer is passed to the new array?s fromlist(), fromstring(), or fromunicode() method (see below) to add initial items to the array. Otherwise, the iterable initializer is passed to the extend() method."

For 3.x, this is pretty bad as it is copied without change from 2.x and uses 'string' in the 2.x sense. It seems to me that fromstring/fromunicode should have been renamed to frombytes/fromstring with a 2to3 fixer. Too late now, I suppose. However, if indeed 'fromstring' is intended to mean 'from bytes only and not bytearrays', then bytearrays should be passed on to .extend, which accepts them as well as anything else.

>>> from array import array
>>> a=array('h')
>>> a.extend(bytearray(b'xjxjx'))
>>> a
array('h', [120, 106, 120, 106, 120])

The two possible fixes:

1. Extend .fromstring to accept bytearrays. Its current doc "Appends items from the string, interpreting the string as an array of machine values " to me supports doing that. This is what Thomas's patch does.

2. If that is rejected, then bytearray initializers should be passed to .extend.

Thomas: a complete patch needs to include a update to the array unit test suite. This can then move to the patch review stage.

----------
nosy: +tjreedy
stage:  -> unit test needed
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8990>
_______________________________________

From report at bugs.python.org  Sat Jun 19 04:15:18 2010
From: report at bugs.python.org (Mike Lisanke)
Date: Sat, 19 Jun 2010 02:15:18 +0000
Subject: [issue2475] Popen.poll always returns None
In-Reply-To: <1276733591.82.0.507377272093.issue2475@psf.upfronthosting.co.za>
Message-ID: <AANLkTik-zQMvkThzwTGT7SLSA85r4aUy9ou5m6Tnbi1_@mail.gmail.com>


Mike Lisanke <MikeLisanke at gmail.com> added the comment:

Terry,

I had long since coded around the problem. At this point, I no longer have
the test environment to cause the intermittent conditions of the process
hang. I could code something up, but; your question is the first response to
this bug report since "reiko <j.k.langridge at gmail.com>" on 7/28/2008. I
suggest it can be closed, and would be reopened when encountered again. I
appears nobody is working in that area of code.

On Wed, Jun 16, 2010 at 8:13 PM, Terry J. Reedy <report at bugs.python.org>wrote:

>
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
>
> Should this be closed or is this still a problem in 2.7 (release candidate
> out now, final soon) or 3.1?
>
> ----------
> nosy: +tjreedy
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2475>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file17719/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2475>
_______________________________________
-------------- next part --------------
Terry,<div><br></div><div>I had long since coded around the problem. At this point, I no longer have the test environment to cause the intermittent conditions of the process hang. I could code something up, but; your question is the first response to this bug report since &quot;<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">reiko &lt;<a href="mailto:j.k.langridge at gmail.com" style="color: rgb(17, 65, 112); ">j.k.langridge at gmail.com</a>&gt;&quot; on 7/28/2008. I suggest it can be closed, and would be reopened when encountered again. I appears nobody is working in that area of code.??</span><br>

<br><div class="gmail_quote">On Wed, Jun 16, 2010 at 8:13 PM, Terry J. Reedy <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>
Terry J. Reedy &lt;<a href="mailto:tjreedy at udel.edu">tjreedy at udel.edu</a>&gt; added the comment:<br>
<br>
Should this be closed or is this still a problem in 2.7 (release candidate out now, final soon) or 3.1?<br>
<br>
----------<br>
nosy: +tjreedy<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/issue2475" target="_blank">http://bugs.python.org/issue2475</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Best regards,<br><br>Mike<br>
</div>

From report at bugs.python.org  Sat Jun 19 04:17:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 19 Jun 2010 02:17:27 +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: <1276913847.19.0.845404724031.issue8990@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Thomas' patch does more than just allow bytearray.  It allows any object that can present itself as a buffer with byte-size items.  It is a bit unfortunate that such method will end up being called "fromstring" in 3.x.    With string being unicode, this is hopelessly ambiguous. Is the string interpreted as array of bytes, UTF-8 style, 16 or 32-bit integers?  It would be much better to have frombuffer, and even better extendfrombuffer method with this functionality.

I am +1 on Terry's option 2.  It may be possible to optimize .extend to detect objects that support buffer interface and bypass iterator protocol.  Of course, when receiving array is not type 'b', extend and fromxyz are not the same, so maybe we should just rename fromunicode to fromstring and fromstring to frombytes?

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8990>
_______________________________________

From report at bugs.python.org  Sat Jun 19 05:09:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 19 Jun 2010 03:09:47 +0000
Subject: [issue8972] subprocess.list2cmdline doesn't quote the & character
In-Reply-To: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>
Message-ID: <1276916987.72.0.850298890981.issue8972@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The reason that Popen doesn't do "the obvious thing" with a list and shell=True is that it is far from obvious what the correct thing is to do, especially for windows.

Thanks for the revert, exarkun.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8972>
_______________________________________

From report at bugs.python.org  Sat Jun 19 05:19:04 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 19 Jun 2010 03:19:04 +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: <1276917544.76.0.76332890102.issue8990@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Whatever is done, I think a bytearray should be handled the same as bytes. It must be that they give the same result. In basic operations, I believe that bytearrays can *always* substitute for bytes. "Bytes and bytearray objects contain single bytes ? the former is immutable while the latter is a mutable sequence." For example:
>>> b'abc'.capitalize()
b'Abc'
>>> bytearray(b'abc').capitalize()
bytearray(b'Abc')

This, to me, implies that .fromstring should accept bytearray (though probably not general buffer objects). In 2.x, I understand .fromstring to initialize an array from machine bytes read into a string, but not .fromunicode. This is *not* a text method, and the result may vary for 2 and 4-byte unicode builds. So I can see that 3.x needs .fromstring(bytes) but not .fromunicode(string).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8990>
_______________________________________

From report at bugs.python.org  Sat Jun 19 05:21:17 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 19 Jun 2010 03:21:17 +0000
Subject: [issue2475] Popen.poll always returns None
In-Reply-To: <1206392349.51.0.854683862843.issue2475@psf.upfronthosting.co.za>
Message-ID: <1276917677.68.0.853126757029.issue2475@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2475>
_______________________________________

From report at bugs.python.org  Sat Jun 19 05:34:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 19 Jun 2010 03:34:15 +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: <1276918455.16.0.836029814452.issue8990@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> This, to me, implies that .fromstring should accept bytearray (though
> probably not general buffer objects). In 2.x, I understand .fromstring 
> to initialize an array from machine bytes read into a string, but not
> .fromunicode. This is *not* a text method, and the result may vary for 2
> and 4-byte unicode builds. So I can see that 3.x needs
>  .fromstring(bytes) but not .fromunicode(string).


No, fromunicode is still needed.  It is used to fill type 'u' array with unicode wide characters.  In 3.x unicode type was renamed to str and str to bytes, so fromunicode should become fromstring (or maybe fromstr to avoid confusion) and fromstring should become frombytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8990>
_______________________________________

From report at bugs.python.org  Sat Jun 19 05:46:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 19 Jun 2010 03:46:29 +0000
Subject: [issue5904] strftime docs do not explain locale affect on result
	string
In-Reply-To: <1241270739.12.0.286821632978.issue5904@psf.upfronthosting.co.za>
Message-ID: <1276919189.79.0.0628777841169.issue5904@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Victor, this is your chance to add French to Python docs!

----------
keywords: +easy
nosy: +belopolsky, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5904>
_______________________________________

From report at bugs.python.org  Sat Jun 19 06:36:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 19 Jun 2010 04:36:23 +0000
Subject: [issue6641] datetime.strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1276922183.88.0.483637794686.issue6641@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

PEP 8 says: ?If your public attribute name collides with a reserved keyword, append a single trailing underscore to your attribute name.  This is preferable to an abbreviation or corrupted spelling.? e.g. ?class_? is used for an HTML class. ?(However, notwithstanding this rule, 'cls' is the preferred spelling for any variable or argument which is known to be a class, especially the first argument to a class method.)? I?d like this recommendation to be followed, even if it?s in an internal function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Sat Jun 19 06:58:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 19 Jun 2010 04:58:03 +0000
Subject: [issue9026] [argparse] Subcommands not printed in the same order they
	were added
In-Reply-To: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za>
Message-ID: <1276923483.18.0.304391066673.issue9026@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the nice report and patch! I don?t know if Steven maintains argparse first in Python?s repository and then makes external releases or if he touches first his argparse repo and then Python?s, but if it?s the former, please generate your diff again from the top directory of the checkout (see http://www.python.org/dev/patches/).

Could you add tests too?

----------
nosy: +merwok
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9026>
_______________________________________

From report at bugs.python.org  Sat Jun 19 07:01:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 19 Jun 2010 05:01:50 +0000
Subject: [issue9023] distutils relative path errors
In-Reply-To: <1276850851.53.0.471987336824.issue9023@psf.upfronthosting.co.za>
Message-ID: <1276923710.74.0.360087874886.issue9023@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok
versions: +Python 3.2 -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9023>
_______________________________________

From report at bugs.python.org  Sat Jun 19 11:46:51 2010
From: report at bugs.python.org (Scott Tsai)
Date: Sat, 19 Jun 2010 09:46:51 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1276940811.92.0.52257867434.issue5639@psf.upfronthosting.co.za>


Changes by Scott Tsai <scottt.tw at gmail.com>:


----------
nosy: +scott.tsai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________

From report at bugs.python.org  Sat Jun 19 12:21:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Jun 2010 10:21:34 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1276942894.69.0.0293708514392.issue9009@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r82080: Whitespace fixes.
r82081: In strtod, simplify the computation of the initial approximation.
r82082: Fix typo introduced in r82025 (I think);  this was preventing
   a shortcut from being taken.

r82087: Simplify the ratio function.  The previous ratio function (actually, b2d), aborted if the numerator was zero, and the current code ends up requiring special cases for zero as a result of this.  That restriction is now removed, which will allow further simplifications (to come) in strtod.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Sat Jun 19 12:47:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Jun 2010 10:47:37 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1276944457.58.0.305966648326.issue9009@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Patch that does a fairly significant rewrite of strtod;  it's still (mostly) based on Gay's code, but there are some significant changes.

Some background:  strtod, after dealing with easy cases, works roughly as follows:

(1) Using floating-point arithmetic, create a double *rv* holding an approximation to the input value; this approximation may be out from the true value by several ulps (perhaps as much as 10 ulps;  certainly not more than 100 ulps).

(2) If the input string is very long, truncate it (accepting that this introduces a small error), and work with the truncated value below.

(3) Use integer arithmetic to compute (an approximation to) ulps difference between *rv* and true value.  Possibly return immediately if
the ulps difference can be proved to be <= 0.5 ulps, and we're not in any of various exceptional cases.

(4) Use the ulps difference to correct *rv* to a new value.

(5) If the ulps difference has fractional part close to 0.5, or if the correction takes us past a power of 2, or if it takes use near/to the max representable double, or to 0.0, go around the correction loop again.

(6) If we still can't decide (because the ulps difference is very close to 0.5), call bigcomp to settle the issue once and for all.


The new patch simplifies the above procedure considerably:

- scaling of rv is used for very large values as well as very small ones; this simplifies handling of overflow, meaning that there's only a single place where overflow has to be detected.

- the adjustment step handles adjustments that cross power-of-2 boundaries correctly.

- as a result of the above two simplifications, there's never any need to do a second correction step, so the main correction loop is no longer a loop; a single correction is performed.

- we always use the bigcomp function in hard cases, so there's no longer any need for the computation of ulps_difference to detect the case where the error is exactly 0.5 ulps.


The patch isn't quite ready to apply;  I want to expand some of the comments a little.

----------
Added file: http://bugs.python.org/file17720/rewrite_strtod.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Sat Jun 19 13:09:16 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 19 Jun 2010 11:09:16 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>
Message-ID: <1276945756.6.0.541320375603.issue9020@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Py_CHARMASK should return a non-negative integer. As I understand it:

tokenizer.c:tok_get around line 1368:

        while (Py_ISALNUM(c) || c == '_') {
            c = tok_nextc(tok);
        }


1) tok_nextc(tok) returns EOF (correct).

2) c is an int.

3) c == -1 gets passed to Py_ISALNUM(c):

   #define Py_ISALNUM(c)  (_Py_ctype_table[Py_CHARMASK(c)] & PY_CTF_ALNUM)



So either it should be enforced that only chars are passed to
Py_CHARMASK, or a cast for the EOF case is needed (but it should
be to (unsigned char)).


Sridhar, did I sum this up correctly?

----------
nosy: +skrah
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Sat Jun 19 13:52:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Jun 2010 11:52:34 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <AANLkTila7wm_4BPir7ffUqe9p0G9OZCz2hYGnMV_qOOt@mail.gmail.com>
Message-ID: <1276948348.3371.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le samedi 19 juin 2010 ? 00:55 +0000, geremy condra a ?crit :
> geremy condra <debatem1 at gmail.com> added the comment:
> 
> On Fri, Jun 18, 2010 at 6:05 AM, Antoine Pitrou <report at bugs.python.org> wrote:
> >
> > Antoine Pitrou <pitrou at free.fr> added the comment:
> >
> >> Great, I'm thinking more-or-less the API proposed in PEP 272- the
> >> exception I'm thinking of is that 'strings' should be substituted for
> >> 'bytes'- for AES and DES. It gets trickier when talking about public
> >> key crypto, though. Perhaps something along the lines of
> >> RSA.new(public_key=None, private_key=None,...), with the resulting
> >> object supporting encrypt/decrypt/sign/verify operations?
> >
> > I don't have any opinion right now. I think a concrete proposal should
> > be initiated and we can iterate from that.
> > (that's assuming other people agree on the principle, of course)
> 
> I assume that by "a concrete proposal" you're talking about code? Or
> API docs? Also, what more needs to be done to ensure that other people
> agree on the principle?

I was thinking about a PEP. Of course, you are free to reuse existing
PEP content for that :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sat Jun 19 13:56:03 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 19 Jun 2010 11:56:03 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276945756.6.0.541320375603.issue9020@psf.upfronthosting.co.za>
Message-ID: <4C1CB051.8000508@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Py_CHARMASK should return a non-negative integer.

And it does, also on AIX. Do we have proof to the contrary?

> tokenizer.c:tok_get around line 1368:
>
>          while (Py_ISALNUM(c) || c == '_') {
>              c = tok_nextc(tok);
>          }
>
>
> 1) tok_nextc(tok) returns EOF (correct).
>
> 2) c is an int.
>
> 3) c == -1 gets passed to Py_ISALNUM(c):
>
>     #define Py_ISALNUM(c)  (_Py_ctype_table[Py_CHARMASK(c)]&  PY_CTF_ALNUM)
>
>
>
> So either it should be enforced that only chars are passed to
> Py_CHARMASK, or a cast for the EOF case is needed (but it should
> be to (unsigned char)).

Why do you say that? If c is -1, then Py_CHARMASK(c) is 255, which is a
positive integer. Passing -1, or any other integer, to Py_CHARMASK is 
perfectly fine.

There seems to be a minor bug in the loop above, which doesn't actually 
break at EOF. Instead, it implicitly trusts that Py_ISALNUM(EOF) is 
false (because 255 is not alpha-numeric); this is a flaw - but that
shouldn't cause breakage on AIX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Sat Jun 19 14:05:02 2010
From: report at bugs.python.org (Christoph Burgmer)
Date: Sat, 19 Jun 2010 12:05:02 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1276949102.51.0.523745271021.issue1602@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

Will this bug be tackled or Python2.7?

And is there a way to get hold of the access denied error?

Here are my steps to reproduce:

I started the console with "cmd /u /k chcp 65001"
_______________________________________________________________________
Aktive Codepage: 65001.

C:\Dokumente und Einstellungen\root>set PYTHONIOENCODING=UTF-8

C:\Dokumente und Einstellungen\root>d:

D:\>cd Python31

D:\Python31>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.
>>> print("\u573a")
?
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 13] Permission denied
>>>
_______________________________________________________________________

I see a rectangle on screen but obviously c&p works.

----------
nosy: +christoph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sat Jun 19 14:09:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Jun 2010 12:09:58 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1276949398.62.0.611800508685.issue1602@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: unit test needed -> needs patch
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sat Jun 19 14:16:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Jun 2010 12:16:53 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>
Message-ID: <1276949813.63.0.9361433769.issue9020@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Why do you say that? If c is -1, then Py_CHARMASK(c) is 255, which is a
> positive integer.

What srid seems to be saying is that chars are unsigned on AIX, and therefore Py_CHARMASK() returns -1. Hence his patch proposal.

Of course, it is dubious why EOF is not tested separately rather than passing it to Py_ISALNUM(). Micro-optimization? At least a comment should be added.

Also, really, the Py_CHARMASK() macro seems poorly specified. It claims to "convert a possibly signed character to a nonnegative int", but this is wrong: it doesn't convert to an int at all. Furthermore, it does a cast in one branch but not in the other, which can give bad surprises as here.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Sat Jun 19 14:24:43 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 19 Jun 2010 12:24:43 +0000
Subject: [issue9020] Specification of Py_CHARMASK
In-Reply-To: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>
Message-ID: <1276950283.42.0.587403765048.issue9020@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

You can simulate this on Linux by compiling with:

  BASECFLAGS="-funsigned-char"

Then:

Index: Parser/tokenizer.c
===================================================================
--- Parser/tokenizer.c  (revision 81682)
+++ Parser/tokenizer.c  (working copy)
@@ -1366,6 +1366,8 @@
             break;
         }
         while (Py_ISALNUM(c) || c == '_') {
+            c = EOF; // tok_nextc can return EOF
+            printf("c: %d\n", Py_CHARMASK(c));
             c = tok_nextc(tok);
         }
         tok_backup(tok, c);



>>> eval("abcd")
c: -1
c: -1
c: -1
c: -1
c: -1
c: -1




Also, during compilation you get tons of warnings about using
char as an array subscript:

Objects/stringlib/split.h: In function ?stringlib_split_whitespace?:
Objects/stringlib/split.h:70: warning: array subscript has type ?char?
Objects/stringlib/split.h:74: warning: array subscript has type ?char?
Objects/stringlib/split.h:91: warning: array subscript has type ?char?

----------
title: 2.7: eval hangs on AIX -> Specification of Py_CHARMASK

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Sat Jun 19 14:48:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 19 Jun 2010 12:48:01 +0000
Subject: [issue9029] errors='replace' works in IDLE,
	fails at Windows command line.
In-Reply-To: <1276890229.73.0.493277821026.issue9029@psf.upfronthosting.co.za>
Message-ID: <1276951681.96.0.0963149365336.issue9029@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

What you show is not a complete program, nor do you provide the complete traceback or the data causing the problem.  The most helpful thing would be a complete small program and data file demonstrating the problem.  That said, I'm wondering if your problem is the encoding of the terminal window.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9029>
_______________________________________

From report at bugs.python.org  Sat Jun 19 15:00:59 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 19 Jun 2010 13:00:59 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276949813.63.0.9361433769.issue9020@psf.upfronthosting.co.za>
Message-ID: <4C1CBF87.8080003@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> What srid seems to be saying is that chars are unsigned on AIX, and
> therefore Py_CHARMASK() returns -1. Hence his patch proposal.

Ah, ok. I misread some of the messages (and got confused by msg108125,
which seems to suggest that chars are signed on AIX).

> Of course, it is dubious why EOF is not tested separately rather than
> passing it to Py_ISALNUM(). Micro-optimization? At least a comment
> should be added.

No, I think this is an error that EOF is not processed separately.
Otherwise, char 255 may be confused with EOF.

Of course, this would have to be done throughout.

> Also, really, the Py_CHARMASK() macro seems poorly specified. It
> claims to "convert a possibly signed character to a nonnegative int",
> but this is wrong: it doesn't convert to an int at all. Furthermore,
> it does a cast in one branch but not in the other, which can give bad
> surprises as here.

I think the specification is correct: it ought to convert to a
non-negative int. In the signed char case, it already returns an int.
So if it is changed at all, it needs to be changed, in the unsigned
case, to

#define  Py_CHARMASK(c)		((int)(c))

----------
title: Specification of Py_CHARMASK -> 2.7: eval hangs on AIX

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Sat Jun 19 15:15:00 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 19 Jun 2010 13:15:00 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <4C1CBF87.8080003@v.loewis.de>
Message-ID: <20100619131453.GA16155@yoda.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Martin v. L?wis <report at bugs.python.org> wrote:
> > Of course, it is dubious why EOF is not tested separately rather than
> > passing it to Py_ISALNUM(). Micro-optimization? At least a comment
> > should be added.
> 
> No, I think this is an error that EOF is not processed separately.
> Otherwise, char 255 may be confused with EOF.

Indeed. I think Py_ISALNUM() should check for EOF, to be consistent
with the C isalnum(int c).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Sat Jun 19 15:18:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 19 Jun 2010 13:18:22 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1276953502.63.0.102400962041.issue7989@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Brett's assertion comes from the decision made at the language summit at the last pycon. Which does not negate Raymond's assertion that there may be more important stuff to pythonize. However, Alexander is maintaining datetime, and if he wishes to do the Python version there is no reason I see for him not to do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Sat Jun 19 15:25:58 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 19 Jun 2010 13:25:58 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <20100619131453.GA16155@yoda.bytereef.org>
Message-ID: <4C1CC562.1060906@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Indeed. I think Py_ISALNUM() should check for EOF, to be consistent
> with the C isalnum(int c).

Ah, that sounds fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Sat Jun 19 15:50:07 2010
From: report at bugs.python.org (Chris McDonough)
Date: Sat, 19 Jun 2010 13:50:07 +0000
Subject: [issue1573931] WSGI, cgi.FieldStorage incompatibility
Message-ID: <1276955407.62.0.89046317196.issue1573931@psf.upfronthosting.co.za>


Chris McDonough <chrism at plope.com> added the comment:

<Review prompted by "500 tracker orphans; need more reviewers">

Although the current WSGI 1.0 spec (http://www.python.org/dev/peps/pep-0333/) still indicates that implementing the size argument to readline is not required, effectively, it is and has been for several years.  Stalling on a WSGI 1.1 spec has caused a spec change to be delayed.  See also http://www.mail-archive.com/web-sig at python.org/msg02494.html

----------
nosy: +mcdonc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1573931>
_______________________________________

From report at bugs.python.org  Sat Jun 19 15:57:34 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 19 Jun 2010 13:57:34 +0000
Subject: [issue1573931] WSGI, cgi.FieldStorage incompatibility
Message-ID: <1276955854.95.0.520852777519.issue1573931@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

It's not terribly productive to block a fix for this specific issue in the WSGI specification on the big pile of contentious unrelated issues.

It would make sense to issue a new WSGI specification with a correction for only this issue.  The rest of the WSGI 1.1 issues can wait for a subsequent revision.

Of course, actually getting this done involves either getting web-sig behind it or deciding to ignore web-sig and just do it.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1573931>
_______________________________________

From report at bugs.python.org  Sat Jun 19 16:27:41 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 19 Jun 2010 14:27:41 +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: <1276957661.45.0.644806185284.issue9031@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

It's a duplicate of issue #1222585. The patch in that issue will also make distutils not reuse flags Python was built with.

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9031>
_______________________________________

From report at bugs.python.org  Sat Jun 19 16:47:57 2010
From: report at bugs.python.org (gonegown)
Date: Sat, 19 Jun 2010 14:47:57 +0000
Subject: [issue8988] import + coding = failure (3.1.2/win32)
In-Reply-To: <1276426235.15.0.873898512927.issue8988@psf.upfronthosting.co.za>
Message-ID: <1276958877.83.0.866978547596.issue8988@psf.upfronthosting.co.za>


gonegown <nomedocac at gmail.com> added the comment:

Is there py3k for win32?
And how do I know if #8611 comes from the same source?
Have no idea how they have organized the python core. I'm new to python (about 2 months) and I don't think I will use it for long. It's just not serious.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8988>
_______________________________________

From report at bugs.python.org  Sat Jun 19 17:10:16 2010
From: report at bugs.python.org (scott riccardelli)
Date: Sat, 19 Jun 2010 15:10:16 +0000
Subject: [issue9033] cmd module tab misbehavior
In-Reply-To: <1276960216.2.0.17858038653.issue9033@psf.upfronthosting.co.za>
Message-ID: <1276960216.2.0.17858038653.issue9033@psf.upfronthosting.co.za>


New submission from scott riccardelli <s.riccardelli at gmail.com>:

noticed that cmd module does not perform completion using TAB on a macintosh properly.  instead, the TAB key just places several blank spaces and moves the cursor forward.  what it should do is retrieve a list of possibilities for completing a command.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 108185
nosy: ronaldoussoren, slcott
priority: normal
severity: normal
status: open
title: cmd module tab misbehavior
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9033>
_______________________________________

From report at bugs.python.org  Sat Jun 19 17:24:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Jun 2010 15:24:10 +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: <1276961050.88.0.917548125508.issue8990@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

On the principle the patch looks good. In practice, it lacks a call to `PyBuffer_Release(&buffer)` in the various error cases (before returning NULL). It also lacks some tests in Lib/test/test_array.py.

> In 3.x unicode type was renamed to str and str to bytes, so fromunicode 
> should become fromstring (or maybe fromstr to avoid confusion) and
> fromstring should become frombytes.

This should be discussed separately, perhaps on python-dev first.

----------
nosy: +haypo, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8990>
_______________________________________

From report at bugs.python.org  Sat Jun 19 18:41:55 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Jun 2010 16:41:55 +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: <1276965715.82.0.588963682029.issue2636@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Jun 19 19:05:46 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 19 Jun 2010 17:05:46 +0000
Subject: [issue4883] Compiling python 2.5.2 under Wine on linux.
In-Reply-To: <1231431218.3.0.0118570431179.issue4883@psf.upfronthosting.co.za>
Message-ID: <1276967146.79.0.706704604082.issue4883@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Can this be closed as out of date, or is it still relevant to Python 2.7 or any of the Python 3 branches?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4883>
_______________________________________

From report at bugs.python.org  Sat Jun 19 19:47:40 2010
From: report at bugs.python.org (Andrew Moise)
Date: Sat, 19 Jun 2010 17:47:40 +0000
Subject: [issue1300] subprocess.list2cmdline doesn't do pipe symbols
In-Reply-To: <1192729254.96.0.285794085895.issue1300@psf.upfronthosting.co.za>
Message-ID: <1276969660.52.0.892831393347.issue1300@psf.upfronthosting.co.za>


Andrew Moise <chops at demiurgestudios.com> added the comment:

Why is this bug invalid?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1300>
_______________________________________

From report at bugs.python.org  Sat Jun 19 19:51:29 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 19 Jun 2010 17:51:29 +0000
Subject: [issue1300] subprocess.list2cmdline doesn't do pipe symbols
In-Reply-To: <1192729254.96.0.285794085895.issue1300@psf.upfronthosting.co.za>
Message-ID: <1276969889.89.0.618236474495.issue1300@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

See the commit message for r82075 and the discussion on issue8972 and issue7839.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1300>
_______________________________________

From report at bugs.python.org  Sat Jun 19 19:53:24 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 19 Jun 2010 17:53:24 +0000
Subject: [issue5136] Deprecating (and removing) "globalcall",
	"merge" and "globaleval"
In-Reply-To: <1233623088.62.0.412008570682.issue5136@psf.upfronthosting.co.za>
Message-ID: <1276970004.88.0.0562657685598.issue5136@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

>From the recent large thread on c.l.py regarding Python GUIs I understand that the author of this issue Guilherme Polo has done a massive amount of work on Tkinter.  Would it therefore be possible for him to give an update as to whether this issue can be closed as out of date, already actioned but not recorded, or whatever?  Thanks.

There are several other issues raised by Guilherme Polo regarding Tkinter, sorry I'm too lazy to repeat this comment on all of them.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5136>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:08:51 2010
From: report at bugs.python.org (Andrew Moise)
Date: Sat, 19 Jun 2010 18:08:51 +0000
Subject: [issue1300] subprocess.list2cmdline doesn't do pipe symbols
In-Reply-To: <1192729254.96.0.285794085895.issue1300@psf.upfronthosting.co.za>
Message-ID: <1276970931.95.0.204640572636.issue1300@psf.upfronthosting.co.za>


Andrew Moise <chops at demiurgestudios.com> added the comment:

Hm, I'm not sure I understand.  After r82075, will list2cmdline(['echo', 'foo|bar']) return 'echo foo|bar', or will it return 'echo "foo|bar"'?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1300>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:11:04 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 19 Jun 2010 18:11:04 +0000
Subject: [issue4849] instantiating and populating xml.dom.minidom.Element is
	cumbersome
In-Reply-To: <1231182515.38.0.572857860756.issue4849@psf.upfronthosting.co.za>
Message-ID: <1276971064.32.0.338599413658.issue4849@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

As you Jean-Paul Calderone seem to know what you're talking about could you provide a patch to get this issue going?  If not I might even have a go myself, even if I do get shot down in flames.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4849>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:15:43 2010
From: report at bugs.python.org (Joseph)
Date: Sat, 19 Jun 2010 18:15:43 +0000
Subject: [issue8820] IDLE not launching correctly
In-Reply-To: <1274842084.45.0.257196773636.issue8820@psf.upfronthosting.co.za>
Message-ID: <1276971343.17.0.590714070633.issue8820@psf.upfronthosting.co.za>


Joseph <joseph.a.marlin at gmail.com> added the comment:

I'm using python version 2.6.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8820>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:16:35 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 19 Jun 2010 18:16:35 +0000
Subject: [issue1300] subprocess.list2cmdline doesn't do pipe symbols
In-Reply-To: <1192729254.96.0.285794085895.issue1300@psf.upfronthosting.co.za>
Message-ID: <1276971395.46.0.999747214136.issue1300@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

It will return the former.

To clarify, it's true that there appears to be a problem with Popen(['echo', 'foo|bar'], shell=True).  That is being tracked in issue7839.

What's invalid is the report that list2cmdline() should be quoting strings with | in them.  list2cmdline() is documented as being an implementation of the quoting convention implemented by the MS C runtime.  That quoting convention does not require | to be quoted.

It's cmd.exe which requires | to be quoted (if it is to be part of an argument value, rather than to indicate a command pipeline of some sort).  cmd.exe quoting rules need to be addressed separately from the MS C quoting rules used even if cmd.exe isn't involved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1300>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:17:01 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 19 Jun 2010 18:17:01 +0000
Subject: [issue4919] 2.6.1 build issues on solaris with SunStudio 12
In-Reply-To: <1231751691.61.0.918589692105.issue4919@psf.upfronthosting.co.za>
Message-ID: <1276971421.88.0.166912396387.issue4919@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Can this be closed as out of date or is it still an issue with Python 2.7 or any of the Python 3 versions?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4919>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:18:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 19 Jun 2010 18:18:18 +0000
Subject: [issue9033] cmd module tab misbehavior
In-Reply-To: <1276960216.2.0.17858038653.issue9033@psf.upfronthosting.co.za>
Message-ID: <1276971498.27.0.452095357383.issue9033@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your report. Does the readline module work at all?

2.5 is unsupported now; can you test your code with 2.7, the next stable version?

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9033>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:19:27 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Jun 2010 18:19:27 +0000
Subject: [issue4883] Compiling python 2.5.2 under Wine on linux.
In-Reply-To: <1231431218.3.0.0118570431179.issue4883@psf.upfronthosting.co.za>
Message-ID: <1276971567.23.0.480908141013.issue4883@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It can be closed.  Thanks!

----------
nosy: +mark.dickinson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4883>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:23:03 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 19 Jun 2010 18:23:03 +0000
Subject: [issue4883] Compiling python 2.5.2 under Wine on linux.
In-Reply-To: <1276971567.23.0.480908141013.issue4883@psf.upfronthosting.co.za>
Message-ID: <17119.80548.qm@web23303.mail.ird.yahoo.com>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Hi Mark,

It'll cost you a couple of pints of Ringwood Old Thumper if you're ever in my neck of the woods.

Also blame Terry Reedy if I prove to be a pain in the neck!!!

Kindest regards.

Mark Lawrence.

________________________________
From: Mark Dickinson <report at bugs.python.org>
To: breamoreboy at yahoo.co.uk
Sent: Sat, 19 June, 2010 19:19:27
Subject: [issue4883] Compiling python 2.5.2 under Wine on linux.

Mark Dickinson <dickinsm at gmail.com> added the comment:

It can be closed.  Thanks!

----------
nosy: +mark.dickinson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4883>
_______________________________________

----------
Added file: http://bugs.python.org/file17721/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4883>
_______________________________________
-------------- 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>Hi Mark,<br><br>It'll cost you a couple of pints of Ringwood Old Thumper if you're ever in my neck of the woods.<br><br>Also blame Terry Reedy if I prove to be a pain in the neck!!!<br><br>Kindest regards.<br><br>Mark Lawrence.<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> Mark Dickinson &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> Sat, 19 June, 2010 19:19:27<br><b><span style="font-weight: bold;">Subject:</span></b> [issue4883] Compiling python 2.5.2 under Wine on
 linux.<br></font><br><br>Mark Dickinson &lt;<a ymailto="mailto:dickinsm at gmail.com" href="mailto:dickinsm at gmail.com">dickinsm at gmail.com</a>&gt; added the comment:<br><br>It can be closed.&nbsp; Thanks!<br><br>----------<br>nosy: +mark.dickinson<br>resolution:&nbsp; -&gt; out of date<br>status: open -&gt; closed<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/issue4883" target="_blank">http://bugs.python.org/issue4883</a>&gt;<br>_______________________________________<br></div></div>
</div><br>



      </body></html>

From report at bugs.python.org  Sat Jun 19 20:32:49 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 19 Jun 2010 18:32:49 +0000
Subject: [issue4629] getopt should not accept no_argument that ends with '='
In-Reply-To: <1228978458.01.0.0804138423997.issue4629@psf.upfronthosting.co.za>
Message-ID: <1276972369.33.0.710385512579.issue4629@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I'm not sure why this is still open, would somebody like to comment, see also Issue4650.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4629>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:32:51 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 19 Jun 2010 18:32:51 +0000
Subject: [issue9033] cmd module tab misbehavior
In-Reply-To: <1276960216.2.0.17858038653.issue9033@psf.upfronthosting.co.za>
Message-ID: <1276972371.37.0.0984677606345.issue9033@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

It seems readline module is not installed on your system. 
Quoting Ned Deily's comment from issue8365 which will most probably solve your issue:
"Issue6877 (and subsequent fixes in Issue8066) allows the Python readline module to be built and linked with the OS X editline (libedit) library rather than with the GNU readline library (which is not included with OS X).  However, the libedit included in versions of OS X prior to 10.5 is considered too broken to use here.

By default, if you do not specify an --with-universal-archs other than "32-bit" to configure or if you do not explicitly set MACOSX_DEPLOYMENT_TARGET to another value, configure defaults to using "10.4" (or earlier) so the building of the readline module is skipped.  You can check this:

>>> from distutils.sysconfig import get_config_var 
>>> get_config_var('MACOSX_DEPLOYMENT_TARGET')
'10.4'

(Whether this is the best default is another question.)

As it stands, to be able to build the readline module, either:

(1) supply the GNU readline library as a local library, or

(2) ensure you are building with a deployment target of at least 10.5.  For example:

    ./configure MACOSX_DEPLOYMENT_TARGET=10.6 ; make

Also note that option (2) is not available for 3.1.x since the changes to support editline/libedit were not ported to it; they are, however, in 2.6.5, 2.7 (trunk), and 3.2 (py3k)"

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9033>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:33:36 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 19 Jun 2010 18:33:36 +0000
Subject: [issue9033] cmd module tab misbehavior
In-Reply-To: <1276960216.2.0.17858038653.issue9033@psf.upfronthosting.co.za>
Message-ID: <1276972416.38.0.265328397412.issue9033@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9033>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:36:09 2010
From: report at bugs.python.org (Andrew Moise)
Date: Sat, 19 Jun 2010 18:36:09 +0000
Subject: [issue1300] subprocess.list2cmdline doesn't do pipe symbols
In-Reply-To: <1192729254.96.0.285794085895.issue1300@psf.upfronthosting.co.za>
Message-ID: <1276972569.08.0.211876290291.issue1300@psf.upfronthosting.co.za>


Andrew Moise <chops at demiurgestudios.com> added the comment:

Okay, makes sense.  It sure would be nice on Windows to have an equivalent of list2cmdline() that works for the shell.  I actually don't have immediate access to the code anymore, but I remember having to fool around with list2cmdline in the first place because it was difficult to do what I wanted without passing things through the shell (maybe I was spawning a process on Windows and capturing input/output/stderr; I don't remember in detail).

Maybe the solution is to make what I was trying to do easier without fooling with the shell instead of playing the fool's game of trying to improve the ability to deal with the shell so we can pass things through it unnecessarily.

Anyway, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1300>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:38:19 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 19 Jun 2010 18:38:19 +0000
Subject: [issue4654] os.path.realpath() get the wrong result
In-Reply-To: <1229158060.01.0.633699238594.issue4654@psf.upfronthosting.co.za>
Message-ID: <1276972699.82.0.783222578788.issue4654@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

An issue with Python 2.3, can this be closed or is it still a problem with Python 2.7 or any of the Python 3 versions?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4654>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:40:38 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 19 Jun 2010 18:40:38 +0000
Subject: [issue8820] IDLE not launching correctly
In-Reply-To: <1274842084.45.0.257196773636.issue8820@psf.upfronthosting.co.za>
Message-ID: <1276972838.65.0.83890203488.issue8820@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +kbk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8820>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:41:06 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 19 Jun 2010 18:41:06 +0000
Subject: [issue8820] IDLE not launching correctly
In-Reply-To: <1274842084.45.0.257196773636.issue8820@psf.upfronthosting.co.za>
Message-ID: <1276972866.67.0.918687653807.issue8820@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8820>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:42:03 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 19 Jun 2010 18:42:03 +0000
Subject: [issue4654] os.path.realpath() get the wrong result
In-Reply-To: <1229158060.01.0.633699238594.issue4654@psf.upfronthosting.co.za>
Message-ID: <1276972923.51.0.238684431868.issue4654@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +l0nwlf, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4654>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:45:25 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 19 Jun 2010 18:45:25 +0000
Subject: [issue5005] 3.0 sqlite doc: most examples refer to pysqlite2,
	use 2.x syntax.
In-Reply-To: <1232406910.8.0.623178386993.issue5005@psf.upfronthosting.co.za>
Message-ID: <1276973125.78.0.035210015676.issue5005@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I'm guessing that this is fixed and hence can be closed as google didn't throw anything obvious at me, am I correct?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5005>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:46:17 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Jun 2010 18:46:17 +0000
Subject: [issue4654] os.path.realpath() get the wrong result
In-Reply-To: <1229158060.01.0.633699238594.issue4654@psf.upfronthosting.co.za>
Message-ID: <1276973177.36.0.539286692273.issue4654@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/issue4654>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:51:37 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 19 Jun 2010 18:51:37 +0000
Subject: [issue1479626] Uninstall does not clean registry
Message-ID: <1276973497.28.0.230790529266.issue1479626@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Wouldn't be the first Windows uninstaller to leave junk in the registry and won't be the last.  if this is going to be actioned versions need to be updated to Python 2.7, thinking realistically of 2.7.1, and Python 3.2+?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1479626>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:54:48 2010
From: report at bugs.python.org (Devin Cook)
Date: Sat, 19 Jun 2010 18:54:48 +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: <1276973688.18.0.18716716547.issue1589@psf.upfronthosting.co.za>


Changes by Devin Cook <devin.c.cook at gmail.com>:


----------
nosy: +devin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Sat Jun 19 20:58:35 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 19 Jun 2010 18:58:35 +0000
Subject: [issue4654] os.path.realpath() get the wrong result
In-Reply-To: <1229158060.01.0.633699238594.issue4654@psf.upfronthosting.co.za>
Message-ID: <1276973915.66.0.420605987229.issue4654@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

No such issue on python 2.6, 2.7, 3.2.

>>> print(os.path.realpath('/Users/l0nwlf/Desktop/tmp/../decotest.lnk'))
/Users/l0nwlf/Desktop/decotest.lnk
I think this issue can be closed.
However, I came with a different issue while testing on 2.6, trunk and 3.2.

>>> print(os.path.realpath('~/Desktop/tmp/../decotest.lnk'))
/Volumes/CoreHD/py3k/~/Desktop/decotest.lnk

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4654>
_______________________________________

From report at bugs.python.org  Sat Jun 19 21:00:39 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 19 Jun 2010 19:00:39 +0000
Subject: [issue1778410] removeTest() method patch for unittest.TestSuite
Message-ID: <1276974039.85.0.626639016214.issue1778410@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

This is almost three years old but strikes me as being useful.  Could somebody with more knowledge than myself review the patch and update the relevant Python versions?  Failing that, simply close the issue as not being relevant today.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1778410>
_______________________________________

From report at bugs.python.org  Sat Jun 19 21:59:23 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 19 Jun 2010 19:59:23 +0000
Subject: [issue5005] 3.0 sqlite doc: most examples refer to pysqlite2,
	use 2.x syntax.
In-Reply-To: <1232406910.8.0.623178386993.issue5005@psf.upfronthosting.co.za>
Message-ID: <1276977563.92.0.524133529679.issue5005@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This issue is about the examples in 
11.6.1. Module functions and constants.
All 3 points are fixed.
The indentation issue seems to have been fixed by making the blank line completely blank with no spaces. I would have removed it, but cut and paste now works.

I have no idea what Google has to do with this, but thanks for pinging it.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
resolution:  -> fixed
status: open -> closed
type:  -> behavior
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5005>
_______________________________________

From report at bugs.python.org  Sat Jun 19 22:00:55 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 19 Jun 2010 20:00:55 +0000
Subject: [issue9018] os.path.normcase(None) does not raise an error on linux
	and should
In-Reply-To: <1276782016.7.0.192519527211.issue9018@psf.upfronthosting.co.za>
Message-ID: <1276977655.35.0.854993397938.issue9018@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Following the documentation,
os.path.normcase(path)
Normalize the case of a pathname. On Unix and Mac OS X, this returns the path unchanged; on case-insensitive filesystems, it converts the path to lowercase. On Windows, it also converts forward slashes to backward slashes.

on Mac OS X,
>>> import os
>>> os.name
'posix'

Checking through, Lib/posixpath.py,

# Normalize the case of a pathname.  Trivial in Posix, string.lower on Mac.
# On MS-DOS this may also turn slashes into backslashes; however, other
# normalizations (such as optimizing '../' away) are not allowed                
# (another function should be defined to do that).

def normcase(s):
    """Normalize case of pathname.  Has no effect under Posix"""
    # TODO: on Mac OS X, this should really return s.lower().
    return s

Why on Mac OS X, it should return s.lower() ?
Also to raise Error for None case we can probably change normcase() in Lib/posixpath.py as,

def normcase(s):
    """Normalize case of pathname.  Has no effect under Posix"""
    if s is None:  
        raise AttributeError
    return s

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9018>
_______________________________________

From report at bugs.python.org  Sat Jun 19 22:42:37 2010
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 19 Jun 2010 20:42:37 +0000
Subject: [issue9026] [argparse] Subcommands not printed in the same order they
	were added
In-Reply-To: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za>
Message-ID: <1276980157.07.0.994148587148.issue9026@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Yes, please generate patches from the Python repository.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9026>
_______________________________________

From report at bugs.python.org  Sat Jun 19 22:46:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 19 Jun 2010 20:46:03 +0000
Subject: [issue9026] [argparse] Subcommands not printed in the same order they
	were added
In-Reply-To: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za>
Message-ID: <1276980363.58.0.070875410353.issue9026@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Guidelines: http://www.python.org/dev/patches/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9026>
_______________________________________

From report at bugs.python.org  Sat Jun 19 23:36:09 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jun 2010 21:36:09 +0000
Subject: [issue5969] setup build with Platform SDK, finding vcvarsall.bat
In-Reply-To: <1241791427.1.0.931613951559.issue5969@psf.upfronthosting.co.za>
Message-ID: <1276983369.89.0.37270940851.issue5969@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> msvc9compiler.py: ValueError: [u'path']

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5969>
_______________________________________

From report at bugs.python.org  Sat Jun 19 23:36:43 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Jun 2010 21:36:43 +0000
Subject: [issue5972] Failing test_signal.py on Redhat 4.1.2-44
In-Reply-To: <1241817614.78.0.115572621899.issue5972@psf.upfronthosting.co.za>
Message-ID: <1276983403.84.0.894616162694.issue5972@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Closing for lack of response.

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5972>
_______________________________________

From report at bugs.python.org  Sat Jun 19 23:46:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 19 Jun 2010 21:46:10 +0000
Subject: [issue9005] Year range in timetuple
In-Reply-To: <1276660627.85.0.364876080456.issue9005@psf.upfronthosting.co.za>
Message-ID: <1276983970.22.0.631868998489.issue9005@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
keywords: +patch
Added file: http://bugs.python.org/file17722/issue9005.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9005>
_______________________________________

From report at bugs.python.org  Sat Jun 19 23:46:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 19 Jun 2010 21:46:25 +0000
Subject: [issue9005] Year range in timetuple
In-Reply-To: <1276660627.85.0.364876080456.issue9005@psf.upfronthosting.co.za>
Message-ID: <1276983985.19.0.732489294524.issue9005@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9005>
_______________________________________

From report at bugs.python.org  Sun Jun 20 00:14:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Jun 2010 22:14:15 +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: <1276985655.04.0.643445903194.issue8524@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I have tried refactoring the ssl code in order not to inherit from socket anymore, but it turned out suboptimal because chunks of code from the socket class then have to be duplicated.

Therefore, I instead propose a much simpler approach which is to add a forget() method to socket objects; this method "closes" the socket object (sets the internal fd to -1) without closing the underlying fd at all. This allows to create another socket (actually SSLSocket) from the same fd without having to dup() it.

Here is a patch; if the principle is accepted, I will add tests and docs.

----------
keywords: +patch
nosy: +loewis
Added file: http://bugs.python.org/file17723/sockforget.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8524>
_______________________________________

From report at bugs.python.org  Sun Jun 20 00:25:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 19 Jun 2010 22:25:57 +0000
Subject: [issue8939] Use C type names (PyUnicode etc;) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276986357.93.0.943475968803.issue8939@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Shouldn?t ?inside a :ctype:`Py_BEGIN_ALLOW_THREADS` block? rather use ?:cmacro:??

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8939>
_______________________________________

From report at bugs.python.org  Sun Jun 20 00:36:17 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 19 Jun 2010 22:36:17 +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: <1276986977.89.0.789125066338.issue8524@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

It might be nice to see the version that avoids the dup() and has the duplicate code instead (interesting trade-off ;).  Just for the sake of comparison against the forget() proposal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8524>
_______________________________________

From report at bugs.python.org  Sun Jun 20 00:54:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 19 Jun 2010 22:54:47 +0000
Subject: [issue4654] os.path.realpath() get the wrong result
In-Reply-To: <1229158060.01.0.633699238594.issue4654@psf.upfronthosting.co.za>
Message-ID: <1276988087.79.0.922684213409.issue4654@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Your different issue looks like a correct result to me.  ~ is not automatically expanded.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4654>
_______________________________________

From report at bugs.python.org  Sun Jun 20 01:12:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 19 Jun 2010 23:12:24 +0000
Subject: [issue9008] CGIHTTPServer support for arbitrary CGI scripts
In-Reply-To: <1276683224.45.0.0857224786266.issue9008@psf.upfronthosting.co.za>
Message-ID: <1276989144.78.0.652862171267.issue9008@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m sorry to have launched this thread. I hadn?t thought that Senthil
is doing a lot of good work on HTTP and URI-related modules, and I wanted
to express my feeling that this bug would not get fixed without someone
proposing a patch. I didn?t want to imply that the request was not valid
nor to discourage bug reporters. If I did, I sincerely apologize.

To address the issues Anatoly raised before I stop being off-topic:

1) Patch submission: You can already use Mercurial to prepare patches
(bare Mercurial, MQ or pbranch, on top of a Subversion checkout or
Mercurial clone (code.python.org/hg, kindly maintained by Antoine).

2) No maintainer for CGI: The term ?maintainer? is explained at the top of
the Misc/maintainers.rst file, it means a core developer taking special
care of one area or module. All core developpers are collectively
maintaining the whole stdlib; a module without a dedicated maintainer is
*not* unmaintained.

3) Nothing better than CGI in stdlib: BaseHTTPServer is handy for quick
testing; wsgiref is okay for quick testing of WSGI applications.
Third-party servers have different design goals and advantages for various
classes of users.

4) The header thing is a bug; I?ll search whether it?s already reported.

5) Current workflow seems good to the vast majority of contributors. I?ve
been contributing for a few months and found the workflow reasonable and
working, like a lot of people. That said, a Web UI for doc changes with
live preview may be a good way to let non-programmers propose fixes;
please open a feature request on Sphinx? tracker (on Bitbucket) or ask for
opinions on docs at python.org. Again, we?re all volunteers here, so ?you
should do X? works a lot less than ?I want to do X?.

I hope I have provided some hints and data points; I do not wish this
off-topic discussion to continue. Like Antoine said, we now understand your
viewpoint, and your suggestions for improvement would be more fruitful on
relevant mailing lists. Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9008>
_______________________________________

From report at bugs.python.org  Sun Jun 20 01:17:37 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 19 Jun 2010 23:17:37 +0000
Subject: [issue4654] os.path.realpath() get the wrong result
In-Reply-To: <1229158060.01.0.633699238594.issue4654@psf.upfronthosting.co.za>
Message-ID: <1276989457.01.0.160980354718.issue4654@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

By different issue I meant expected but non-useful output. 
Although it does exactly what it is supposed to do, but expanding tilde (~) to $HOME could have been the default behavior(more user-friendly I should say). Don't know if that is worth it but the scale seems more on the negative side.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4654>
_______________________________________

From report at bugs.python.org  Sun Jun 20 01:32:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 19 Jun 2010 23:32:46 +0000
Subject: [issue4654] os.path.realpath() get the wrong result
In-Reply-To: <1229158060.01.0.633699238594.issue4654@psf.upfronthosting.co.za>
Message-ID: <1276990366.23.0.133894306037.issue4654@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I can confirm this works correctly on 32 bit Linux under 2.6.4.  Since it is unlikely the width matters to this issue I'm going to close it. If anyone has a case where it fails we can reopen.

----------
resolution:  -> out of date
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4654>
_______________________________________

From report at bugs.python.org  Sun Jun 20 01:35:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 19 Jun 2010 23:35:10 +0000
Subject: [issue4654] os.path.realpath() get the wrong result
In-Reply-To: <1229158060.01.0.633699238594.issue4654@psf.upfronthosting.co.za>
Message-ID: <1276990510.01.0.933456353995.issue4654@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Somebody long ago made the decision that ~ is only expanded if you call expanduser.  I don't think this decision is likely to get changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4654>
_______________________________________

From report at bugs.python.org  Sun Jun 20 01:36:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 19 Jun 2010 23:36:03 +0000
Subject: [issue4654] os.path.realpath() get the wrong result
In-Reply-To: <1229158060.01.0.633699238594.issue4654@psf.upfronthosting.co.za>
Message-ID: <1276990563.31.0.111866886285.issue4654@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4654>
_______________________________________

From report at bugs.python.org  Sun Jun 20 03:29:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 20 Jun 2010 01:29:20 +0000
Subject: [issue9005] Year range in timetuple
In-Reply-To: <1276660627.85.0.364876080456.issue9005@psf.upfronthosting.co.za>
Message-ID: <1276997360.85.0.771501522366.issue9005@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Note that a recently closed issue 7150 similarly tightened up datetime operations by making out of range dates raise OverflowError rather than produce non-sensible result.  This case is not a clear cut, but now with timezone.utc available in datetime module, I believe users should be encouraged to use t.astimezone(timezone.utc) to produce UTC time.  If timetuple is required the later can be converted using timetuple() method.  Idelally, t.utctimetuple() should be deprecated in favor of more explicit t.astimezone(timezone.utc).timetuple().  Unfortunately the two expressions are subtly different because 

>>> t = datetime.max.replace(tzinfo=timezone.min)
>>> t.astimezone(timezone.utc)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: date value out of range

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9005>
_______________________________________

From report at bugs.python.org  Sun Jun 20 03:35:09 2010
From: report at bugs.python.org (Timothy Farrell)
Date: Sun, 20 Jun 2010 01:35:09 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1276997709.88.0.225459472318.issue4953@psf.upfronthosting.co.za>


Timothy Farrell <tfarrell at swgen.com> added the comment:

Yes, they are related but not quite the same.  The solution to this problem will likely include a fix to the problem described in issue 8077.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Sun Jun 20 03:44:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 20 Jun 2010 01:44:18 +0000
Subject: [issue9034] datetime module should use int32_t for date/time
	components
In-Reply-To: <1276998258.21.0.743259532258.issue9034@psf.upfronthosting.co.za>
Message-ID: <1276998258.21.0.743259532258.issue9034@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

"""
As an aside, I dislike the fact that the datetime module uses a C 'int' for date ordinals, and clearly assumes that it'll be at least 32 bits.  int could be as small as 16 bits on some systems (small embedded systems?).  But that's another issue.
""" -- Mark Dickinson 

A comment and an assertion at the top of the module suggest that this was deliberate.

/* We require that C int be at least 32 bits, and use int virtually                                                                                  
 * everywhere.  In just a few cases we use a temp long, where a Python                                                                               
 * API returns a C long.  In such cases, we have to ensure that the                                                                                  
 * final result fits in a C int (this can be an issue on 64-bit boxes).                                                                              
 */
#if SIZEOF_INT < 4
#       error "datetime.c requires that C int have at least 32 bits"
#endif

However, since ranges of all integers are well defined in this module, there is little to be gained from the uncertainty about sizes of int and long. (For example, the allowed range of dates will not magically increase on a platform with 64 bit ints.)

I propose using explicitly sized C99 types int32_t and int64_t or rather their blessed for use in python equivalents PY_INTXX_T) throughout the module.

----------
assignee: belopolsky
components: Extension Modules
messages: 108222
nosy: belopolsky, mark.dickinson
priority: low
severity: normal
stage: needs patch
status: open
title: datetime module should use int32_t for date/time components
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9034>
_______________________________________

From report at bugs.python.org  Sun Jun 20 06:30:04 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 20 Jun 2010 04:30:04 +0000
Subject: [issue8996] Add a default role to allow writing bare `len` instead of
	:func:`len`
In-Reply-To: <1276528152.92.0.60611534239.issue8996@psf.upfronthosting.co.za>
Message-ID: <1277008204.22.0.948873360904.issue8996@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

-1 I like how explicit it is now.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8996>
_______________________________________

From report at bugs.python.org  Sun Jun 20 08:30:45 2010
From: report at bugs.python.org (geremy condra)
Date: Sun, 20 Jun 2010 06:30:45 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276948348.3371.0.camel@localhost.localdomain>
Message-ID: <AANLkTil6RDoE6R9ZMUrLkfuFpDhS7XklDz4vJcYnQxRv@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Sat, Jun 19, 2010 at 7:52 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Le samedi 19 juin 2010 ? 00:55 +0000, geremy condra a ?crit :
>> geremy condra <debatem1 at gmail.com> added the comment:
>>
>> On Fri, Jun 18, 2010 at 6:05 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>> >
>> > Antoine Pitrou <pitrou at free.fr> added the comment:
>> >
>> >> Great, I'm thinking more-or-less the API proposed in PEP 272- the
>> >> exception I'm thinking of is that 'strings' should be substituted for
>> >> 'bytes'- for AES and DES. It gets trickier when talking about public
>> >> key crypto, though. Perhaps something along the lines of
>> >> RSA.new(public_key=None, private_key=None,...), with the resulting
>> >> object supporting encrypt/decrypt/sign/verify operations?
>> >
>> > I don't have any opinion right now. I think a concrete proposal should
>> > be initiated and we can iterate from that.
>> > (that's assuming other people agree on the principle, of course)
>>
>> I assume that by "a concrete proposal" you're talking about code? Or
>> API docs? Also, what more needs to be done to ensure that other people
>> agree on the principle?
>
> I was thinking about a PEP. Of course, you are free to reuse existing
> PEP content for that :)

Ok. I've gone ahead and put together kind of a map for what I think the
basic structure of the library is going to look like. Let me know what you
think, and once we're done with that we can proceed into PEP land.

crypto API
==========
Variables message, key, salt, iv, ciphertext, and signature are of type bytes.
Variables public_key and private_key are DER-encoded bytes.
Variable bitlength is an integer.

Note that we deviate from the standard in PEP 272 in several ways:

	* arguments are generally bytes rather than strings
	* ciphers do not accept the 'counter', 'rounds', or 'segment_size' args

Layer 1
-------

Symmetric Ciphers
	crypto.cipher.encrypt(message, key) -> (salt, iv, ciphertext)
		depends on:
			crypto.keys.strengthen_password
			crypto.AES.new
			crypto.AES.encrypt
		raises:
			crypto.cipher.EncryptionError

	crypto.cipher.decrypt(salt, iv, ciphertext, key) -> message
		depends on:
			crypto.AES.new
			crypto.AES.decrypt
		raises:
			crypto.cipher.DecryptionError

Envelope Encryption
	crypto.envelope.encrypt(message, public_key) -> (iv, aes_key, ciphertext)
		depends on:
			crypto.keys.random_key
			crypto.AES.new
			crypto.AES.encrypt
			crypto.RSA.new
			crypto.RSA.encrypt
		raises:
			crypto.envelope.EncryptionError

	crypto.envelope.decrypt(iv, aes_key, ciphertext, private_key) -> message
		depends on:
			crypto.AES.new
			crypto.AES.decrypt
			crypto.RSA.new
			crypto.RSA.decrypt
		raises:
			crypto.envelope.DecryptionError

Digital Signatures
	crypto.signature.sign(message, private_key) -> signature
		depends on:
			hashlib.SHA512.new
			hashlib.SHA512.update
			hashlib.SHA512.digest
			crypto.RSA.new
			crypto.RSA.sign
		raises:
			crypto.signature.SigningError

	crypto.signature.verify(message, signature, public_key)
		depens on:
			hashlib.SHA512.new
			hashlib.SHA512.update
			hashlib.SHA512.digest
			crypto.RSA.new
			crypto.RSA.verify

Layer 2
-------

Utilities
	crypto.keys.strengthen_password(password) -> key
		depends on:
			openssl: RAND_bytes, EVP_get_digest_by_name, EVP_bytes_to_key
		raises:
			crypto.keys.KeyGenerationError

Symmetric Encryption
	crypto._cipher_object

		crypto._cipher_object.CipherObject._ctx = openssl context | None
		crypto._cipher_object.CipherObject._cipher = openssl cipher | None
		crypto._cipher_object.CipherObject._key = bytes | None

		CipherObject.encrypt(self, data) -> ciphertext
			depends on:
				crypto._cipher_object.CipherObject.encrypt_init
				crypto._cipher_object.CipherObject.encrypt_update
				crypto._cipher_object.CipherObject.encrypt_finalize
			raises:
				crypto._cipher_object.EncryptError

		CipherObject.encrypt_init() -> None
			depends on:
				openssl: EVP_EncryptInit_ex
			raises:
				crypto._cipher_object.EncryptInitError

		CipherObject.encrypt_update
			depends on:
				openssl: EVP_EncryptUpdate_ex
			raises:
				crypto._cipher_object.EncryptUpdateError

		CipherObject.encrypt_finalize
			depends on:
				openssl: EVP_EncryptFinal_ex
			raises:
				crypto._cipher_object.FinalizeError

		CipherObject.decrypt(self, ciphertext) -> message
			depends on:
				crypto._cipher_object.CipherObject.decrypt_init
				crypto._cipher_object.CipherObject.decrypt_update
				crypto._cipher_object.CipherObject.decrypt_finalize
			raises:
				crypto._cipher_object.DecryptError

		CipherObject.decrypt_init() -> None
			depends on:
				openssl: EVP_DecryptInit_ex
			raises:
				crypto._cipher_object.DecryptInitError

		CipherObject.decrypt_update
			depends on:
				openssl: EVP_DecryptUpdate_ex
			raises:
				crypto._cipher_object.DecryptUpdateError

		CipherObject.decrypt_finalize
			depends on:
				openssl: EVP_DecryptFinal_ex
			raises:
				crypto._cipher_object.DecryptFinalizeError

	crypto.AES
		crypto.AES.new(key, mode, IV=None) -> cipher_object

	crypto.DES
		crypto.DES.new(key, mode, IV=None) -> cipher_object

Asymmetric Encryption
	crypto.RSA
		crypto.RSA.new(public_key=None, private_key=None, padding=4) -> crypto.RSA.RSA
			depends on:
				openssl: d2i_RSAPublicKey, d2i_RSAPrivateKey
			raises:
				crypto.RSA.KeyError
				crypto.RSA.InitializationError

		crypto.RSA.generate_keypair(bitlength) -> public_key, private_key
			depends on:
				openssl: RSA_generate_key, i2d_RSAPublicKey, RSA_free
			raises:
				crypto.RSA.KeygenError

	crypt.RSA.RSA
		crypto.RSA.RSA._public_key = openssl RSA key | None
		crypto.RSA.RSA._private_key = openssl RSA key | None
		crypto.RSA.RSA._padding_type = integer

		crypto.RSA.RSA.encrypt(self, data) -> ciphertext
			depends on:
				openssl: RSA_size, RSA_public_encrypt
			raises:
				crypto.RSA.EncryptionError

		crypto.RSA.RSA.decrypt(self, ciphertext) -> message
			depends on:
				openssl: RSA_size, RSA_private_decrypt
			raises:
				crypto.RSA.DecryptionError

		crypto.RSA.RSA.sign(self, hash) -> signature
			depends on:
				openssl: RSA_size, RSA_sign
			raises:
				crypto.RSA.SigningError

		crypto.RSA.RSA.verify(self, hash, signature) -> True | False
			depends on:
				openssl: RSA_size, RSA_verify
			raises:
				crypto.RSA.VerificationError

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sun Jun 20 10:49:12 2010
From: report at bugs.python.org (Oren Held)
Date: Sun, 20 Jun 2010 08:49:12 +0000
Subject: [issue9035] os.path.ismount on windows doesn't support windows mount
	points
In-Reply-To: <1277023751.91.0.438330382261.issue9035@psf.upfronthosting.co.za>
Message-ID: <1277023751.91.0.438330382261.issue9035@psf.upfronthosting.co.za>


New submission from Oren Held <oren at held.org.il>:

On unices, ismount checks whether the given path is a mount point.
On windows, it only checks whether it's a drive letter.

Long story short, Python simply returns False when doing ismount(r"c:\mount1"), while c:\mount1 is a real mount point.

This is relevant for all modern windows versions.

-- 

I'm using win32file.GetVolumePathName() for overcoming this, but I'm not sure if the os python package should be importing win32file, maybe there is a better way to check whether a path is a mount point..

----------
components: Windows
messages: 108225
nosy: Oren_Held
priority: normal
severity: normal
status: open
title: os.path.ismount on windows doesn't support windows mount points
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9035>
_______________________________________

From report at bugs.python.org  Sun Jun 20 10:53:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 20 Jun 2010 08:53:29 +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: <1277024009.92.0.97505179033.issue8990@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

About the patch:

 - Why not reading itemsize from buffer.itemsize?
 - A test would be nice in Lib/test/test_array.py (in test_tofromstring?). Please add also a.extend(bytearray(b'xjxjx')) to the test suite.


I agree that it is a bugfix and so i can be applied to 3.1 (and 3.2).

--

> fromstring should become frombytes.

I remember an issue proposing that. I also prefer .frombytes() name: we can add .frombytes() and keep .fromstring() as an alias to .frombytes() (and maybe mark it as deprecated).

A message:
http://bugs.python.org/issue3565#msg71205

An issue starting at:
http://bugs.python.org/issue1023290#msg92069

Can someone open a issue about .frombytes()?

> fromunicode is still needed. 

Can someone open a new issue about .fromunicodes()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8990>
_______________________________________

From report at bugs.python.org  Sun Jun 20 10:54:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 20 Jun 2010 08:54:49 +0000
Subject: [issue8939] Use C type names (PyUnicode etc;) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1277024089.4.0.874218336983.issue8939@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Shouldn?t ?inside a :ctype:`Py_BEGIN_ALLOW_THREADS` block? rather use ?:cmacro:??

Same remark on IRC: "Taggnostr> haypo, in r82084: "Add :ctype: to Py_BEGIN_ALLOW_THREADS and int", maybe :cfunc: (or :cmacro:)?"

I don't know :cmacro:. I will fix it in my next patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8939>
_______________________________________

From report at bugs.python.org  Sun Jun 20 10:56:16 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 20 Jun 2010 08:56:16 +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: <1277024176.85.0.463708925751.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file14540/python-trunk-20090722-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sun Jun 20 10:56:22 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 20 Jun 2010 08:56:22 +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: <1277024182.91.0.556668512487.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file15261/python-trunk-20091104-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sun Jun 20 10:56:29 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 20 Jun 2010 08:56:29 +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: <1277024189.95.0.400346925588.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file15416/python-trunk-20091129-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sun Jun 20 10:56:35 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 20 Jun 2010 08:56:35 +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: <1277024195.69.0.0151424726475.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file15465/python-trunk-20091206-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sun Jun 20 10:56:41 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 20 Jun 2010 08:56:41 +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: <1277024201.49.0.683916352514.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file15725/python-trunk-20100103-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sun Jun 20 10:56:49 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 20 Jun 2010 08:56:49 +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: <1277024209.54.0.443045566133.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file16364/python-trunk-20100225-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sun Jun 20 10:56:55 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 20 Jun 2010 08:56:55 +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: <1277024215.38.0.100458795114.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file16534/python-trunk-20100313-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sun Jun 20 10:57:02 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 20 Jun 2010 08:57:02 +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: <1277024222.13.0.760602222802.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file16806/python-trunk-20100407-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sun Jun 20 11:00:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 20 Jun 2010 09:00:58 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1277024458.93.0.662490794499.issue1602@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Maybe the solution is to use the win32 console API directly...

Yes, it is the best solution because it avoids the horrible mbcs encoding.

About cp65001: it is not *exactly* the same encoding than utf-8 and so it cannot be used as an alias to utf-8: see issue #6058.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sun Jun 20 11:05:43 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 20 Jun 2010 09:05:43 +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: <1277024743.26.0.455167320439.issue3871@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Patches to this issue require first patch from issue 3754. The last patch here now is from 2010-05-16. This patch cannot be applied to trunk as it will fail after update for readline in setup.py. You could use trunk version before this readline update.

Now I'm working on readline and ncurses support for mingw . All patches before skip this as MSVC build don't support them. As I could not found reason to limit mingw users I will post soon version without limitation.

P.S. Many thanks to ??????? (www.ekk.com now blizzo) - a company that left me for a week without internet connection.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sun Jun 20 11:11:51 2010
From: report at bugs.python.org (Tim Golden)
Date: Sun, 20 Jun 2010 09:11:51 +0000
Subject: [issue9035] os.path.ismount on windows doesn't support windows mount
	points
In-Reply-To: <1277023751.91.0.438330382261.issue9035@psf.upfronthosting.co.za>
Message-ID: <1277025111.41.0.220519660485.issue9035@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

Switching to Python 3.2 as this essentially constitutes a behaviour change and 2.6 is in bugfix mode and 2.7 is about to enter rc2. It would certainly be possible to use one of the volume APIs under the covers. Would you be willing to offer a patch to, say, posixmodule.c?

----------
assignee:  -> tim.golden
nosy: +tim.golden
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.2 -Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9035>
_______________________________________

From report at bugs.python.org  Sun Jun 20 11:55:53 2010
From: report at bugs.python.org (Tim Golden)
Date: Sun, 20 Jun 2010 09:55:53 +0000
Subject: [issue9035] os.path.ismount on windows doesn't support windows
	mount	points
In-Reply-To: <1277025111.41.0.220519660485.issue9035@psf.upfronthosting.co.za>
Message-ID: <4C1DE5A5.3000801@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

All we need to do is check the FILE_ATTRIBUTE_REPARSE_POINT
in the file attributes. Frustratingly, we grab file attributes
a dozen times in posixpath.c only to throw most of it away.

Is there a case for adding an "attributes" function to os.path
which exposes the full file attributes on Windows, and its
posix equivalent if there is one? This could then be used
in the ismount function currently implemented in ntpath.py.

----------
title: os.path.ismount on windows doesn't support windows mount points -> os.path.ismount on windows doesn't support windows mount	points

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9035>
_______________________________________

From report at bugs.python.org  Sun Jun 20 12:04:52 2010
From: report at bugs.python.org (Tim Golden)
Date: Sun, 20 Jun 2010 10:04:52 +0000
Subject: [issue9035] os.path.ismount on windows doesn't support windows
	mount	points
In-Reply-To: <1277023751.91.0.438330382261.issue9035@psf.upfronthosting.co.za>
Message-ID: <1277028292.97.0.472201890555.issue9035@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

... of course you still need to get the reparse tag to determine whether this is a mount point so the file attributes alone in this case are not enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9035>
_______________________________________

From report at bugs.python.org  Sun Jun 20 12:31:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Jun 2010 10:31:09 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <AANLkTil6RDoE6R9ZMUrLkfuFpDhS7XklDz4vJcYnQxRv@mail.gmail.com>
Message-ID: <1277029863.3197.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le dimanche 20 juin 2010 ? 06:30 +0000, geremy condra a ?crit :
> crypto API
> ==========
> [...]

For presentation purposes, I would order layers by abstraction levem:
that is, "layer 1" should be the lower-level layer and "layer 2" the
upper-level.

I think all further discussion should happen on the PEP itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Sun Jun 20 15:12:08 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 20 Jun 2010 13:12:08 +0000
Subject: [issue9036] Simplify Py_CHARMASK
In-Reply-To: <1277039528.15.0.539020018856.issue9036@psf.upfronthosting.co.za>
Message-ID: <1277039528.15.0.539020018856.issue9036@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

This feature request is extracted from issue 9020, where Py_CHARMASK(c)
was used on EOF, producing different results depending on whether __CHAR_UNSIGNED__ is defined or not.

The preferred fix for issue 9020 is to check for EOF before using
Py_CHARMASK, so this is only loosely related.


I've looked through the source tree to determine how Py_CHARMASK
is meant to be used. It seems that it is only used in situations
where one would actually want to cast a char to an unsigned char,
like isspace((unsigned char)c).


Simplifications:

1) Python.h already enforces that an unsigned char is 8 bit wide. Thus,
   ((unsigned char)((c) & 0xff)) and ((unsigned char)(c)) should produce
   the same results.

2) There is no reason not to do the cast when __CHAR_UNSIGNED__ is
   defined (it will be a no-op).

----------
components: Interpreter Core
files: py_charmask.patch
keywords: needs review, patch
messages: 108234
nosy: eric.smith, loewis, pitrou, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Simplify Py_CHARMASK
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17724/py_charmask.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9036>
_______________________________________

From report at bugs.python.org  Sun Jun 20 15:27:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Jun 2010 13:27:04 +0000
Subject: [issue9036] Simplify Py_CHARMASK
In-Reply-To: <1277039528.15.0.539020018856.issue9036@psf.upfronthosting.co.za>
Message-ID: <1277040424.45.0.292669416337.issue9036@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Thus,
> ((unsigned char)((c) & 0xff)) and ((unsigned char)(c)) should produce
> the same results.

If it's the case, it's probably optimized away by the compiler anyway.

> There is no reason not to do the cast when __CHAR_UNSIGNED__ is
> defined (it will be a no-op).

Agreed. It also reduces the opportunity for bugs :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9036>
_______________________________________

From report at bugs.python.org  Sun Jun 20 16:07:08 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 20 Jun 2010 14:07:08 +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: <1277042828.4.0.216756390121.issue8959@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Is r80761 something that can be safely reverted?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8959>
_______________________________________

From report at bugs.python.org  Sun Jun 20 16:19:04 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 20 Jun 2010 14:19:04 +0000
Subject: [issue9035] os.path.ismount on windows doesn't support windows
	mount	points
In-Reply-To: <1277023751.91.0.438330382261.issue9035@psf.upfronthosting.co.za>
Message-ID: <1277043544.5.0.726795477515.issue9035@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/issue9035>
_______________________________________

From report at bugs.python.org  Sun Jun 20 16:29:26 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Jun 2010 14:29:26 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1277044166.3.0.937775138207.issue9011@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Summary of brief discussion on #python-dev:

- This is a hacky patch; it would be better to rewrite that portion of ast.c in a way that doesn't modify the original CST at all. With 2.7 so close, I daren't try anything more invasive than this patch, though. (I don't know whether there are any other portions of this file that deliberately change the CST.)

- Given that no-one noticed this problem in 5 years, the fix can probably wait until 2.7.1, when it can be done properly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Sun Jun 20 18:40:19 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 20 Jun 2010 16:40:19 +0000
Subject: [issue8996] Add a default role to allow writing bare `len` instead of
	:func:`len`
In-Reply-To: <1276528152.92.0.60611534239.issue8996@psf.upfronthosting.co.za>
Message-ID: <1277052019.12.0.611651299287.issue8996@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

`someref` would be more convenient than :func:`someref` but in case of namespace conflict (for example, as a result of documentation merge it both :func:`someref` and :class:`someref` can appear) - it would be necessary to go through all the links in both sources and update ambiguous references to point to the right type.

But perhaps the biggest problem would be to explain users what happens. Also in the case when you create new :class:`someref` and Sphinx detects conflict.

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8996>
_______________________________________

From report at bugs.python.org  Sun Jun 20 18:55:06 2010
From: report at bugs.python.org (Jonathan G. Underwood)
Date: Sun, 20 Jun 2010 16:55:06 +0000
Subject: [issue9037] Add explanation as to how to raise a custom exception in
	the extending python intermezzo on exceptions
In-Reply-To: <1277052906.52.0.842872873757.issue9037@psf.upfronthosting.co.za>
Message-ID: <1277052906.52.0.842872873757.issue9037@psf.upfronthosting.co.za>


New submission from Jonathan G. Underwood <jonathan.underwood at gmail.com>:

In the documentation section on Extending Python with C or C++ there is an Intermezzo on Errors and Exceptions which shows how to create a custom exception in an extension module. I was just following these instructions for the first time and got to the end and was left wondering how to actually raise the custom exception in my new module, and it wasn't immediately obvious, so I propose to add a brief explanation to the end of that section explaining how. Patch attached.

----------
assignee: docs at python
components: Documentation
files: extending_how_to_raise_exception.patch
keywords: patch
messages: 108239
nosy: docs at python, jonathan.underwood
priority: normal
severity: normal
status: open
title: Add explanation as to how to raise a custom exception in the extending python intermezzo on exceptions
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file17725/extending_how_to_raise_exception.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9037>
_______________________________________

From report at bugs.python.org  Sun Jun 20 19:29:55 2010
From: report at bugs.python.org (Frederic Torres)
Date: Sun, 20 Jun 2010 17:29:55 +0000
Subject: [issue8964] Method _sys_version() module Lib\platform.py does not
	parse	correctly IronPython 2.x version
In-Reply-To: <1276204295.1.0.731236969654.issue8964@psf.upfronthosting.co.za>
Message-ID: <1277054995.07.0.212973432725.issue8964@psf.upfronthosting.co.za>


Frederic Torres <fredericaltorres at gmail.com> added the comment:

print repr(sys_version)
returns
'2.6.1 (IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.3603)'

The format of sys.version now start with a version number
2.6.1 (IronPythons  2.6.1 (2.6.10920.0) on .NET 4.0.30319.1)
My guess is that with previous version of IronPython this was not the case

----------
title: Method _sys_version() module Lib\platform.py does parse	correctly IronPython 2.x version -> Method _sys_version() module Lib\platform.py does not parse	correctly IronPython 2.x version

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8964>
_______________________________________

From report at bugs.python.org  Sun Jun 20 21:51:50 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 20 Jun 2010 19:51:50 +0000
Subject: [issue9028] test_support.run_unittest cmdline options and arguments
In-Reply-To: <1276866224.2.0.777930943128.issue9028@psf.upfronthosting.co.za>
Message-ID: <1277063510.09.0.986638526039.issue9028@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

RDM, running your way will execute test from standard library location of installed Python.

> python -m unittest test.test_httpservers.BaseHTTPServerTestCase.test_handler

But I want to execute test from my own patched copy of test_httpservers.py with whatever python I want. I.e.

> C:\Python27\python.exe Z:\python-cgi-tests\test_httpservers.py ...

I prefer to explicitly specify it in command line to be sure that I execute the right test suite. I also don't feel like typing `-m unittest test.test_httpservers.` each time when there is shell completion, and every decent file manager has keyboard shortcuts for inserting active filename into command line prompt.

You know - I am not a core contributor to maintain a bunch of batch files for all kind of operations, so I am interested to make testing process more intuitive.

I know how "TestCase" and "test_" auto discovery works. The point is to remove the need in extra typing, because test runner can add these suffix/prefixes automatically when parsing command line.

@exarkun: Ok. `.` is fine - `::` was a copy paste from my old PHP test runner.

----------
nosy: +michael.foord, pitrou
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9028>
_______________________________________

From report at bugs.python.org  Sun Jun 20 21:54:32 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 20 Jun 2010 19:54:32 +0000
Subject: [issue9028] test_support.run_unittest cmdline options and arguments
In-Reply-To: <1276866224.2.0.777930943128.issue9028@psf.upfronthosting.co.za>
Message-ID: <1277063672.26.0.635512356697.issue9028@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

"""But I want to execute test from my own patched copy of test_httpservers.py with whatever python I want. I.e.

> C:\Python27\python.exe Z:\python-cgi-tests\test_httpservers.py ...
"""

If you use Python 2.7 then the following at the end of the test module enables the same command line features that David Murray pointed you to:

if __name__ == '__main__':
    unittest.main()

If you are using earlier versions of Python you can use unittest2 (which also works with Python 2.7).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9028>
_______________________________________

From report at bugs.python.org  Sun Jun 20 21:59:59 2010
From: report at bugs.python.org (Thomas Heller)
Date: Sun, 20 Jun 2010 19:59:59 +0000
Subject: [issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning
	correctly in Python 2.7
In-Reply-To: <1277042828.4.0.216756390121.issue8959@psf.upfronthosting.co.za>
Message-ID: <4C1E7337.4090000@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

> Is r80761 something that can be safely reverted?

Yes, I think so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8959>
_______________________________________

From report at bugs.python.org  Sun Jun 20 22:01:17 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 20 Jun 2010 20:01:17 +0000
Subject: [issue9028] test_support.run_unittest cmdline options and arguments
In-Reply-To: <1277063672.26.0.635512356697.issue9028@psf.upfronthosting.co.za>
Message-ID: <AANLkTin9AGj2i104JqQpIUuVfuMYx4zQ67I_fapeVV-Z@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

> If you use Python 2.7 then the following at the end of the test module enables the same command line features that David Murray pointed you to:
>
> if __name__ == '__main__':
> ? ?unittest.main()

Unfortunately, test_httpservers.py from stdlib contains this code:

def test_main(verbose=None):
    try:
        cwd = os.getcwd()
        test_support.run_unittest(BaseHTTPServerTestCase,
                                SimpleHTTPServerTestCase,
                                CGIHTTPServerTestCase
                                )
    finally:
        os.chdir(cwd)

if __name__ == '__main__':
    test_main()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9028>
_______________________________________

From report at bugs.python.org  Sun Jun 20 22:09:28 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 20 Jun 2010 20:09:28 +0000
Subject: [issue9028] test_support.run_unittest cmdline options and arguments
In-Reply-To: <1276866224.2.0.777930943128.issue9028@psf.upfronthosting.co.za>
Message-ID: <1277064568.23.0.679458719605.issue9028@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Right. That code should change. My intention is to go through the whole of the Python test suite and make them compatible with the new unittest features.

I also intend to add extensions to unittest to allow listing of collecting tests and filtering tests by name (at the moment test filtering is by filename only which is useful but not enough)... The first task is to add extension / plugin machinery to unittest and then these use cases become easy - so I will not implement them on their own in unittest until the plugin system is done.

At the same time I don't think there is any point (although I wouldn't argue with) in adding code to do this directly to test_support when it is going to be added to unittest anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9028>
_______________________________________

From report at bugs.python.org  Sun Jun 20 22:44:47 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 20 Jun 2010 20:44:47 +0000
Subject: [issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning
	correctly in Python 2.7
In-Reply-To: <4C1E7337.4090000@ctypes.org>
Message-ID: <AANLkTin_fBgAbgoOfIH65sWHogH06-xN3H5O6iNO63ZY@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/6/20 Thomas Heller <report at bugs.python.org>:
>
> Thomas Heller <theller at ctypes.org> added the comment:
>
>> Is r80761 something that can be safely reverted?
>
> Yes, I think so.

Can you do so? Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8959>
_______________________________________

From report at bugs.python.org  Sun Jun 20 22:48:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Jun 2010 20:48:21 +0000
Subject: [issue9038] test_distutils failure
In-Reply-To: <1277066901.58.0.116708897563.issue9038@psf.upfronthosting.co.za>
Message-ID: <1277066901.58.0.116708897563.issue9038@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

test_distutils
test test_distutils failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/ssl-8524/Lib/distutils/tests/support.py", line 16, in _capture_warnings
    return func(*args, **kw)
  File "/home/antoine/py3k/ssl-8524/Lib/distutils/tests/test_sysconfig.py", line 47, in test_get_python_inc
    self.assertTrue(os.path.isdir(inc_dir), inc_dir)
AssertionError: /home/antoine/py3k/ssl-8524/build/test_python_15977/Include

----------
assignee: tarek
components: Distutils, Tests
messages: 108247
nosy: pitrou, tarek
priority: normal
severity: normal
status: open
title: test_distutils failure
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9038>
_______________________________________

From report at bugs.python.org  Sun Jun 20 22:51:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Jun 2010 20:51:54 +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: <1277067114.16.0.801444034249.issue8524@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It might be nice to see the version that avoids the dup() and has the 
> duplicate code instead (interesting trade-off ;).  Just for the sake of 
> comparison against the forget() proposal.

Here it is. There's probably a bit of polishing left to do, in the (unlikely) case this is chosen as a solution.

----------
Added file: http://bugs.python.org/file17726/sslrefactor.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8524>
_______________________________________

From report at bugs.python.org  Sun Jun 20 23:22:36 2010
From: report at bugs.python.org (Christian Hofstaedtler)
Date: Sun, 20 Jun 2010 21:22:36 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1277068956.51.0.883921723912.issue6755@psf.upfronthosting.co.za>


Christian Hofstaedtler <ch+pythonbugs at zeha.at> added the comment:

Will this be part of 3.2 and possibly 2.7?

Without these patches wide character input using curses is basically impossible (on at least some platforms).

----------
nosy: +zeha

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Sun Jun 20 23:32:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Jun 2010 21:32: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: <1277069535.38.0.590539305287.issue1589@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file8933/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Sun Jun 20 23:32:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Jun 2010 21:32:19 +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: <1277069539.63.0.0772373867424.issue1589@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file8941/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Sun Jun 20 23:32:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Jun 2010 21:32:33 +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: <1277069553.06.0.477790503335.issue1589@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file11463/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Sun Jun 20 23:40:57 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 20 Jun 2010 21:40:57 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <1275175831.39.0.913540756271.issue8854@psf.upfronthosting.co.za>
Message-ID: <1277070057.74.0.976372191789.issue8854@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The patch looks good but I am not comfortable with this change until it's tested under other windows/VC flavors.

I'll leave it up to Benjamin to decide whether it goes in rc2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Mon Jun 21 00:44:13 2010
From: report at bugs.python.org (Yoda_Uchiha)
Date: Sun, 20 Jun 2010 22:44:13 +0000
Subject: [issue9039] IDLE and module Doc
In-Reply-To: <1277073853.62.0.33861554581.issue9039@psf.upfronthosting.co.za>
Message-ID: <1277073853.62.0.33861554581.issue9039@psf.upfronthosting.co.za>


New submission from Yoda_Uchiha <MMPyro55 at gmail.com>:

I recently installed python 3.1 on a Windows XP computer. I cannot open IDLE nor module Docs. When I click on them, nothing happens. I am wondering if there is anyway on opening either of those too files. I do know how to IDLE through the workaround listed below but i have to put that in everytime to open IDLE. I am wondering if there was a permanent fix so i can just open if from my desktop. 
C:\>set TCL_LIBRARY= 
C:\>set TK_LIBRARY= 
C:\>C:\Python31\python.exe C:\Python31\Lib\idlelib\idle.py

----------
components: IDLE
messages: 108251
nosy: Yoda_Uchiha
priority: normal
severity: normal
status: open
title: IDLE and module Doc
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9039>
_______________________________________

From report at bugs.python.org  Mon Jun 21 02:55:24 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 21 Jun 2010 00:55:24 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1277081724.41.0.414411703833.issue2516@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

The same subject on python-dev raised last month received positive feedbacks:
http://mail.python.org/pipermail/python-dev/2010-May/100197.html

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________

From report at bugs.python.org  Mon Jun 21 03:12:28 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 21 Jun 2010 01:12:28 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <1275175831.39.0.913540756271.issue8854@psf.upfronthosting.co.za>
Message-ID: <1277082748.4.0.473410010803.issue8854@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Mon Jun 21 04:41:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Jun 2010 02:41:52 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1277088112.7.0.198520218017.issue2516@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

All that is needed now is a working patch... :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________

From report at bugs.python.org  Mon Jun 21 04:42:50 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 21 Jun 2010 02:42:50 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1277088170.19.0.927477687769.issue2516@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________

From report at bugs.python.org  Mon Jun 21 08:59:20 2010
From: report at bugs.python.org (Javier Collado)
Date: Mon, 21 Jun 2010 06:59:20 +0000
Subject: [issue9026] [argparse] Subcommands not printed in the same order they
	were added
In-Reply-To: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za>
Message-ID: <1277103560.16.0.436064298761.issue9026@psf.upfronthosting.co.za>


Javier Collado <javier.collado at gmail.com> added the comment:

Working on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9026>
_______________________________________

From report at bugs.python.org  Mon Jun 21 09:21:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 21 Jun 2010 07:21:14 +0000
Subject: [issue9039] IDLE and module Doc
In-Reply-To: <1277073853.62.0.33861554581.issue9039@psf.upfronthosting.co.za>
Message-ID: <1277104874.28.0.618606754255.issue9039@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

You will need to delete TCL_LIBRARY and TK_LIBRARY in your environment settings.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9039>
_______________________________________

From report at bugs.python.org  Mon Jun 21 10:20:29 2010
From: report at bugs.python.org (Enrico Sartori)
Date: Mon, 21 Jun 2010 08:20:29 +0000
Subject: [issue9040] using MIMEApplication to attach a PDF raises a TypeError
	exception
In-Reply-To: <1277108429.25.0.109783634019.issue9040@psf.upfronthosting.co.za>
Message-ID: <1277108429.25.0.109783634019.issue9040@psf.upfronthosting.co.za>


New submission from Enrico Sartori <enrypif at gmail.com>:

To send an email with a PDF attachment the following code should work:

msg = MIMEMultipart()
msg['From'] = from
msg['To'] = to
msg['Subject'] = 'test'
fp = open('/path/to/file.pdf', 'rb')
attach = MIMEApplication(fp.read(), 'pdf')
fp.close()
attach.add_header('Content-Disposition', 'attachment', filename = 'file.pdf')
msg.attach(attach)
server = smtplib.SMTP('smtp.example.com')
server.login('username', 'password')
server.sendmail(from, to, msg.as_string())
server.quit()

But an exception is raised:

TypeError: string payload expected: <class 'bytes'>

To work around the problem the code above can be rewritten as follows:

msg = MIMEMultipart()
msg['From'] = from
msg['To'] = to
msg['Subject'] = 'test'
fp = open('/path/to/file.pdf', 'rb')
attach = MIMENonMultipart('application', 'pdf')
payload = base64.b64encode(fp.read()).decode('ascii')
attach.set_payload(payload)
attach['Content-Transfer-Encoding'] = 'base64'
fp.close()
attach.add_header('Content-Disposition', 'attachment', filename = 'file.pdf')
msg.attach(attach)
server = smtplib.SMTP('smtp.example.com')
server.login('username', 'password')
server.sendmail(from, to, msg.as_string())
server.quit()

This works, but explicit encoding should not be necessary.

----------
components: Library (Lib)
messages: 108256
nosy: Enrico.Sartori
priority: normal
severity: normal
status: open
title: using MIMEApplication to attach a PDF raises a TypeError exception
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9040>
_______________________________________

From report at bugs.python.org  Mon Jun 21 10:43:05 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jun 2010 08:43:05 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <1277070057.74.0.976372191789.issue8854@psf.upfronthosting.co.za>
Message-ID: <4C1F2615.8020907@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Tarek Ziad? wrote:
> 
> Tarek Ziad? <ziade.tarek at gmail.com> added the comment:
> 
> The patch looks good but I am not comfortable with this change until it's tested under other windows/VC flavors.

The patch is really trivial, but I'll test it on a Windows x86
installation as well today.

Would be great if we could get someone else test it on their
Windows x64 system.

It's strange that noone has noticed this problem while Python 2.6
was out. I know that Martin uses a cross-compiling setup to create
the 64-bit installers, so he wouldn't have noticed, but others
should have seen similar problems, trying to compile extensions
on Windows x64.

I guess most people still use the 32-bit Python installers on Windows
x64 systems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Mon Jun 21 10:44:42 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 21 Jun 2010 08:44:42 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <1275175831.39.0.913540756271.issue8854@psf.upfronthosting.co.za>
Message-ID: <1277109882.35.0.94798283023.issue8854@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I am adding srid in the nosy list. I believe he can test those platforms as well if he's around

----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Mon Jun 21 11:19:52 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Jun 2010 09:19:52 +0000
Subject: [issue8340] bytearray undocumented on trunk
In-Reply-To: <1270682579.64.0.491172746908.issue8340@psf.upfronthosting.co.za>
Message-ID: <1277111992.47.0.422020307743.issue8340@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This affects 2.6 as well, doesn't it?

----------
nosy: +mark.dickinson
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8340>
_______________________________________

From report at bugs.python.org  Mon Jun 21 12:26:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Jun 2010 10:26:44 +0000
Subject: [issue8340] bytearray undocumented on trunk
In-Reply-To: <1270682579.64.0.491172746908.issue8340@psf.upfronthosting.co.za>
Message-ID: <1277116004.98.0.265556094446.issue8340@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: georg.brandl -> docs at python
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8340>
_______________________________________

From report at bugs.python.org  Mon Jun 21 13:12:39 2010
From: report at bugs.python.org (Konstantin Zemlyak)
Date: Mon, 21 Jun 2010 11:12:39 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <1275175831.39.0.913540756271.issue8854@psf.upfronthosting.co.za>
Message-ID: <1277118759.79.0.0329749809003.issue8854@psf.upfronthosting.co.za>


Konstantin Zemlyak <zart at zartsoft.ru> added the comment:

Win2003 x64, VS2008, vanilla python 2.7rc1 amd64 from python.org.
Building python packages with C extensions works fine. Tested on simplejson, jinja2 (with enabled speedups) and PIL.

----------
nosy: +zart

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Mon Jun 21 13:39:52 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jun 2010 11:39:52 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <1277118759.79.0.0329749809003.issue8854@psf.upfronthosting.co.za>
Message-ID: <4C1F4F84.9020608@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Konstantin Zemlyak wrote:
> 
> Konstantin Zemlyak <zart at zartsoft.ru> added the comment:
> 
> Win2003 x64, VS2008, vanilla python 2.7rc1 amd64 from python.org.
> Building python packages with C extensions works fine. Tested on simplejson, jinja2 (with enabled speedups) and PIL.

I assume that you built without the patch applied. Does it also work
with the patch ?

This is the relevant section from the KB article:

"""
When you install a new program or when you run a program on a Windows x64 Edition computer, registry
calls made by 64-bit programs access the HKEY_LOCAL_MACHINE\Software registry sub key without
redirection. WOW64 intercepts registry calls to HKEY_LOCAL_MACHINE\Software that are made by 32-bit
programs, and then redirects them to the HKEY_LOCAL_MACHINE\Software\WOW6432node sub key.
"""

Since VS2008 is a 32-bit application, the registry keys are written
to the HKEY_LOCAL_MACHINE\Software\WOW6432node branch.

64-bit applications such as Python AMD64 don't see this indirection,
so they have to explicitly look in that branch to find VS2008 settings.

I checked the registry on the machine and indeed the VS2008 keys are
only available under the HKEY_LOCAL_MACHINE\Software\WOW6432node branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Mon Jun 21 13:48:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Jun 2010 11:48:47 +0000
Subject: [issue8340] bytearray undocumented on trunk
In-Reply-To: <1270682579.64.0.491172746908.issue8340@psf.upfronthosting.co.za>
Message-ID: <1277120927.52.0.708441639913.issue8340@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ideally, there should be documentation of 'bytes' and 'bytearray' in the 'Built-in Types' section of the library manual, too.  (library/stdtypes.rst).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8340>
_______________________________________

From report at bugs.python.org  Mon Jun 21 13:59:31 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jun 2010 11:59:31 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <1275175831.39.0.913540756271.issue8854@psf.upfronthosting.co.za>
Message-ID: <1277121571.18.0.47852935765.issue8854@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I checked this again using Python 2.7rc1 AMD64 on Windows Vista x64
using VS2008 and get the same error:

error: Unable to find vcvarsall.bat

Here's an updated patch for Python 2.7rc1.

----------
Added file: http://bugs.python.org/file17727/msvc9compiler-py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Mon Jun 21 14:11:17 2010
From: report at bugs.python.org (Konstantin Zemlyak)
Date: Mon, 21 Jun 2010 12:11:17 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <1275175831.39.0.913540756271.issue8854@psf.upfronthosting.co.za>
Message-ID: <1277122277.95.0.259500969082.issue8854@psf.upfronthosting.co.za>


Konstantin Zemlyak <zart at zartsoft.ru> added the comment:

64-bit Windows, 64-bit cmd.exe, 64-bit python, not patched::

	D:\>"c:\Program Files\Python27\python.exe"
	Python 2.7rc1 (r27rc1:81787, Jun  6 2010, 20:03:36) [MSC v.1500 64 bit (AMD64)]
	on win32
	Type "help", "copyright", "credits" or "license" for more information.
	>>> import distutils.msvc9compiler
	>>> distutils.msvc9compiler.get_build_version()
	9.0
	>>> distutils.msvc9compiler.find_vcvarsall(9.0)
	'c:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\vcvarsall.bat'
	>>>

How did you test? Maybe it's some difference in setup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Mon Jun 21 14:23:34 2010
From: report at bugs.python.org (Pauli Rikula)
Date: Mon, 21 Jun 2010 12:23:34 +0000
Subject: [issue9041] raised exception is misleading
In-Reply-To: <1277123013.52.0.887079191328.issue9041@psf.upfronthosting.co.za>
Message-ID: <1277123013.52.0.887079191328.issue9041@psf.upfronthosting.co.za>


New submission from Pauli Rikula <pauli.rikula at gmail.com>:

Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.c_double(-10L)
c_double(-10.0)
>>> ctypes.c_double(-16158503035655503650357438344334975980222051334857742016065172713762327569433945446598600705761456731844358980460949009747059779575245460547544076193224141560315438683650498045875098875194826053398028819192033784138396109321309878080919047169238085235290822926018152521443787945770532904303776199561965192761047051351577287005728952652821735984108986866610276357675617870244379434256980638641483535093292326373531858799166625357628570460558031263448272521936380684506350754039141397287742159767011772534248723062567540713722795836229745796676103584020939467516975660579180998612463422664938089473950280866877864444041L)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError:  float expected instead of long instance

.. vs:

>>> float(-16158503035655503650357438344334975980222051334857742016065172713762327569433945446598600705761456731844358980460949009747059779575245460547544076193224141560315438683650498045875098875194826053398028819192033784138396109321309878080919047169238085235290822926018152521443787945770532904303776199561965192761047051351577287005728952652821735984108986866610276357675617870244379434256980638641483535093292326373531858799166625357628570460558031263448272521936380684506350754039141397287742159767011772534248723062567540713722795836229745796676103584020939467516975660579180998612463422664938089473950280866877864444041L)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to float

----------
assignee: theller
components: ctypes
messages: 108265
nosy: kumma, theller
priority: normal
severity: normal
status: open
title: raised exception is misleading
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9041>
_______________________________________

From report at bugs.python.org  Mon Jun 21 14:31:47 2010
From: report at bugs.python.org (Konstantin Zemlyak)
Date: Mon, 21 Jun 2010 12:31:47 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <1275175831.39.0.913540756271.issue8854@psf.upfronthosting.co.za>
Message-ID: <1277123507.88.0.632923008365.issue8854@psf.upfronthosting.co.za>


Konstantin Zemlyak <zart at zartsoft.ru> added the comment:

Tried msvc9compiler-py27.patch. find_vcvarsall() still works with the same result, while distutils.msvc9compiler.VS_BASE has been changed.

:: 
	>>> distutils.msvc9compiler.find_vcvarsall(9.0)
	u'c:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\vcvarsall.bat'
	>>> distutils.msvc9compiler.VS_BASE
	'Software\\Wow6432Node\\Microsoft\\VisualStudio\\%0.1f'

Checked registry, 9.0 is only under Wow6432Node.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Mon Jun 21 14:36:46 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jun 2010 12:36:46 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <1277122277.95.0.259500969082.issue8854@psf.upfronthosting.co.za>
Message-ID: <4C1F5CDA.4030204@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Konstantin Zemlyak wrote:
> 
> Konstantin Zemlyak <zart at zartsoft.ru> added the comment:
> 
> 64-bit Windows, 64-bit cmd.exe, 64-bit python, not patched::
> 
> 	D:\>"c:\Program Files\Python27\python.exe"
> 	Python 2.7rc1 (r27rc1:81787, Jun  6 2010, 20:03:36) [MSC v.1500 64 bit (AMD64)]
> 	on win32
> 	Type "help", "copyright", "credits" or "license" for more information.
> 	>>> import distutils.msvc9compiler
> 	>>> distutils.msvc9compiler.get_build_version()
> 	9.0
> 	>>> distutils.msvc9compiler.find_vcvarsall(9.0)
> 	'c:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\vcvarsall.bat'
> 	>>>
> 
> How did you test? Maybe it's some difference in setup.

I'm running the build process using a batch file which is
invoked through a remote shell.

Trying the same build from within a cmd.exe started locally on
the machine does not cause the error messages, so I guess this
does indeed have to do with the way the Python interpreter
is invoked.

Further inspection shows that in case the registry key is not
found, the find_vcvarsall() function uses the OS environment
to find the installation.

With the local cmd.exe, the OS environment does indeed have the
entry that points the function to the installation:

VS90COMNTOOLS

Using the remote shell, those VS2008 env vars are not set and
so the build fails.

Could you check the registry keys on your installation ?

I put these extra log lines into the find_vcvarsall() function to
see what the registry has stored:

    vsbase = VS_BASE % version
    try:
        productdir = Reg.get_value(r"%s\Setup\VC" % vsbase,
                                   "productdir")
    except KeyError:
        productdir = None

    log.info('VS2008 product dir: %s - %s' % (productdir, vsbase))

    # trying Express edition
    if productdir is None:
        vsbase = VSEXPRESS_BASE % version
        try:
            productdir = Reg.get_value(r"%s\Setup\VC" % vsbase,
                                       "productdir")
        except KeyError:
            productdir = None
            log.debug("Unable to find productdir in registry")

    log.info('VS2008 product dir: %s - %s' % (productdir, vsbase))

The output is:

VS2008 product dir: None - Software\Microsoft\VisualStudio\9.0
VS2008 product dir: None - Software\Microsoft\VCExpress\9.0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Mon Jun 21 14:38:25 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jun 2010 12:38:25 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <1277123507.88.0.632923008365.issue8854@psf.upfronthosting.co.za>
Message-ID: <4C1F5D3E.1030001@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Konstantin Zemlyak wrote:
> 
> Konstantin Zemlyak <zart at zartsoft.ru> added the comment:
> 
> Tried msvc9compiler-py27.patch. find_vcvarsall() still works with the same result, while distutils.msvc9compiler.VS_BASE has been changed.
> 
> :: 
> 	>>> distutils.msvc9compiler.find_vcvarsall(9.0)
> 	u'c:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\vcvarsall.bat'
> 	>>> distutils.msvc9compiler.VS_BASE
> 	'Software\\Wow6432Node\\Microsoft\\VisualStudio\\%0.1f'
> 
> Checked registry, 9.0 is only under Wow6432Node.

Thanks for confirming that. So at least my setup is not special and the
keys do indeed have to be updated fir Win64 platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Mon Jun 21 14:42:56 2010
From: report at bugs.python.org (Meador Inge)
Date: Mon, 21 Jun 2010 12:42:56 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1277124176.35.0.943894559336.issue9011@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +minge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Mon Jun 21 14:55:38 2010
From: report at bugs.python.org (Konstantin Zemlyak)
Date: Mon, 21 Jun 2010 12:55:38 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <4C1F5CDA.4030204@egenix.com>
Message-ID: <4C1F613B.8010700@zartsoft.ru>


Konstantin Zemlyak <zart at zartsoft.ru> added the comment:

> Using the remote shell, those VS2008 env vars are not set and
> so the build fails.

Seems it doesn't load user profile.

> The output is:
> 
> VS2008 product dir: None - Software\Microsoft\VisualStudio\9.0
> VS2008 product dir: None - Software\Microsoft\VCExpress\9.0

Same for me. Your patch fixes registry lookup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Mon Jun 21 15:23:39 2010
From: report at bugs.python.org (v_peter)
Date: Mon, 21 Jun 2010 13:23:39 +0000
Subject: [issue9042] Gettext cache and classes
In-Reply-To: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>
Message-ID: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>


New submission from v_peter <leanmeandonothingmachine at gmail.com>:

If you pass gettext.translation a class_ but the mo file you are trying to open already exists in the _translations cache the instance that is returned is an instance of whatever was in the cache and not the class that you requested.

I think that if a class is requested it should return that class. If others agree then I'd be happy to work on a patch.

----------
components: Library (Lib)
messages: 108270
nosy: v_peter
priority: normal
severity: normal
status: open
title: Gettext cache and classes
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9042>
_______________________________________

From report at bugs.python.org  Mon Jun 21 16:06:10 2010
From: report at bugs.python.org (Daniel Bengtsson)
Date: Mon, 21 Jun 2010 14:06:10 +0000
Subject: [issue6931] dreadful performance in difflib: ndiff and HtmlDiff
In-Reply-To: <1253199298.69.0.280559653373.issue6931@psf.upfronthosting.co.za>
Message-ID: <1277129170.95.0.00317473001722.issue6931@psf.upfronthosting.co.za>


Changes by Daniel Bengtsson <daniel at bengtssons.info>:


----------
nosy: +zitrax

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6931>
_______________________________________

From report at bugs.python.org  Mon Jun 21 16:25:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 21 Jun 2010 14:25:10 +0000
Subject: [issue9005] Year range in timetuple
In-Reply-To: <1276660627.85.0.364876080456.issue9005@psf.upfronthosting.co.za>
Message-ID: <1277130310.44.0.330223357252.issue9005@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I raised this issue on python-dev and Guido said "OK."  See "[Python-Dev] Year 0 and year 10,000 in timetuple", http://mail.python.org/pipermail/python-dev/2010-June/100682.html

I am attaching a "commit ready" patch which contains a few more test cases and a NEWS entry.  I don't think there is a need to mention this in documentation, but at some point I would like to be able to write that dt.utctimetuple() is equivalent to dt.astimezone(timezone.utc).timetuple(), but at the moment it is not quite so.  See issue 9004.

----------
resolution:  -> accepted
stage: patch review -> commit review
Added file: http://bugs.python.org/file17728/issue9005a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9005>
_______________________________________

From report at bugs.python.org  Mon Jun 21 16:46:15 2010
From: report at bugs.python.org (Virgil Dupras)
Date: Mon, 21 Jun 2010 14:46:15 +0000
Subject: [issue9043] 2to3 doesn't handle byte comparison well
In-Reply-To: <1277131575.09.0.876680898489.issue9043@psf.upfronthosting.co.za>
Message-ID: <1277131575.09.0.876680898489.issue9043@psf.upfronthosting.co.za>


New submission from Virgil Dupras <hsoft at hardcoded.net>:

If we run 2to3 on the following code:

s = b' '
print s[0] == s

we end up with this:

s = b' '
print(s[0] == s)

However, the first code, under python2 prints True while the converted code, under python3 prints False.

Shouldn't 2to3 convert this code to:

s = b' '
print s[0:1] == s

instead?

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 108272
nosy: vdupras
priority: normal
severity: normal
status: open
title: 2to3 doesn't handle byte comparison well
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9043>
_______________________________________

From report at bugs.python.org  Mon Jun 21 16:55:36 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 21 Jun 2010 14:55:36 +0000
Subject: [issue9005] Year range in timetuple
In-Reply-To: <1276660627.85.0.364876080456.issue9005@psf.upfronthosting.co.za>
Message-ID: <1277132136.99.0.388028829011.issue9005@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17729/issue9005b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9005>
_______________________________________

From report at bugs.python.org  Mon Jun 21 16:59:12 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 21 Jun 2010 14:59:12 +0000
Subject: [issue9043] 2to3 doesn't handle byte comparison well
In-Reply-To: <1277131575.09.0.876680898489.issue9043@psf.upfronthosting.co.za>
Message-ID: <1277132352.67.0.032555356326.issue9043@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

2to3 can't guess which slices are from bytes.

----------
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9043>
_______________________________________

From report at bugs.python.org  Mon Jun 21 17:25:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 21 Jun 2010 15:25:55 +0000
Subject: [issue9005] Year range in timetuple
In-Reply-To: <1276660627.85.0.364876080456.issue9005@psf.upfronthosting.co.za>
Message-ID: <1277133955.74.0.362150339747.issue9005@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r82128.

----------
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9005>
_______________________________________

From report at bugs.python.org  Mon Jun 21 17:28:02 2010
From: report at bugs.python.org (Javier Collado)
Date: Mon, 21 Jun 2010 15:28:02 +0000
Subject: [issue9026] [argparse] Subcommands not printed in the same order they
	were added
In-Reply-To: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za>
Message-ID: <1277134082.88.0.838666539233.issue9026@psf.upfronthosting.co.za>


Javier Collado <javier.collado at gmail.com> added the comment:

Finally I had to use an OrderedDict as suggested by R. David Murray because it wasn't safe to rely on _choices_actions in HelpFormatter class (i.e. previous patch wasn't valid):
- _choices_actions attribute is only present in _SubParsersAction class
- Even if action object is an instance of _SubParsersAction, _choices_actions only contains data for for subparsers that contain a help description.

Regarding the test cases:
- TestHelpSubparsersOrdering and TestHelpSubparsersWithHelpOrdering have been added
- TestHelpFormattingMetaClass has been modified:
  - New subparsers_signatures tester attribute added to test subparsers help.
  - If a 'signatures attribute' isn't present in tester object, then isn't consumed
  - assertMultilineEqual used instead of assertEqual to make it easier to debug test case failures.

----------
Added file: http://bugs.python.org/file17730/trunk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9026>
_______________________________________

From report at bugs.python.org  Mon Jun 21 17:28:07 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 21 Jun 2010 15:28:07 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <1275175831.39.0.913540756271.issue8854@psf.upfronthosting.co.za>
Message-ID: <1277134087.11.0.549433673307.issue8854@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Applied patch in r82130. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Mon Jun 21 17:28:20 2010
From: report at bugs.python.org (Javier Collado)
Date: Mon, 21 Jun 2010 15:28:20 +0000
Subject: [issue9026] [argparse] Subcommands not printed in the same order they
	were added
In-Reply-To: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za>
Message-ID: <1277134100.87.0.0171216182632.issue9026@psf.upfronthosting.co.za>


Changes by Javier Collado <javier.collado at gmail.com>:


Removed file: http://bugs.python.org/file17705/ordered_subcommands.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9026>
_______________________________________

From report at bugs.python.org  Mon Jun 21 17:32:08 2010
From: report at bugs.python.org (Javier Collado)
Date: Mon, 21 Jun 2010 15:32:08 +0000
Subject: [issue9026] [argparse] Subcommands not printed in the same order they
	were added
In-Reply-To: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za>
Message-ID: <1277134328.97.0.147532853368.issue9026@psf.upfronthosting.co.za>


Javier Collado <javier.collado at gmail.com> added the comment:

Despite trunk.diff can be successfully applied to py3k branch, please find attached the patch generated from py3k branch.

----------
Added file: http://bugs.python.org/file17731/py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9026>
_______________________________________

From report at bugs.python.org  Mon Jun 21 17:35:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 21 Jun 2010 15:35:17 +0000
Subject: [issue9004] datetime.utctimetuple() should not set tm_isdst flag to 0
In-Reply-To: <1276659404.06.0.425467293989.issue9004@psf.upfronthosting.co.za>
Message-ID: <1277134517.77.0.579653961485.issue9004@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

With timezone.utc available in datetime module, users should be encouraged to use dt.astimezone(timezone.utc).timetuple() instead of dt.utctimetuple().  Note that the later will set tm_isdst to -1.  This observation can be used to argue for either of two ways to resolve this issue:

1. Since utctimetuple() is no longer necessary, and the alternative works correctly, there is no need to fix it.  Just recommend the astimezone use in the docs and explain the subtle difference.

2. Having two ways to do the same thing which have a subtle difference is not a good idea.

I am leaning towards #1, but would like to hear from others.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9004>
_______________________________________

From report at bugs.python.org  Mon Jun 21 18:01:47 2010
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 21 Jun 2010 16:01:47 +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: <1277136107.46.0.244272560516.issue8959@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Fixed in rev. 82127 (trunk) and rev 82138 (py3k).
Added test for the  issues reported here so that it doen't happen again.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8959>
_______________________________________

From report at bugs.python.org  Mon Jun 21 18:05:31 2010
From: report at bugs.python.org (Krzysztof Szawala)
Date: Mon, 21 Jun 2010 16:05:31 +0000
Subject: [issue9044] [optparse] confusion over an option and its value without
	any space in between
In-Reply-To: <1277136331.24.0.0452022727538.issue9044@psf.upfronthosting.co.za>
Message-ID: <1277136331.24.0.0452022727538.issue9044@psf.upfronthosting.co.za>


New submission from Krzysztof Szawala <kszawala at slb.com>:

Currently optparse library supports the following option definitions:
-e value,
-e=value,
-e:value,
-evalue.

Having said that let's consider the following option definition:
-e <string_value>.

Based on the above syntax the following statement will be correct:
-exclusive
and will be parsed into -e xclusive.
The fact that no caracter is required in between the option itself and its value leads to confusion.

My suggestion is to restrict the syntax to the following:
-e value,
-e=value,
-e:value.

Thanks,
Krzysztof

----------
components: Library (Lib)
messages: 108280
nosy: kszawala
priority: normal
severity: normal
status: open
title: [optparse] confusion over an option and its value without any space in between
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9044>
_______________________________________

From report at bugs.python.org  Mon Jun 21 18:10:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Jun 2010 16:10:25 +0000
Subject: [issue9042] Gettext cache and classes
In-Reply-To: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>
Message-ID: <1277136625.43.0.0182500438472.issue9042@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your report. Unfortunately, 2.6 and 3.1 are stable releases, they only get security and documentation fixes. 2.7 is nearly in the same state, since it?s at the release candidate stage. If your bug still applies to 3.2 (branch named ?py3k?), please propose a patch. I have added the maintainer of the gettext module and another developer expert in i18n to the nosy list (they are listed in Misc/maintainers.rst). Thanks again!

----------
nosy: +lemburg, loewis, merwok
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9042>
_______________________________________

From report at bugs.python.org  Mon Jun 21 18:12:02 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 21 Jun 2010 16:12:02 +0000
Subject: [issue3326] py3k shouldn't use -fno-strict-aliasing anymore
In-Reply-To: <1215605479.82.0.766368773223.issue3326@psf.upfronthosting.co.za>
Message-ID: <1277136722.66.0.255118556016.issue3326@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I think that this change could be backported to 3.1 branch. It doesn't cause any additional warnings, which are absent in py3k branch (see issue #8623). r79499 doesn't merge cleanly, so I'm attaching the patch for 3.1 branch.

----------
nosy: +Arfrever
Added file: http://bugs.python.org/file17732/python-3.1-issue3326.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3326>
_______________________________________

From report at bugs.python.org  Mon Jun 21 18:12:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Jun 2010 16:12:10 +0000
Subject: [issue9043] 2to3 doesn't handle byte comparison well
In-Reply-To: <1277131575.09.0.876680898489.issue9043@psf.upfronthosting.co.za>
Message-ID: <1277136730.94.0.664778996366.issue9043@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9043>
_______________________________________

From report at bugs.python.org  Mon Jun 21 18:12:35 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 21 Jun 2010 16:12:35 +0000
Subject: [issue8623] Aliasing warnings in socketmodule.c
In-Reply-To: <1273067856.13.0.617035378143.issue8623@psf.upfronthosting.co.za>
Message-ID: <1277136755.93.0.743136587594.issue8623@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/issue8623>
_______________________________________

From report at bugs.python.org  Mon Jun 21 18:13:56 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jun 2010 16:13:56 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <1277134087.11.0.549433673307.issue8854@psf.upfronthosting.co.za>
Message-ID: <4C1F8FD6.2060807@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Benjamin Peterson wrote:
> 
> Benjamin Peterson <benjamin at python.org> added the comment:
> 
> Applied patch in r82130. Thanks!

Thanks, Benjamin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Mon Jun 21 18:18:40 2010
From: report at bugs.python.org (Javier Collado)
Date: Mon, 21 Jun 2010 16:18:40 +0000
Subject: [issue9026] [argparse] Subcommands not printed in the same order they
	were added
In-Reply-To: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za>
Message-ID: <1277137120.97.0.148690038306.issue9026@psf.upfronthosting.co.za>


Javier Collado <javier.collado at gmail.com> added the comment:

Just for the record, please find attached an uglier patch for python < 2.7 that doesn't have the same problems as the first one I uploaded and passes all the test cases (tested with python 2.6).

----------
Added file: http://bugs.python.org/file17733/pre27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9026>
_______________________________________

From report at bugs.python.org  Mon Jun 21 18:30:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Jun 2010 16:30:22 +0000
Subject: [issue9041] raised exception is misleading
In-Reply-To: <1277123013.52.0.887079191328.issue9041@psf.upfronthosting.co.za>
Message-ID: <1277137822.74.0.128787515201.issue9041@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your report. Unfortunately, 2.6 and 3.1 are stable releases, they only get security and documentation fixes. 2.7 is nearly in the same state, since it?s at the release candidate stage. Can you check if your bug still applies to 3.2 (branch named ?py3k?) and propose a patch? Thanks again.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9041>
_______________________________________

From report at bugs.python.org  Mon Jun 21 18:41:46 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 21 Jun 2010 16:41:46 +0000
Subject: [issue9044] [optparse] confusion over an option and its value without
	any space in between
In-Reply-To: <1277136331.24.0.0452022727538.issue9044@psf.upfronthosting.co.za>
Message-ID: <1277138506.12.0.95469001254.issue9044@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I wouldn't say that is confusing -- it is a common usage to have an option immediately followed by it's value (see gcc output after running make, -Wall, etc).

----------
nosy: +brian.curtin
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9044>
_______________________________________

From report at bugs.python.org  Mon Jun 21 18:55:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Jun 2010 16:55:19 +0000
Subject: [issue8636] enumerate() test cases do not cover optional start
	argument
In-Reply-To: <1273153699.94.0.112049339171.issue8636@psf.upfronthosting.co.za>
Message-ID: <1277139319.54.0.253326228811.issue8636@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8636>
_______________________________________

From report at bugs.python.org  Mon Jun 21 19:04:22 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 21 Jun 2010 17:04:22 +0000
Subject: [issue3326] py3k shouldn't use -fno-strict-aliasing anymore
In-Reply-To: <1277136722.66.0.255118556016.issue3326@psf.upfronthosting.co.za>
Message-ID: <AANLkTinsFBQtjAkp8nal5VG4Ls_CKsoq6025AsUJGCIx@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/6/21 Arfrever Frehtes Taifersar Arahesis <report at bugs.python.org>:
>
> Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:
>
> I think that this change could be backported to 3.1 branch. It doesn't cause any additional warnings, which are absent in py3k branch (see issue #8623). r79499 doesn't merge cleanly, so I'm attaching the patch for 3.1 branch.

Thanks for the patch. Backported to in r82141.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3326>
_______________________________________

From report at bugs.python.org  Mon Jun 21 19:04:31 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 21 Jun 2010 17:04:31 +0000
Subject: [issue9041] raised exception is misleading
In-Reply-To: <1277123013.52.0.887079191328.issue9041@psf.upfronthosting.co.za>
Message-ID: <1277139871.96.0.911955328259.issue9041@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

"they only get security and documentation fixes"

2.6 does receive bug fixes. 2.5 is the version in security fix only mode.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9041>
_______________________________________

From report at bugs.python.org  Mon Jun 21 19:07:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Jun 2010 17:07:14 +0000
Subject: [issue9041] raised exception is misleading
In-Reply-To: <1277123013.52.0.887079191328.issue9041@psf.upfronthosting.co.za>
Message-ID: <1277140034.13.0.259802323608.issue9041@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks Brian, I?ll note that somewhere and be exact in the future.
*has to check the bugs he?s nosy on now to correct comments*

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9041>
_______________________________________

From report at bugs.python.org  Mon Jun 21 19:23:26 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 21 Jun 2010 17:23:26 +0000
Subject: [issue5468] urlencode does not handle "bytes",
	and could easily handle alternate encodings
In-Reply-To: <1236696316.6.0.478633045289.issue5468@psf.upfronthosting.co.za>
Message-ID: <1277141006.29.0.137834001886.issue5468@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The question of whether % escape should be limited to utf-8 or not was discussed and decided in favor of 'not' in #3300, quote and unquote.

Last December, a websig post (referenced yesterday on pydev) reported a 'problem' that would be solved by Miles' suggestion to include parse_qs and parse_qsl.

----------
nosy: +tjreedy
stage:  -> patch review
versions:  -Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5468>
_______________________________________

From report at bugs.python.org  Mon Jun 21 19:58:55 2010
From: report at bugs.python.org (Yoda_Uchiha)
Date: Mon, 21 Jun 2010 17:58:55 +0000
Subject: [issue9039] IDLE and module Doc
In-Reply-To: <1277073853.62.0.33861554581.issue9039@psf.upfronthosting.co.za>
Message-ID: <1277143135.13.0.960339935692.issue9039@psf.upfronthosting.co.za>


Yoda_Uchiha <MMPyro55 at gmail.com> added the comment:

But I need those to make windows and screens.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9039>
_______________________________________

From report at bugs.python.org  Mon Jun 21 20:02:21 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 21 Jun 2010 18:02:21 +0000
Subject: [issue9045] 2.7rc1: 64-bit OSX installer is not built with 64-bit
	tkinter
In-Reply-To: <1277143341.0.0.74848452771.issue9045@psf.upfronthosting.co.za>
Message-ID: <1277143341.0.0.74848452771.issue9045@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

It appears that we are building 64-bit mac installer starting 2.7. For http://python.org/ftp/python/2.7/python-2.7rc1-macosx10.5-2010-06-07.dmg

$ file /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so: Mach-O universal binary with 2 architectures
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so (for architecture ppc7400):     Mach-O bundle ppc
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so (for architecture i386):        Mach-O bundle i386

$ python2.7 -c "import _tkinter"
Traceback (most recent call last):
  File "<string>", line 1, in<module>
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so, 2): no suitable image found.  Did find:
        /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so: no matching architecture in universal wrapper
$

----------
assignee: ronaldoussoren
components: IDLE, Macintosh, Tkinter
messages: 108292
nosy: ronaldoussoren, srid
priority: normal
severity: normal
status: open
title: 2.7rc1: 64-bit OSX installer is not built with 64-bit tkinter
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9045>
_______________________________________

From report at bugs.python.org  Mon Jun 21 20:09:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Jun 2010 18:09:29 +0000
Subject: [issue8340] bytearray undocumented on trunk
In-Reply-To: <1270682579.64.0.491172746908.issue8340@psf.upfronthosting.co.za>
Message-ID: <1277143769.25.0.90252642362.issue8340@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

'bytes' is an alias for 'str' in 2.x, so it shouldn't be "documented" separately.
As for bytearray, yes, it should be added if not present.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8340>
_______________________________________

From report at bugs.python.org  Mon Jun 21 20:35:56 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jun 2010 18:35:56 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.3
In-Reply-To: <1277145356.65.0.792770780459.issue9046@psf.upfronthosting.co.za>
Message-ID: <1277145356.65.0.792770780459.issue9046@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

The RC2 builds fine on Mac OS X 10.6 (Snow Leopard), but fails to build any of the required extension modules on 10.3:

Python build finished, but the necessary bits to build these modules were not found:
_bsddb             gdbm               linuxaudiodev
ossaudiodev        readline           spwd
sunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
_AE                _AH                _App
_bisect            _CarbonEvt         _CF
_CG                _Cm                _codecs_cn
_codecs_hk         _codecs_iso2022    _codecs_jp
_codecs_kr         _codecs_tw         _collections
_csv               _Ctl               _ctypes
_ctypes_test       _curses            _curses_panel
_Dlg               _Drag              _elementtree
_Evt               _File              _Fm
_Folder            _functools         _hashlib
_heapq             _Help              _hotshot
_IBCarbon          _Icn               _io
_json              _Launch            _List
_locale            _lsprof            _Menu
_Mlte              _multibytecodec    _multiprocessing
_OSA               _Qd                _Qdoffs
_Qt                _random            _Res
_Scrap             _sha256            _sha512
_Snd               _socket            _sqlite3
_ssl               _struct            _TE
_testcapi          _tkinter           _weakref
_Win               array              audioop
autoGIL            binascii           bsddb185
bz2                cmath              ColorPicker
cPickle            crypt              cStringIO
datetime           dbm                dl
fcntl              future_builtins    gestalt
grp                icglue             imageop
itertools          MacOS              math
mmap               Nav                nis
operator           OSATerminology     parser
pyexpat            resource           select
strop              syslog             termios
time               unicodedata        zlib

Example:

building '_struct' extension
gcc-4.0 -fno-strict-aliasing -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/usr/local/src/egenix-build-environment/Python-2.7rc2-ucs2/Mac/Include -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/src/egenix-build-environment/Python-2.7rc2-ucs2/Include -I/usr/local/src/egenix-build-environment/Python-2.7rc2-ucs2 -c _struct.c -o build/temp.macosx-10.4-fat-2.7/_struct.o
powerpc-apple-darwin8-gcc-4.0.1: _struct.c: No such file or directory
powerpc-apple-darwin8-gcc-4.0.1: no input files
i686-apple-darwin8-gcc-4.0.1: _struct.c: No such file or directory
i686-apple-darwin8-gcc-4.0.1: no input files
lipo: can't figure out the architecture type of: /var/tmp//cckP7ZEq.out
...

These were the used configure options:

./configure  --prefix=/usr/local/python-2.7-ucs2 --enable-unicode=ucs2 --enable-universalsdk MACOSX_DEPLOYMENT_TARGET=10.4

----------
assignee: ronaldoussoren
components: Build
messages: 108294
nosy: lemburg, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python 2.7rc2 doesn't build on Mac OS X 10.3
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Mon Jun 21 20:38:13 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jun 2010 18:38:13 +0000
Subject: [issue9047] Python 2.7rc2 includes -isysroot twice on each gcc
	command line
In-Reply-To: <1277145493.52.0.0439952052215.issue9047@psf.upfronthosting.co.za>
Message-ID: <1277145493.52.0.0439952052215.issue9047@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

A typical build line looks like this:

gcc-4.0 -c -fno-strict-aliasing -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include -isysroot /Developer/SDKs/MacOSX10.4u.sdk   -DPy_BUILD_CORE -o Python/codecs.o Python/codecs.c

With older Xcode releases, the above is known not to work at all: gcc simply gives up and raises an error. With the latest Xcode available for 10.3 (last release + all patches), gcc accepts the extra options, but it's not clear whether the resulting code will work... mostly due to #9046: Python 2.7rc2 doesn't build on Mac OS X 10.3.

The two issues could also be connected.

----------
assignee: ronaldoussoren
components: Build
messages: 108295
nosy: lemburg, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python 2.7rc2 includes -isysroot twice on each gcc command line
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9047>
_______________________________________

From report at bugs.python.org  Mon Jun 21 20:39:35 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jun 2010 18:39:35 +0000
Subject: [issue9047] Python 2.7rc2 includes -isysroot twice on each gcc
	command line
In-Reply-To: <1277145493.52.0.0439952052215.issue9047@psf.upfronthosting.co.za>
Message-ID: <1277145575.42.0.100305468856.issue9047@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Note that the duplicate insertion of -isysroot happens because CPPFLAGS was changed to include this extra option. 

Since PY_CFLAGS includes both CFLAGS and CPPFLAGS, you get the duplicate occurrence.

In Python 2.6, the extra option did appear in CPPFLAGS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9047>
_______________________________________

From report at bugs.python.org  Mon Jun 21 20:44:25 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jun 2010 18:44:25 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.3
In-Reply-To: <1277145356.65.0.792770780459.issue9046@psf.upfronthosting.co.za>
Message-ID: <1277145865.36.0.223382199308.issue9046@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Mon Jun 21 20:44:56 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 21 Jun 2010 18:44:56 +0000
Subject: [issue9018] os.path.normcase(None) does not raise an error on linux
	and should
In-Reply-To: <1276977655.35.0.854993397938.issue9018@psf.upfronthosting.co.za>
Message-ID: <20100621183827.GB10192@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Sat, Jun 19, 2010 at 08:00:55PM +0000, Shashwat Anand wrote:
> Why on Mac OS X, it should return s.lower() ?

That is is because some file systems on Mac OS X are case-sensitive.

> def normcase(s):
>     """Normalize case of pathname.  Has no effect under Posix"""
>     if s is None:  
>         raise AttributeError
>     return s

It should be a TypeError, not AttributeError. (Attached Test cases
checks it properly)

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9018>
_______________________________________

From report at bugs.python.org  Mon Jun 21 21:08:04 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jun 2010 19:08:04 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.3
In-Reply-To: <1277145356.65.0.792770780459.issue9046@psf.upfronthosting.co.za>
Message-ID: <1277147284.08.0.0451570358191.issue9046@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Some debugging shows that the ext.sources list in setup.py does not include the "Modules/" prefix for the source files:

*** moddirlist=['/usr/local/src/egenix-build-environment/Python-2.7rc2-ucs2/Modules', '/usr/local/src/egenix-build-environment/Python-2.7rc2-ucs2/Mac/Modules']

but:

*** Extension _struct: ext.sources=['_struct.c']
*** Extension _ctypes_test: ext.sources=['_ctypes/_ctypes_test.c']
*** Extension _weakref: ext.sources=['_weakref.c']
*** Extension array: ext.sources=['arraymodule.c']
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Mon Jun 21 21:13:53 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 21 Jun 2010 19:13:53 +0000
Subject: [issue9021] no copy.copy problem description
In-Reply-To: <1276816713.34.0.416523004663.issue9021@psf.upfronthosting.co.za>
Message-ID: <1277147633.03.0.107110137762.issue9021@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The intro paragraph currently (3.2a) consists of
"This module provides generic (shallow and deep) copying operations."

This could be expanded to '''
Assignment statements create bindings between a target and an object. They never duplicate or copy an existing object. For collections that are mutable or contain mutable items, a copy is sometimes needed so one can change one copy without changing the other. Sequences can be shallow copied by slicing the entire sequence(s[:]). (See below for the meaning of 'shallow'.) Some objects can be shallow copied with their class constructors (tuple, list, set, dict). This module provides generic shallow *and* deep copying operations. The latter is not otherwise available in an single operation or call.'''

----------
nosy: +tjreedy
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9021>
_______________________________________

From report at bugs.python.org  Mon Jun 21 21:21:48 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 21 Jun 2010 19:21:48 +0000
Subject: [issue9021] no copy.copy problem description
In-Reply-To: <1276816713.34.0.416523004663.issue9021@psf.upfronthosting.co.za>
Message-ID: <1277148108.9.0.805678976256.issue9021@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Shorter and better version.

Assignment statements create bindings between a target and an object. They never duplicate or copy an existing object. For collections that are mutable or contain mutable items, a copy is sometimes needed so one can change one copy without changing the other. This module provides generic shallow and deep copy operations (explained below). Shallow copies can also be obtained by whole sequence slicing (s[:]) and some class constructors (tuple, list, set, dict).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9021>
_______________________________________

From report at bugs.python.org  Mon Jun 21 21:21:49 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jun 2010 19:21:49 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.3
In-Reply-To: <1277145356.65.0.792770780459.issue9046@psf.upfronthosting.co.za>
Message-ID: <1277148109.99.0.56534250065.issue9046@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Turns out that find_file() always returns None for the shared mods:

*** module _struct.c in ['/usr/local/src/egenix-build-environment/Python-2.7rc2-ucs2/Modules', '/usr/local/src/egenix-build-environment/Python-2.7rc2-ucs2/Mac/Modules']: find_file returned None
*** Extension _struct: ext.sources=['_struct.c']

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Mon Jun 21 21:25:43 2010
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 21 Jun 2010 19:25:43 +0000
Subject: [issue9048] no OS X buildbots in the stable list
In-Reply-To: <1277148342.98.0.18086046529.issue9048@psf.upfronthosting.co.za>
Message-ID: <1277148342.98.0.18086046529.issue9048@psf.upfronthosting.co.za>


New submission from Bill Janssen <bill.janssen at gmail.com>:

Considering the number of OS X machines running Python programs, it would be good idea to get this platform into the "stable" list of buildbots so that releases are checked against it.

----------
messages: 108302
nosy: janssen
priority: normal
severity: normal
status: open
title: no OS X buildbots in the stable list
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9048>
_______________________________________

From report at bugs.python.org  Mon Jun 21 21:26:47 2010
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 21 Jun 2010 19:26:47 +0000
Subject: [issue9048] no OS X buildbots in the stable list
In-Reply-To: <1277148342.98.0.18086046529.issue9048@psf.upfronthosting.co.za>
Message-ID: <1277148407.61.0.985417748848.issue9048@psf.upfronthosting.co.za>


Changes by Bill Janssen <bill.janssen at gmail.com>:


----------
components: +None
keywords: +buildbot
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9048>
_______________________________________

From report at bugs.python.org  Mon Jun 21 21:30:04 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jun 2010 19:30:04 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.3
In-Reply-To: <1277145356.65.0.792770780459.issue9046@psf.upfronthosting.co.za>
Message-ID: <1277148604.85.0.489125172474.issue9046@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Instrumenting find_file() a bit:

    if sys.platform == 'darwin':
        # Honor the MacOSX SDK setting when one was specified.
        # An SDK is a directory with the same structure as a real
        # system, but with only header files and libraries.
        sysroot = macosx_sdk_root()

    # Check the standard locations
    for dir in std_dirs:
        f = os.path.join(dir, filename)

        if sys.platform == 'darwin' and is_macosx_sdk_path(dir):
            f = os.path.join(sysroot, dir[1:], filename)

        print '*** checking standard location %s' % f
        if os.path.exists(f): return []

this gives:

*** checking additional location /Developer/SDKs/MacOSX10.4u.sdk/usr/local/src/egenix-build-environment/Python-2.7rc2-ucs2/Modules/_struct.c
*** checking additional location /Developer/SDKs/MacOSX10.4u.sdk/usr/local/src/egenix-build-environment/Python-2.7rc2-ucs2/Mac/Modules/_struct.c
*** module _struct.c in ['/usr/local/src/egenix-build-environment/Python-2.7rc2-ucs2/Modules', '/usr/local/src/egenix-build-environment/Python-2.7rc2-ucs2/Mac/Modules']: find_file returned None
*** Extension _struct: ext.sources=['_struct.c']

So the reason for the failure is that is_macosx_sdk_path(dir) doesn't do what it's probably supposed to do, or the code assumes that it's getting relative paths in moddirslist rather the absolute paths it is getting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Mon Jun 21 21:34:27 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jun 2010 19:34:27 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.3
In-Reply-To: <1277145356.65.0.792770780459.issue9046@psf.upfronthosting.co.za>
Message-ID: <1277148867.17.0.518770695919.issue9046@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Note that I've not checked whether an SDK build works on Mac OS X 10.6. The regular build does work.

The problem appears to be related to SDK builds only, e.g. if you plan to build Universal binary on Mac OS X 10.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Mon Jun 21 21:34:38 2010
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 21 Jun 2010 19:34:38 +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: <1277148878.19.0.151345601243.issue8959@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Thanks, Michael, for reporting this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8959>
_______________________________________

From report at bugs.python.org  Mon Jun 21 21:46:39 2010
From: report at bugs.python.org (Andreas Hofmeister)
Date: Mon, 21 Jun 2010 19:46:39 +0000
Subject: [issue9049] UnboundLocalError in nested function
In-Reply-To: <1277149599.18.0.763779339646.issue9049@psf.upfronthosting.co.za>
Message-ID: <1277149599.18.0.763779339646.issue9049@psf.upfronthosting.co.za>


New submission from Andreas Hofmeister <andreas.hofmeister at yahoo.de>:

Description:
An unexpected UnboundLocalError is produced when assigning a value to a variable inside a nested function. The first assignment to the variable is in the enclosing function.

Example:
def x():
     a = False
     def y():
         print a
         a = True
     return y

Calling x()() produces an UnboundLocalError on the 'print a' line.
If the 'a = True' line is removed, no error occurs.

Tested with:
  - 2.5.1
  - 2.6.5

Keywords: 
Nested function, UnboundLocalError, variable assignment

Thank you for your attention

----------
components: Interpreter Core
messages: 108306
nosy: Andreas Hofmeister
priority: normal
severity: normal
status: open
title: UnboundLocalError in nested function
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9049>
_______________________________________

From report at bugs.python.org  Mon Jun 21 21:46:41 2010
From: report at bugs.python.org (Andreas Hofmeister)
Date: Mon, 21 Jun 2010 19:46:41 +0000
Subject: [issue9050] UnboundLocalError in nested function
In-Reply-To: <1277149601.0.0.820188048763.issue9050@psf.upfronthosting.co.za>
Message-ID: <1277149601.0.0.820188048763.issue9050@psf.upfronthosting.co.za>


New submission from Andreas Hofmeister <andreas.hofmeister at yahoo.de>:

Description:
An unexpected UnboundLocalError is produced when assigning a value to a variable inside a nested function. The first assignment to the variable is in the enclosing function.

Example:
def x():
     a = False
     def y():
         print a
         a = True
     return y

Calling x()() produces an UnboundLocalError on the 'print a' line.
If the 'a = True' line is removed, no error occurs.

Tested with:
  - 2.5.1
  - 2.6.5

Keywords: 
Nested function, UnboundLocalError, variable assignment

Thank you for your attention

----------
components: Interpreter Core
messages: 108307
nosy: Andreas Hofmeister
priority: normal
severity: normal
status: open
title: UnboundLocalError in nested function
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9050>
_______________________________________

From report at bugs.python.org  Mon Jun 21 21:51:27 2010
From: report at bugs.python.org (Andreas Hofmeister)
Date: Mon, 21 Jun 2010 19:51:27 +0000
Subject: [issue9050] UnboundLocalError in nested function
In-Reply-To: <1277149601.0.0.820188048763.issue9050@psf.upfronthosting.co.za>
Message-ID: <1277149887.43.0.0232904190456.issue9050@psf.upfronthosting.co.za>


Andreas Hofmeister <andreas.hofmeister at yahoo.de> added the comment:

Duplicate of 9049.

Sorry for the inconvenience.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9050>
_______________________________________

From report at bugs.python.org  Mon Jun 21 21:52:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Jun 2010 19:52:02 +0000
Subject: [issue9050] UnboundLocalError in nested function
In-Reply-To: <1277149601.0.0.820188048763.issue9050@psf.upfronthosting.co.za>
Message-ID: <1277149922.16.0.304358184028.issue9050@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9050>
_______________________________________

From report at bugs.python.org  Mon Jun 21 21:52:42 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Jun 2010 19:52:42 +0000
Subject: [issue9049] UnboundLocalError in nested function
In-Reply-To: <1277149599.18.0.763779339646.issue9049@psf.upfronthosting.co.za>
Message-ID: <1277149962.03.0.875525034353.issue9049@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This isn't a bug;  it's by design.

Because there's an assignment to 'a' in the function 'y', 'a' is considered local to that function.  (It doesn't matter where the assignment happens within the function;  the presence of an assignment anywhere is enough to make 'a' local for the entirety of 'y'.)

This is described in the reference manual at:

http://docs.python.org/reference/executionmodel.html#naming-and-binding

See the paragraph beginning:

"If a name binding operation occurs anywhere within a code block, "

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9049>
_______________________________________

From report at bugs.python.org  Mon Jun 21 21:55:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Jun 2010 19:55:05 +0000
Subject: [issue9049] UnboundLocalError in nested function
In-Reply-To: <1277149599.18.0.763779339646.issue9049@psf.upfronthosting.co.za>
Message-ID: <1277150106.0.0.758249134092.issue9049@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9049>
_______________________________________

From report at bugs.python.org  Mon Jun 21 21:55:50 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 21 Jun 2010 19:55:50 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1277150150.62.0.715173651422.issue9025@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

'Random', without qualification, is commonly taken to mean 'with uniform distribution'. Otherwise it has no specific meaning and could well be a synonym for 'arbitrary' or 'haphazard'.

The behavior reported is buggy and in my opinion should be fixed if possible. I have done simulation research in the past and do not consider them minor. If I had results that depended on these functions, I might want to rerun with the fixed versions to make sure the end results were not affected. I would certainly want the fixed behavior for any future work.

I do not see any promise of reproducibility of sequences from version to version. I do not really see the point as one can rerun with the old Python version or copy the older random.py.

The old versions could be kept with with an 'old_' prefix and documented in a separate subsection that starts with "Do not use these buggy old versions of x and y in new code. They are only present for those who want to reproduce old sequences." But I wonder how many people would use them.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Mon Jun 21 21:57:39 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jun 2010 19:57:39 +0000
Subject: [issue8949] PyArg_Parse*(): "z" should not accept bytes
In-Reply-To: <1276904794.69.0.0381162151509.issue8949@psf.upfronthosting.co.za>
Message-ID: <4C1FC430.3050607@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:
> 
> @lemburg: So what is your opinion on this issue?

You're probably right: it's too late to change "s" to accept buffer
interface compatible objects as well.

In that case, symmetry is more important, so +1 on rejecting bytes
for "z" as well.

Please add a note to the NEWS file for this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8949>
_______________________________________

From report at bugs.python.org  Mon Jun 21 22:09:51 2010
From: report at bugs.python.org (Thomas Jollans)
Date: Mon, 21 Jun 2010 20:09:51 +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: <1277150991.51.0.563306853587.issue8990@psf.upfronthosting.co.za>


Thomas Jollans <thomas at jollans.com> added the comment:

Thanks for the input. I'm going to re-work the patch a bit (releasing buffers and such) and add a test within the next few days. 

The question remains whether or not to accept other buffers with itemsize == 1. The way I understand it, fromstring already accepted any read-only buffer object, no matter the item size / whether it actually makes sense to call it a "string". I don't think accepting a hypothetical read-only buffer with items wider than 1 in fromstring (yes, bad naming) is desirable behaviour - I see a few options on how to deal with input validation:

1. ignore the item size. This'd be similar to current behaviour, plus r/w buffers

2. only accept byte-based buffers. ("things that look like 'const char*'") - this is what I've been aiming at.

3. only accept bytes and bytearray, and let the user think about how to deal with other objects. Question is - shouldn't array('B') be treated like bytearray in this respect?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8990>
_______________________________________

From report at bugs.python.org  Mon Jun 21 22:15:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 21 Jun 2010 20:15:09 +0000
Subject: [issue9051] Cannot pickle timezone instances
In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za>
Message-ID: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

>>> s = pickle.dumps(timezone.utc)
>>> pickle.loads(s)
Traceback (most recent call last):
 ..
TypeError: ("Required argument 'offset' (pos 1) not found", <class 'datetime.timezone'>, ())

----------
assignee: belopolsky
messages: 108313
nosy: belopolsky
priority: normal
severity: normal
stage: unit test needed
status: open
title: Cannot pickle timezone instances
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9051>
_______________________________________

From report at bugs.python.org  Mon Jun 21 22:34:38 2010
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 21 Jun 2010 20:34:38 +0000
Subject: [issue9052] 2.7rc2 fails test_urllib_localnet tests on OS X
In-Reply-To: <1277152478.13.0.221509017711.issue9052@psf.upfronthosting.co.za>
Message-ID: <1277152478.13.0.221509017711.issue9052@psf.upfronthosting.co.za>


New submission from Bill Janssen <bill.janssen at gmail.com>:

% ./python.exe -Wd -3 -E -tt ./Lib/test/regrtest.py -v test_urllib2_localnet
== CPython 2.7rc2 (r27rc2:82137, Jun 21 2010, 12:50:22) [GCC 4.0.1 (Apple Inc. build 5493)]
==   Darwin-9.8.0-i386-32bit little-endian
==   /private/tmp/Python-2.7rc2/build/test_python_58063
test_urllib2_localnet
test_proxy_qop_auth_int_works_or_throws_urlerror (test.test_urllib2_localnet.ProxyAuthTests) ... ok
test_proxy_qop_auth_works (test.test_urllib2_localnet.ProxyAuthTests) ... ok
test_proxy_with_bad_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ... FAIL
test_proxy_with_no_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ... FAIL
test_200 (test.test_urllib2_localnet.TestUrlopen) ... ok
test_200_with_parameters (test.test_urllib2_localnet.TestUrlopen) ... ok
test_404 (test.test_urllib2_localnet.TestUrlopen) ... ok
test_bad_address (test.test_urllib2_localnet.TestUrlopen) ... ok
test_basic (test.test_urllib2_localnet.TestUrlopen) ... ok
test_geturl (test.test_urllib2_localnet.TestUrlopen) ... ok
test_info (test.test_urllib2_localnet.TestUrlopen) ... ok
test_redirection (test.test_urllib2_localnet.TestUrlopen) ... ok
test_sending_headers (test.test_urllib2_localnet.TestUrlopen) ... ok

======================================================================
FAIL: test_proxy_with_bad_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/private/tmp/Python-2.7rc2/Lib/test/test_urllib2_localnet.py", line 264, in test_proxy_with_bad_password_raises_httperror
    self.URL)
AssertionError: HTTPError not raised

======================================================================
FAIL: test_proxy_with_no_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/private/tmp/Python-2.7rc2/Lib/test/test_urllib2_localnet.py", line 270, in test_proxy_with_no_password_raises_httperror
    self.URL)
AssertionError: HTTPError not raised

----------------------------------------------------------------------
Ran 13 tests in 9.050s

FAILED (failures=2)
test test_urllib2_localnet failed -- multiple errors occurred
1 test failed:
    test_urllib2_localnet
/tmp/Python-2.7rc2 397 %

----------
messages: 108314
nosy: janssen
priority: high
severity: normal
stage: needs patch
status: open
title: 2.7rc2 fails test_urllib_localnet tests on OS X
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9052>
_______________________________________

From report at bugs.python.org  Mon Jun 21 22:48:20 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Jun 2010 20:48:20 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.3
In-Reply-To: <1277145356.65.0.792770780459.issue9046@psf.upfronthosting.co.za>
Message-ID: <1277153300.21.0.954932626815.issue9046@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

As far as I know, it is not supported to "upbuild" Python (or anything else) on OS X, i.e. you cannot use a higher level SDK (i.e. 10.4u) to build on an earlier system (i.e. 10.3).  In particular, to build Python with a deployment target of 10.3, you need to build on 10.4 or higher with the 10.4u SDK.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Mon Jun 21 22:54:11 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jun 2010 20:54:11 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4
In-Reply-To: <1277145356.65.0.792770780459.issue9046@psf.upfronthosting.co.za>
Message-ID: <1277153651.18.0.942528091574.issue9046@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Sorry, my bad. The system in question is a 10.4 Tiger system.

----------
title: Python 2.7rc2 doesn't build on Mac OS X 10.3 -> Python 2.7rc2 doesn't build on Mac OS X 10.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Mon Jun 21 22:54:46 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 21 Jun 2010 20:54:46 +0000
Subject: [issue9048] no OS X buildbots in the stable list
In-Reply-To: <1277148342.98.0.18086046529.issue9048@psf.upfronthosting.co.za>
Message-ID: <1277153686.31.0.646581113163.issue9048@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

"stable" is also meant to mean "typically passes test suite without errors". I don't think OSX meets this criterion.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9048>
_______________________________________

From report at bugs.python.org  Mon Jun 21 22:55:27 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Jun 2010 20:55:27 +0000
Subject: [issue9045] 2.7rc1: 64-bit OSX installer is not built with 64-bit
	tkinter
In-Reply-To: <1277143341.0.0.74848452771.issue9045@psf.upfronthosting.co.za>
Message-ID: <1277153727.02.0.274450773522.issue9045@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I believe the issue was that there was no supported 64-bit non-X Tk available for 10.5. Has that changed?  Otherwise, the build process and Tkinter need to be modified to dynamically link with more than one version of Tk, something that has been discussed but, AFAIK, not implemented.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9045>
_______________________________________

From report at bugs.python.org  Mon Jun 21 23:32:17 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 21 Jun 2010 21:32:17 +0000
Subject: [issue9018] os.path.normcase(None) does not raise an error on linux
	and should
In-Reply-To: <1276782016.7.0.192519527211.issue9018@psf.upfronthosting.co.za>
Message-ID: <1277155937.24.0.218989761989.issue9018@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

ntpath and macpath raise an AttributeError, so we could:
1) change them all to accept only bytes/str and raise a TypeError for other wrong types (correct, consistent, non-backward-compatible);
2) change only posixpath to raise a TypeError for wrong types (partially correct, inconsistent, backward-compatible);
3) change only posixpath to raise an AttributeError for wrong types (wrong, consistent, backward-compatible);

The option 2 is still an improvement over the current situation, but it would be better to find a backward-compatible way to also obtain option 1 (assuming that backward compatibility is a concern here -- and I think it is (even though people could just change the code to catch (AttributeError, TypeError) and eventually get rid of the AttributeError)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9018>
_______________________________________

From report at bugs.python.org  Mon Jun 21 23:39:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Jun 2010 21:39:21 +0000
Subject: [issue9018] os.path.normcase(None) does not raise an error on linux
	and should
In-Reply-To: <1277155937.24.0.218989761989.issue9018@psf.upfronthosting.co.za>
Message-ID: <1277156354.3369.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> ntpath and macpath raise an AttributeError, so we could:
> 1) change them all to accept only bytes/str and raise a TypeError for
> other wrong types (correct, consistent, non-backward-compatible);

Sounds like the best thing to do.

> The option 2 is still an improvement over the current situation, but
> it would be better to find a backward-compatible way to also obtain
> option 1 (assuming that backward compatibility is a concern here --
> and I think it is (even though people could just change the code to
> catch (AttributeError, TypeError) and eventually get rid of the
> AttributeError)).

This isn't an exception you catch at runtime. It's an exception you get
when your code is wrong, and then you fix your code. Therefore I don't
think backwards compatibility is important.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9018>
_______________________________________

From report at bugs.python.org  Tue Jun 22 00:03:31 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 21 Jun 2010 22:03:31 +0000
Subject: [issue9053] distutils compiles extensions so that Python.h cannot be
	found
In-Reply-To: <1277157811.25.0.502780750068.issue9053@psf.upfronthosting.co.za>
Message-ID: <1277157811.25.0.502780750068.issue9053@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at twistedmatrix.com>:

With a checkout of the py3k branch, building an extension module using distutils fails:

  error: Python.h: No such file or directory

This is clearly because the wrong -I option is being supplied:

  gcc -pthread -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/exarkun/Projects/python-signalfd/trunk/Include -I/home/exarkun/Projects/python/branches/py3k -c signalfd/_signalfd.c -o build/temp.linux-i686-3.2/signalfd/_signalfd.o

Building the extension with Python 3.1 all the way back through Python 2.3 does work, though.

----------
assignee: tarek
components: Distutils
messages: 108321
nosy: exarkun, tarek
priority: critical
severity: normal
status: open
title: distutils compiles extensions so that Python.h cannot be found
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9053>
_______________________________________

From report at bugs.python.org  Tue Jun 22 00:04:05 2010
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Mon, 21 Jun 2010 22:04:05 +0000
Subject: [issue3439] create a numbits() method for int and long types
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1277157845.73.0.885521494438.issue3439@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

There is a small mistake in the docs:

def bit_length(x):
    'Number of bits necessary to represent self in binary.'
    s = bin(x)          # binary representation:  bin(-37) --> '-0b100101'
    s = s.lstrip('-0b') # remove leading zeros and minus sign
    return len(s)       # len('100101') --> 6

is probably supposed to be:

def bit_length(x):
    'Number of bits necessary to represent x in binary.'
    s = bin(x)          # binary representation:  bin(-37) --> '-0b100101'
    s = s.lstrip('-0b') # remove leading zeros and minus sign
    return len(s)       # len('100101') --> 6

----------
nosy: +zooko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Tue Jun 22 00:12:50 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 21 Jun 2010 22:12:50 +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: <1277158370.27.0.787157062055.issue9054@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

pyexpat configured with "--with-system-expat" segfaults in one selftest when built against expat 2.0.1

SVN trunk:
$ ./configure --with-system-expat
(with expat-2.0.1)
$ make
$ ./python Lib/test/test_pyexpat.py
[snip]
test_parse_only_xml_data (__main__.sf1296433Test) ... Segmentation fault (core dumped)

The issue occurs when an exception happens within a character handler.

When a Python exception is raised inside pyexpat.c:call_character_handler(), it invokes pyexpat.c:flag_error() which clears the pyexpat object's handlers, and it then sets the expat structure's handler to a no-op handler:
        XML_SetCharacterDataHandler(self->itself,
                                    noop_character_data_handler);

The reason why appears to be that python's copy of that code in xmlparse.c:doContent() looks like this:
            characterDataHandler(handlerArg, dataBuf,
                                 (int)(dataPtr - (ICHAR *)dataBuf));

(see
http://svn.python.org/view/python/trunk/Modules/expat/xmlparse.c?annotate=77680&pathrev=77680#l2544
)

i.e. using:
  #define characterDataHandler (parser->m_characterDataHandler)
to look up the handler each time, thus picking up on the newly installed noop handler, whereas the corresponding code in expat 2.0.1 looks like this:

        XML_CharacterDataHandler charDataHandler = characterDataHandler;
        if (charDataHandler) {
            ...
            for (;;) {
              ...
=>            charDataHandler(handlerArg, dataBuf,
                              (int)(dataPtr - (ICHAR *)dataBuf));
              ...
            }
          }

i.e. keeping the old function pointer cached

(gdb) p self->itself->m_characterDataHandler 
$30 = (XML_CharacterDataHandler) 0xf8b370 <noop_character_data_handler>

(gdb) p charDataHandler
$31 = (XML_CharacterDataHandler) 0xf8daf0 <my_CharacterDataHandler>

So when the exception is raised and the handler is changed, the local in the loop doesn't change, and we're calling the old handler which doesn't allow for being in the error-recovery state, and self->handlers[3] is NULL, leading to an eventual segfault.

This is with expat-2.0.1-10.fc13.i686 on a Fedora 13 box.

expat's xmlparse.c's caching of the character handler appears to be this
change:
http://expat.cvs.sourceforge.net/viewvc/expat/expat/lib/xmlparse.c?r1=1.157&r2=1.158

> Revision 1.158 - (view) (download) (annotate) - [select for diffs] 
> Mon Jul 10 18:59:52 2006 UTC (3 years, 10 months ago) by kwaclaw 
> Branch: MAIN 
> Changes since 1.157: +39 -37 lines 
> Diff to previous 1.157
> Improved fix for issues # 1515266 and # 1515600. Will now preserve the
> "failover to default handler" logic. Note: clearing the character data handler
> does not take effect immediately anymore.

which is almost 4 years old (2006-07-10)

For reference the issues referred to above are:
http://sourceforge.net/tracker/?func=detail&aid=1515266&group_id=10127&atid=110127
http://sourceforge.net/tracker/?func=detail&aid=1515600&group_id=10127&atid=110127

expat CVS R_2_0_0 has xmlparse.c r1.151 from 2005-12-23
expat CVS R_2_0_1 has xmlparse.c r1.161 from 2007-05-08

So it appears that this "clearing the character data handler does not take
effect immediately anymore." is in expat 2.0.1 onwards, but not in 2.0.0

Running:
$ diff -rup ~/coding/python-svn/trunk-clean/Modules/expat
/usr/src/debug/expat-2.0.1/lib/|less
to show the difference between system expat and latest python SVN code
indicates that we're using 2.0.1 as the system copy, and latest Python SVN code
is using a copy of 2.0.0

Looking at http://bugs.python.org/issue1296433 (as per the test name), this was fixed in r47191 (see http://svn.python.org/view?view=rev&revision=47191 ) on 2006-07-01, adding a termination clause to the loop within its copy of xmlparse.c but this was followed five days later (2006-07-06) with:
http://svn.python.org/view?view=rev&revision=47253
which had the log:
> - back out Expat change; the final fix to Expat will be different
> - change the pyexpat wrapper to not be so sensitive to this detail of the
>  Expat implementation (the ex-crasher test still passes)

though this change happened before the change in expat on 2006-07-10

So, _if_ I'm reading this right, it appears that Python's pyexpat.c module is incompatible with expat 2.0.1: pyexpat expects that when it sets:
    XML_SetCharacterDataHandler(self->itself,
                                noop_character_data_handler);
that my_CharacterDataHandler will no longer be called, but it is, and it segfaults during the test.

Working around it appears trivial; I will attach a patch.

----------
components: XML
messages: 108323
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: pyexpat configured with "--with-system-expat" is incompatible with expat 2.0.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9054>
_______________________________________

From report at bugs.python.org  Tue Jun 22 00:15:18 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 21 Jun 2010 22:15:18 +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: <1277158518.24.0.0907957441195.issue9054@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

With the attached patch all of Lib/test/test_pyexpat.py passes.

----------
keywords: +patch
Added file: http://bugs.python.org/file17734/fix-issue-9054.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9054>
_______________________________________

From report at bugs.python.org  Tue Jun 22 00:16:42 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 21 Jun 2010 22:16:42 +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: <1277158602.51.0.56071900251.issue9054@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
stage:  -> patch review
type:  -> crash
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9054>
_______________________________________

From report at bugs.python.org  Tue Jun 22 00:19:16 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 21 Jun 2010 22:19:16 +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: <1277158756.98.0.544759169917.issue9054@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

For reference, I'm tracking this downstream here: https://bugzilla.redhat.com/show_bug.cgi?id=583931

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9054>
_______________________________________

From report at bugs.python.org  Tue Jun 22 00:31:45 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 21 Jun 2010 22:31:45 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1277159505.47.0.104206444274.issue8621@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Reopening since test failures are reported on python-dev:

[...]
test_uuid
test test_uuid failed -- Traceback (most recent call last):
  File "/private/tmp/Python-2.7rc2/Lib/test/test_uuid.py", line 472, in testIssue8621
    self.assertNotEqual(parent_value, child_value)
AssertionError: '8395a08e40454895be537a180539b7fb' == '8395a08e40454895be537a180539b7fb'

[...]

----------
nosy: +skrah
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8621>
_______________________________________

From report at bugs.python.org  Tue Jun 22 00:38:54 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 21 Jun 2010 22:38:54 +0000
Subject: [issue9052] 2.7rc2 fails test_urllib_localnet tests on OS X
In-Reply-To: <1277152478.13.0.221509017711.issue9052@psf.upfronthosting.co.za>
Message-ID: <1277159934.97.0.0221239313072.issue9052@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Looks like a duplicate of issue 8455.  Leaving open so that someone else could sort out the priority.

----------
nosy: +belopolsky
superseder:  -> buildbot: test_urllib2_localnet failures (Connection refused) on Tiger buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9052>
_______________________________________

From report at bugs.python.org  Tue Jun 22 00:39:29 2010
From: report at bugs.python.org (Paul Moore)
Date: Mon, 21 Jun 2010 22:39:29 +0000
Subject: [issue9055] test_issue_8959_b fails when run from a service
In-Reply-To: <1277159969.39.0.181729867437.issue9055@psf.upfronthosting.co.za>
Message-ID: <1277159969.39.0.181729867437.issue9055@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

test_issue_8959_b fails when run from a service (in this case, from a buildslave running as a service).

It appears to count the number of open windows, expecting a non-zero value. But when run as a service, it looks like the return count is (correctly) zero.

FAIL: test_issue_8959_b (ctypes.test.test_callbacks.SampleCallbacksTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
 File "C:\buildslave\trunk.moore-windows\build\lib\ctypes\test\test_callbacks.py",
line 208, in test_issue_8959_b
   self.assertFalse(windowCount == 0)
AssertionError: True is not False

----------
assignee: theller
components: ctypes
keywords: buildbot
messages: 108328
nosy: pmoore, theller
priority: normal
severity: normal
status: open
title: test_issue_8959_b fails when run from a service
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9055>
_______________________________________

From report at bugs.python.org  Tue Jun 22 01:01:09 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 21 Jun 2010 23:01:09 +0000
Subject: [issue9018] os.path.normcase(None) does not raise an error on linux
	and should
In-Reply-To: <1276782016.7.0.192519527211.issue9018@psf.upfronthosting.co.za>
Message-ID: <1277161269.54.0.864320445399.issue9018@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here is the patch.

----------
assignee:  -> ezio.melotti
components: +Library (Lib)
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file17735/issue9018-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9018>
_______________________________________

From report at bugs.python.org  Tue Jun 22 01:17:52 2010
From: report at bugs.python.org (v_peter)
Date: Mon, 21 Jun 2010 23:17:52 +0000
Subject: [issue9042] Gettext cache and classes
In-Reply-To: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>
Message-ID: <1277162272.95.0.55345451359.issue9042@psf.upfronthosting.co.za>


Changes by v_peter <leanmeandonothingmachine at gmail.com>:


----------
keywords: +patch
versions: +Python 3.2 -Python 2.6
Added file: http://bugs.python.org/file17736/class_cache.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9042>
_______________________________________

From report at bugs.python.org  Tue Jun 22 02:37:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 22 Jun 2010 00:37:15 +0000
Subject: [issue8455] buildbot: test_urllib2_localnet failures (Connection
	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1277167035.04.0.28245527429.issue8455@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Apparently, the failure on OSX is due to the fact that urllib.proxy_bypass('localhost') returns True.  This makes the opener to bypass the ProxyHandler that is explicitly set up to use the correct server port:

    def setUp(self):
        ..
        proxy_url = "http://127.0.0.1:%d" % self.server.port
        handler = urllib2.ProxyHandler({"http" : proxy_url})
        self.proxy_digest_handler = urllib2.ProxyDigestAuthHandler()
        self.opener = urllib2.build_opener(handler, self.proxy_digest_handler)

instead, the opener skips to the default HTTPHandler which attempts to connect on port 80 with sad results.

Interestingly,

>>> urllib.proxy_bypass('127.0.0.1')
False

So the simplest fix is s/localhost/127.0.0.1/ as done in the attached patch (issue8455.diff).

----------
keywords: +patch
nosy: +belopolsky
Added file: http://bugs.python.org/file17737/issue8455.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8455>
_______________________________________

From report at bugs.python.org  Tue Jun 22 02:55:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 22 Jun 2010 00:55:14 +0000
Subject: [issue8455] buildbot: test_urllib2_localnet failures (Connection
	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1277168114.95.0.904309770122.issue8455@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

In fact, urllib.proxy_bypass() returns True for any simple host name (i.e. any string without '.' in it):

>>> proxy_bypass('xyz')
True
>>> proxy_bypass('')
True
>>> proxy_bypass('whatever')
True

I think the fix I am proposing makes sense regardless of platform because proxy_url is set up numerically:

proxy_url = "http://127.0.0.1:%d" % self.server.port

Maybe the above should be changed to

proxy_url = "%s:%d" % (self.URL, self.server.port)

once URL is changed to numerical form.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8455>
_______________________________________

From report at bugs.python.org  Tue Jun 22 03:04:35 2010
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 22 Jun 2010 01:04:35 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1277168675.16.0.512703841657.issue8621@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

This is on an Intel machine running OS X 10.5.8.  I downloaded and built 2.7rc2 from source with "./configure ; make".  I then ran the tests with "make test".  test_uuid fails with this output:


test test_uuid failed -- Traceback (most recent call last):
  File "/private/tmp/Python-2.7rc2/Lib/test/test_uuid.py", line 472, in testIssue8621
    self.assertNotEqual(parent_value, child_value)
AssertionError: '751ca85de22f4450b7f95dd3f82c7e5f' == '751ca85de22f4450b7f95dd3f82c7e5f'

However, when I run the test standalone with this command-line, it passes:

% ./python.exe -Wd -3 -E -tt ./Lib/test/regrtest.py -l test_uuid
test_uuid
1 test OK.

Not sure what's going on.

----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8621>
_______________________________________

From report at bugs.python.org  Tue Jun 22 03:17:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 22 Jun 2010 01:17:26 +0000
Subject: [issue8455] buildbot: test_urllib2_localnet failures (Connection
	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1277169446.56.0.0779401947285.issue8455@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8455>
_______________________________________

From report at bugs.python.org  Tue Jun 22 03:18:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 22 Jun 2010 01:18:37 +0000
Subject: [issue9052] 2.7rc2 fails test_urllib_localnet tests on OS X
In-Reply-To: <1277152478.13.0.221509017711.issue9052@psf.upfronthosting.co.za>
Message-ID: <1277169517.56.0.335699974159.issue9052@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9052>
_______________________________________

From report at bugs.python.org  Tue Jun 22 04:45:28 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 22 Jun 2010 02:45:28 +0000
Subject: [issue3439] create a numbits() method for int and long types
In-Reply-To: <1277157845.73.0.885521494438.issue3439@psf.upfronthosting.co.za>
Message-ID: <20100622024501.GA3390@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

> There is a small mistake in the docs:

Yes there was. Fixed in 82146.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Tue Jun 22 05:00:37 2010
From: report at bugs.python.org (pengyu.ut)
Date: Tue, 22 Jun 2010 03:00:37 +0000
Subject: [issue9056] Adding additional level of bookmarks and section numbers
	in python pdf documents.
In-Reply-To: <1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za>
Message-ID: <1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za>


New submission from pengyu.ut <pengyu.ut at gmail.com>:

Current pdf version of python documents don't have bookmarks for
sussubsection. For example, there is no bookmark for the following
section in python_2.6.5_reference.pdf. Also the bookmarks don't have
section numbers in them. I suggest to include the section numbers.
Could these features be added in future release of python document.

3.4.1 Basic customization

----------
assignee: docs at python
components: Documentation
messages: 108334
nosy: docs at python, pengyu.ut
priority: normal
severity: normal
status: open
title: Adding additional level of bookmarks and section numbers in python pdf documents.
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9056>
_______________________________________

From report at bugs.python.org  Tue Jun 22 05:26:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 22 Jun 2010 03:26:11 +0000
Subject: [issue9051] Cannot pickle timezone instances
In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za>
Message-ID: <1277177171.21.0.98728145637.issue9051@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
keywords: +easy, patch
nosy: +mark.dickinson
stage: unit test needed -> patch review
Added file: http://bugs.python.org/file17738/issue8455.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9051>
_______________________________________

From report at bugs.python.org  Tue Jun 22 05:26:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 22 Jun 2010 03:26:31 +0000
Subject: [issue9051] Cannot pickle timezone instances
In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za>
Message-ID: <1277177191.38.0.234421418057.issue9051@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17738/issue8455.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9051>
_______________________________________

From report at bugs.python.org  Tue Jun 22 05:26:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 22 Jun 2010 03:26:51 +0000
Subject: [issue9051] Cannot pickle timezone instances
In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za>
Message-ID: <1277177211.66.0.0348415008125.issue9051@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17739/issue9051.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9051>
_______________________________________

From report at bugs.python.org  Tue Jun 22 05:46:03 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 22 Jun 2010 03:46:03 +0000
Subject: [issue9018] os.path.normcase(None) does not raise an error on linux
	and should
In-Reply-To: <1276782016.7.0.192519527211.issue9018@psf.upfronthosting.co.za>
Message-ID: <1277178363.96.0.0819209610751.issue9018@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Nice patch. I like the use of new string formating. It can be applied.
 
BTW, do you think that TODO of s.lower() for MAC OS X should be addressed along with this. It might require some research as how much of a desirable behavior it would be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9018>
_______________________________________

From report at bugs.python.org  Tue Jun 22 06:23:12 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 22 Jun 2010 04:23:12 +0000
Subject: [issue8455] buildbot: test_urllib2_localnet failures (Connection
	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1277180592.95.0.106931161873.issue8455@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Replacing 'http://localhost' with 'http://127.0.0.1' for this test is fine. 

But, urllib.proxy_bypass returning for True for any string, is not correct. In the code, I see that Proxy Settings from Mac OSX system configuration is obtained by calling _get_proxy_settings().
proxy_settings = _get_proxy_settings()

The is the check to to see if proxy_settings['exclude_simple'] is set.
It seems that, it is set under conditions, which either might be a wrong behavior, or we should not rely on this property.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8455>
_______________________________________

From report at bugs.python.org  Tue Jun 22 07:11:18 2010
From: report at bugs.python.org (Andreas Hofmeister)
Date: Tue, 22 Jun 2010 05:11:18 +0000
Subject: [issue9049] UnboundLocalError in nested function
In-Reply-To: <1277149599.18.0.763779339646.issue9049@psf.upfronthosting.co.za>
Message-ID: <1277183478.15.0.173018945896.issue9049@psf.upfronthosting.co.za>


Andreas Hofmeister <andreas.hofmeister at yahoo.de> added the comment:

Thank you for your assistance. I apologize for not examining the reference manual closely. 
Is there any way to produce the desired behavior? I currently work around the local name binding like this:

def x():
     a = [False]
     def y():
         print a[0]
         a[0] = True
     return y

However, using a list here seems awkward.
Thank you for your attention.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9049>
_______________________________________

From report at bugs.python.org  Tue Jun 22 08:13:07 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 06:13:07 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4
In-Reply-To: <1277145356.65.0.792770780459.issue9046@psf.upfronthosting.co.za>
Message-ID: <1277187187.71.0.31039333295.issue9046@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'll fire up my 10.4 system to further investigate this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Tue Jun 22 08:20:43 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 06:20:43 +0000
Subject: [issue9045] 2.7rc1: 64-bit OSX installer is not built with 64-bit
	tkinter
In-Reply-To: <1277143341.0.0.74848452771.issue9045@psf.upfronthosting.co.za>
Message-ID: <1277187643.56.0.616546352082.issue9045@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

A patch to fix this issue would be appreciated. However, there is are two reasons why _tkinter is build for 32-bit architectures only:

1) Apple didn't ship a 64-bit Tk until OSX 10.6, and that is Tk 8.5 while earlier releases of the OS use Tk 8.4

2) Tk 8.5 on OSX 10.6 seems to break IDLE, see Issue6864

Issue8798 describes a way to get a build that works on OSX 10.5 or later and still supports 64-bit Tk (on OSX 10.6 or when the user has installed a local 64-bit copy of Tk 6.5). I don't have time to work in this myself, which is why the issue is not very detailed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9045>
_______________________________________

From report at bugs.python.org  Tue Jun 22 09:43:59 2010
From: report at bugs.python.org (Pauli Rikula)
Date: Tue, 22 Jun 2010 07:43:59 +0000
Subject: [issue9041] raised exception is misleading
In-Reply-To: <1277140034.13.0.259802323608.issue9041@psf.upfronthosting.co.za>
Message-ID: <AANLkTikNkj58_DL4tmDItpUrmScm_dtl-pX6LI1QgRLT@mail.gmail.com>


Pauli Rikula <pauli.rikula at gmail.com> added the comment:

I'm a newbie what it comes to Python's C-sources, so please do not
take me too seriously.
I fetched the sources 'svn checkout
http://svn.python.org/projects/python/branches/release26-maint '
studied the issue, and my best guess is that
Modules/_ctypes/cfield.c 's funktion d_set is called, when converting
something to ctypes.c_double

Please check, that this is what happens :)

If so, Objects/longobject.c's function double PyLong_AsDouble(PyObject
*vv) sets the overflow exception, but d_set overwrites it, like you
can see:

static PyObject *
d_set(void *ptr, PyObject *value, Py_ssize_t size)
{
    double x;

    x = PyFloat_AsDouble(value);
    if (x == -1 && PyErr_Occurred()) {
        PyErr_Format(PyExc_TypeError,
                     " float expected instead of %s instance",
                     value->ob_type->tp_name);
        return NULL;
    }
    memcpy(ptr, &x, sizeof(double));
    _RET(value);
}

Perhaps something like:
if (PyErr_ExceptionMatches(PyExc_OverflowError)){
	return NULL;
}

just after the line:
'f (x == -1 && PyErr_Occurred()) {'
could fix this?

 But like I said, I'm an newbie, this was actually my first  look into
Python/C API  and I have not tested this fix in any way whatsoever

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9041>
_______________________________________

From report at bugs.python.org  Tue Jun 22 10:08:59 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 08:08:59 +0000
Subject: [issue8455] buildbot: test_urllib2_localnet failures (Connection
	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1277194139.83.0.430982754789.issue8455@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The mac-related code in urllib is correct, it uses the SystemConfiguration framework on MacOSX to get the proxy settings. That said, the code in _scproxy is not entirly correct, it makes the wrong assumption w.r.t. the value of exclude_simple when the corresponding value is not in the settings retrieved from the SystemConfiguration framework.

The tests seem to make assumptions on how the proxy-detecting code functions, although I don't understand what's going on here (that is, I haven't waded through the test code and urllib to trace the code)


The patch "issue-8455-scproxy.patch" ensures that the tests pass, unless the user changed their proxy settings and selected the checkbox "Exclude simple hostnames" (System Preferernces -> Network -> First network adaptor -> Advanced... -> Proxies)

Please test if the patch solves the issue for you as well. 

NOTE: as I mention in the second paragraph the tests seem to make unwarrented assumptions about their environment. Further proof for this:
when you set "http_proxy=localhost:12345" in the environment on a Unixy system the tests will fail as well (although a different subset of the tests).

----------
Added file: http://bugs.python.org/file17740/issue8455-scproxy.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8455>
_______________________________________

From report at bugs.python.org  Tue Jun 22 10:09:02 2010
From: report at bugs.python.org (Tim Golden)
Date: Tue, 22 Jun 2010 08:09:02 +0000
Subject: [issue8869] execfile does not work with UNC paths
In-Reply-To: <1275403238.02.0.475988525563.issue8869@psf.upfronthosting.co.za>
Message-ID: <1277194142.15.0.807954436294.issue8869@psf.upfronthosting.co.za>


Changes by Tim Golden <mail at timgolden.me.uk>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8869>
_______________________________________

From report at bugs.python.org  Tue Jun 22 10:15:09 2010
From: report at bugs.python.org (Pauli Rikula)
Date: Tue, 22 Jun 2010 08:15:09 +0000
Subject: [issue9041] raised exception is misleading
In-Reply-To: <AANLkTikNkj58_DL4tmDItpUrmScm_dtl-pX6LI1QgRLT@mail.gmail.com>
Message-ID: <AANLkTilokj7tWstrPG4nuVZxJol8yBBrYSB1BCQ3zRXE@mail.gmail.com>


Pauli Rikula <pauli.rikula at gmail.com> added the comment:

If d_set makes the conversion, py3k does the same thing:

http://svn.python.org/projects/python/branches/py3k/Modules/_ctypes/cfield.c

It has a function d_set_sw, which might have same issues as well. The
same function can be found from 2.6 too:
http://svn.python.org/projects/python/branches/release26-maint/Modules/_ctypes/cfield.c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9041>
_______________________________________

From report at bugs.python.org  Tue Jun 22 10:18:10 2010
From: report at bugs.python.org (Tim Golden)
Date: Tue, 22 Jun 2010 08:18:10 +0000
Subject: [issue8440] test_heapq interfering with test_import on py3k
In-Reply-To: <4BCB057A.7030108@timgolden.me.uk>
Message-ID: <1277194690.34.0.596045634955.issue8440@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

Error no longer occurs

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8440>
_______________________________________

From report at bugs.python.org  Tue Jun 22 10:23:33 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Jun 2010 08:23:33 +0000
Subject: [issue8018] Backport 3.x nonlocal keyword to 2.7
In-Reply-To: <1267109193.82.0.369995733303.issue8018@psf.upfronthosting.co.za>
Message-ID: <1277195013.46.0.284911216777.issue8018@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is now out of date for 2.7.

----------
nosy: +mark.dickinson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8018>
_______________________________________

From report at bugs.python.org  Tue Jun 22 10:26:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Jun 2010 08:26:16 +0000
Subject: [issue9049] UnboundLocalError in nested function
In-Reply-To: <1277149599.18.0.763779339646.issue9049@psf.upfronthosting.co.za>
Message-ID: <1277195176.1.0.346147737741.issue9049@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Is there any way to produce the desired behavior?

Not directly, in Python 2.x.  (But there's the 'nonlocal' keyword in 3.x.)  There are various workarounds, but what's best depends on what you're doing.  The python-list mailing list is probably a better place to get answers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9049>
_______________________________________

From orsenthil at gmail.com  Mon Jun 21 20:38:27 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Tue, 22 Jun 2010 00:08:27 +0530
Subject: [issue9018] os.path.normcase(None) does not raise an error on
	linux and should
In-Reply-To: <1276977655.35.0.854993397938.issue9018@psf.upfronthosting.co.za>
References: <1276782016.7.0.192519527211.issue9018@psf.upfronthosting.co.za>
	<1276977655.35.0.854993397938.issue9018@psf.upfronthosting.co.za>
Message-ID: <20100621183827.GB10192@remy>

On Sat, Jun 19, 2010 at 08:00:55PM +0000, Shashwat Anand wrote:
> Why on Mac OS X, it should return s.lower() ?

That is is because some file systems on Mac OS X are case-sensitive.

> def normcase(s):
>     """Normalize case of pathname.  Has no effect under Posix"""
>     if s is None:  
>         raise AttributeError
>     return s

It should be a TypeError, not AttributeError. (Attached Test cases
checks it properly)

From orsenthil at gmail.com  Tue Jun 22 04:45:02 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Tue, 22 Jun 2010 08:15:02 +0530
Subject: [issue3439] create a numbits() method for int and long types
In-Reply-To: <1277157845.73.0.885521494438.issue3439@psf.upfronthosting.co.za>
References: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
	<1277157845.73.0.885521494438.issue3439@psf.upfronthosting.co.za>
Message-ID: <20100622024501.GA3390@remy>

> There is a small mistake in the docs:

Yes there was. Fixed in 82146.

From report at bugs.python.org  Tue Jun 22 11:19:10 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 09:19:10 +0000
Subject: [issue8446] buildbot: DeprecationWarning not raised for icglue
	(test_py3kwarn.TestStdlibRemovals)
In-Reply-To: <1271628757.81.0.455065561336.issue8446@psf.upfronthosting.co.za>
Message-ID: <1277198350.84.0.724491320685.issue8446@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This should be fixed with r82149.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8446>
_______________________________________

From report at bugs.python.org  Tue Jun 22 11:33:42 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 09:33:42 +0000
Subject: [issue8455] buildbot: test_urllib2_localnet failures (Connection
	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1277199222.45.0.40948593472.issue8455@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've applied my patch in r82150, which fixes the issue for me in the trunk.

I'll merge the patch into the other branches if this does indeed fix the buildbot issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8455>
_______________________________________

From report at bugs.python.org  Tue Jun 22 11:40:10 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 09:40:10 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1277199610.92.0.8804031316.issue8621@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Odd, unless someone already checked in a fix on the trunk. 

I currently have a clean test run on the trunk on OSX 10.6.4 (intel). I haven't checked this on my 10.5 VM yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8621>
_______________________________________

From report at bugs.python.org  Tue Jun 22 11:45:30 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 22 Jun 2010 09:45:30 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1277199930.56.0.861913687077.issue8621@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

It is disputed on http://openradar.appspot.com/radar?id=334401 that
this is an OS bug. If I understand correctly, the test program is
not guaranteed to work if threads are involved. See also:

http://webcache.googleusercontent.com/search?q=cache:hJo0u_Lc8wkJ:www.opengroup.org/onlinepubs/000095399/functions/fork.html+http://www.opengroup.org/onlinepubs/009695399/functions/fork.html&hl=en&strip=1


"A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. [THR] [Option Start]  Fork handlers may be established by means of the pthread_atfork() function in order to maintain application invariants across fork() calls."


This could explain why running the complete test suite fails but
running the individual test does not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8621>
_______________________________________

From report at bugs.python.org  Tue Jun 22 11:49:58 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 09:49:58 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1277200198.77.0.270314303894.issue8621@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Stefan: we already new that, see msg105018.

This issue was closed as fixed because the uuid module contains a workaround for this issue (by not using the broken C API on OSX 10.6).

It seems that OSX 10.5.8 and 10.4 is also affected by this issue. I'll test on 10.5, and if I can reproduce the issue there I'll adjust the workaround for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8621>
_______________________________________

From report at bugs.python.org  Tue Jun 22 11:56:17 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 22 Jun 2010 09:56:17 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1277200577.7.0.504725041109.issue8621@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Bill, could you try to add this to the tests and see if they
also fail when you run them standalone?


Index: Lib/test/test_uuid.py
===================================================================
--- Lib/test/test_uuid.py       (revision 82109)
+++ Lib/test/test_uuid.py       (working copy)
@@ -479,4 +479,7 @@
     test_support.run_unittest(TestUUID)
 
 if __name__ == '__main__':
+    import threading
+    t = threading.Thread(target=lambda: None)
+    t.start()
     test_main()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8621>
_______________________________________

From report at bugs.python.org  Tue Jun 22 11:59:43 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 09:59:43 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1277200783.58.0.676997879463.issue8621@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Bill, please test the patch below on a 10.5 system:


Index: Lib/uuid.py
===================================================================
--- Lib/uuid.py	(revision 82148)
+++ Lib/uuid.py	(working copy)
@@ -416,7 +416,7 @@
     import sys
     if sys.platform == 'darwin':
         import os
-        if int(os.uname()[2].split('.')[0]) >= 10:
+        if int(os.uname()[2].split('.')[0]) >= 9:
             _uuid_generate_random = _uuid_generate_time = None
 
     # On Windows prior to 2000, UuidCreate gives a UUID containing the


This extends the workaround for the bug in the system uuid libraries to OSX 10.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8621>
_______________________________________

From report at bugs.python.org  Tue Jun 22 12:09:05 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 10:09:05 +0000
Subject: [issue9033] cmd module tab misbehavior
In-Reply-To: <1276960216.2.0.17858038653.issue9033@psf.upfronthosting.co.za>
Message-ID: <1277201345.02.0.126618375176.issue9033@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

scott: 

* Which OSX version are you using?

* Which Python are you using?
  - What is the value of sys.prefix?
  - How did you install it?

* Does 'import readline' work?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9033>
_______________________________________

From report at bugs.python.org  Tue Jun 22 12:11:01 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 10:11:01 +0000
Subject: [issue8938] Mac OS  dialogs(Save As..., Load) translation
In-Reply-To: <1275996872.25.0.17428013193.issue8938@psf.upfronthosting.co.za>
Message-ID: <1277201461.71.0.15405798885.issue8938@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Pavel: does the problem also happen with newer versions of Python?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8938>
_______________________________________

From report at bugs.python.org  Tue Jun 22 12:16:29 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 22 Jun 2010 10:16:29 +0000
Subject: [issue9021] no copy.copy problem description
In-Reply-To: <1277147633.03.0.107110137762.issue9021@psf.upfronthosting.co.za>
Message-ID: <20100622101034.GA9303@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I am +0 on this change. The existing introduction is fine and the
discussion where shallow and deep copy is discussed is more important.

It is okay to assume that the reader is aware of the assignment
operation nature, i.e. it does not create a copy and you need this
module.  

The doc change suggested by Terry could be helpful in the tutorial
where a copy module is mentioned.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9021>
_______________________________________

From report at bugs.python.org  Tue Jun 22 12:17:53 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 10:17:53 +0000
Subject: [issue9047] Python 2.7rc2 includes -isysroot twice on each gcc
	command line
In-Reply-To: <1277145493.52.0.0439952052215.issue9047@psf.upfronthosting.co.za>
Message-ID: <1277201873.12.0.301986300904.issue9047@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Sigh.

-isysroot was added to CPPFLAGS because Python wouldn't build as a universal binary anymore due a fix for issue 1628484. (According to the SVN log for r80187).

I'll see what can be done to avoid adding -isysroot twice to the compiler flags.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9047>
_______________________________________

From report at bugs.python.org  Tue Jun 22 12:20:43 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 10:20:43 +0000
Subject: [issue7192] webbrowser.get("firefox") does not work on Mac with
	installed Firefox
In-Reply-To: <1256306857.19.0.981560840081.issue7192@psf.upfronthosting.co.za>
Message-ID: <1277202043.07.0.829421353921.issue7192@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

R. David Murray: the issue you refer to isn't the one you intend to link to, it is related to proxy settings and doesn't contain a patch related to firefox.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7192>
_______________________________________

From report at bugs.python.org  Tue Jun 22 12:29:13 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 10:29:13 +0000
Subject: [issue7192] webbrowser.get("firefox") does not work on Mac with
	installed Firefox
In-Reply-To: <1256306857.19.0.981560840081.issue7192@psf.upfronthosting.co.za>
Message-ID: <1277202553.52.0.918339685698.issue7192@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

BTW. The firebox-bin binary in Firefox.app/Contents/MacOS does not support the command-line arguments that Firefox on Linux supports. That is, the following command does not work:

/Applications/Firefox.app/Contents/MacOS/firefox-bin -remote 'openURL("http://www.apple.com/",new-tab)'

This will start the firefox binary, but that complains that firefox is already running (because I already had FF open)

This means that it won't be possible to have one Firefox support class that works the same on all platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7192>
_______________________________________

From report at bugs.python.org  Tue Jun 22 12:32:05 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 10:32:05 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1277202725.6.0.565635422986.issue3362@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh -None

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Tue Jun 22 12:40:22 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 10:40:22 +0000
Subject: [issue9048] no OS X buildbots in the stable list
In-Reply-To: <1277148342.98.0.18086046529.issue9048@psf.upfronthosting.co.za>
Message-ID: <1277203222.65.0.121825356892.issue9048@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Then why bother providing binaries?

I'm trying to keep the OSX port in good shape, but at times have to hunt down issues that were introduced by other bugfixes.

A problem with adding OSX to the list of stable buildbots is IMHO that there seem to be very few core developers that care about OSX beyond it being some odd flavor of unix.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9048>
_______________________________________

From report at bugs.python.org  Tue Jun 22 12:45:24 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Tue, 22 Jun 2010 10:45:24 +0000
Subject: [issue7192] webbrowser.get("firefox") does not work on Mac with
	installed Firefox
In-Reply-To: <1256306857.19.0.981560840081.issue7192@psf.upfronthosting.co.za>
Message-ID: <1277203524.49.0.758356515086.issue7192@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

16:05:57 l0nwlf-MBP:/Applications/Firefox.app/Contents/MacOS$ ./firefox-bin 'http://www.google.com'
says firefox is already running as ff is open.
After we quit ff,
16:09:05 l0nwlf-MBP:/Applications/Firefox.app/Contents/MacOS$ ./firefox-bin -remote 'http://www.google.com'
Nothing happens.
16:09:14 l0nwlf-MBP:/Applications/Firefox.app/Contents/MacOS$ ./firefox-bin  'http://www.google.com'
Opened firefox with url(google homepage) as mentioned.

Also,
>>> import webbrowser
>>> url = 'http://www.google.com'
>>> c = webbrowser.get('safari')
>>> c.open(url)
True
Opens two instances of safari, one with home-page and another with url mentioned. Initially safari was not running and firefox is my default browser. Incase safari is running it opens only one instance with url(google homepage) opened.

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7192>
_______________________________________

From report at bugs.python.org  Tue Jun 22 12:46:45 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 22 Jun 2010 10:46:45 +0000
Subject: [issue9035] os.path.ismount on windows doesn't support windows
	mount	points
In-Reply-To: <4C1DE5A5.3000801@timgolden.me.uk>
Message-ID: <20100622103830.GB9303@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I see that ismount like function on windows is provide by the various
Win32 extensions. 

If Windows supported is added to ismount function itself, then it might be
a good idea to have attributes or list_attributes function as well.

But for posix, how will it be different from details provided by stat?
Would not it add redundancy?

Or would it be better to provide file attributes as part of stat
itself (if some are missing in Windows).

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9035>
_______________________________________

From report at bugs.python.org  Tue Jun 22 12:56:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Jun 2010 10:56:14 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1277204174.83.0.0410411772157.issue8912@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

1) Okay, so I?ll refactor some code in patchcheck into a grep-like function to reduce duplication and support adding new checks.

2) I?ll add more useful report. Perhaps I?ll ask first on python-dev to see if I should add a command-line option or just improve it. Also, whether I should use logging or just output file names and lines.

3) Well, if your editor strips trailing spaces and adds final newlines, you won?t ever see make patchcheck complain, will you? Since the report will be helpful only to people with less smart editors, I think I?ll go with replacing instead of just reporting. Tabs will not be replaced, though, just reported.

4) See attached patch for py3k (no idea if this will go into 2.7 too).

----------
Added file: http://bugs.python.org/file17741/refactor.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 22 12:56:14 2010
From: report at bugs.python.org (Tim Golden)
Date: Tue, 22 Jun 2010 10:56:14 +0000
Subject: [issue9035] os.path.ismount on windows doesn't support windows
	mount	points
In-Reply-To: <20100622103830.GB9303@remy>
Message-ID: <4C2096C8.5060708@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

I think we're saying the same thing :)

The simplest thing to do here is to create a win_ismount function
in posixmodule.c which does the attributes / reparse tag dance and
returns True/False and use that wherever it's needed to support this
concept under Windows. The current solution is correct for a subset
of cases. Arguably a bug, although I doubt I'd get that past the
release manager!

The wider issue of exposing GetFileAttributesW, eg under one of the
unused stat fields, should be explored elsewhere.

On 22/06/2010 11:46, Senthil Kumaran wrote:
>
> Senthil Kumaran<orsenthil at gmail.com>  added the comment:
>
> I see that ismount like function on windows is provide by the various
> Win32 extensions.
>
> If Windows supported is added to ismount function itself, then it might be
> a good idea to have attributes or list_attributes function as well.
>
> But for posix, how will it be different from details provided by stat?
> Would not it add redundancy?
>
> Or would it be better to provide file attributes as part of stat
> itself (if some are missing in Windows).
>
> ----------
> nosy: +orsenthil
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue9035>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/mail%40timgolden.me.uk

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9035>
_______________________________________

From report at bugs.python.org  Tue Jun 22 12:56:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Jun 2010 10:56:29 +0000
Subject: [issue8999] Add Mercurial support to patchcheck
In-Reply-To: <1276593572.4.0.720668123002.issue8999@psf.upfronthosting.co.za>
Message-ID: <1277204189.05.0.915922292968.issue8999@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

In the absence of formal testing, a few comments on my patch to help
reviewers.

1) If the code is both an svn and hg checkout, hg wins, since it?s not unheard of to use hg on top of svn, whereas the contrary does not make sense to me.

2) The hg status command does not need post-processing like the svn one, since hg status --added --modified will already filter the output, and --no-status means ?don?t print A or M at the start of each line?.

3) I changed a list comp for a genexp, and used startswith instead of getitem+contains+eq; does not change behavior.

4) I suppressed the unneeded shell=True argument to subprocess.Popen (and made the command string into a list); does not change behavior since there were no globbing or path expansion of any kind.

Testing is easy: Apply the patch, add bad indentation in a Python file, run make patchcheck (./python Tools/scripts/patchcheck.py on OSes without make), profit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8999>
_______________________________________

From report at bugs.python.org  Tue Jun 22 12:57:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Jun 2010 10:57:40 +0000
Subject: [issue8999] Add Mercurial support to patchcheck
In-Reply-To: <1276593572.4.0.720668123002.issue8999@psf.upfronthosting.co.za>
Message-ID: <1277204260.19.0.458363877784.issue8999@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8999>
_______________________________________

From report at bugs.python.org  Tue Jun 22 12:58:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Jun 2010 10:58:31 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1277204311.89.0.304200981146.issue8912@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +needs review
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 22 13:00:16 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 11:00:16 +0000
Subject: [issue7192] webbrowser.get("firefox") does not work on Mac with
	installed Firefox
In-Reply-To: <1256306857.19.0.981560840081.issue7192@psf.upfronthosting.co.za>
Message-ID: <1277204416.98.0.215721713293.issue7192@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm closing this issue:

1) webbrowser.get("firefox") currently works

2) firefox on OSX doesn't provide hooks to open tabs instead of windows (neither through the command line nor though AppleScript) which means that the 'new' and 'autoraise' options of webbrowser.open cannot be supported due to lack of support in FF itself.

----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7192>
_______________________________________

From report at bugs.python.org  Tue Jun 22 13:05:15 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Tue, 22 Jun 2010 11:05:15 +0000
Subject: [issue7192] webbrowser.get("firefox") does not work on Mac with
	installed Firefox
In-Reply-To: <1256306857.19.0.981560840081.issue7192@psf.upfronthosting.co.za>
Message-ID: <1277204715.68.0.257334146523.issue7192@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

I searched for proxy+firefox on roundup and the only two issue I got was issue 8238 and issue 1160328. None of them seems related to webbrowser.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7192>
_______________________________________

From report at bugs.python.org  Tue Jun 22 13:21:19 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 22 Jun 2010 11:21:19 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1277200198.77.0.270314303894.issue8621@psf.upfronthosting.co.za>
Message-ID: <20100622112107.GA32216@yoda.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Ronald Oussoren <report at bugs.python.org> wrote:
> Stefan: we already new that, see msg105018.
> 
> This issue was closed as fixed because the uuid module contains a workaround for this issue (by not using the broken C API on OSX 10.6).

Ok, my comment was partly meant to give an explanation why the test suite failed
but the individual tests did not.

If uuid_generate_random() is specified as async-signal-safe, then yes, the C API
would be broken on OSX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8621>
_______________________________________

From report at bugs.python.org  Tue Jun 22 13:21:19 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Jun 2010 11:21:19 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1277205679.55.0.161164430556.issue8912@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I think I?ll go with replacing instead of just reporting.

How about a --report-only (insert better name here) command line option to patchcheck, then?

My editor doesn't delete trailing whitespace *automatically*, but it's trivial to remove trailing whitespace from a file if you know it's there (M-x delete-trailing-whitespace, I believe);  some people (like me) might prefer to make all changes within the editor rather than having an external tool do it for them.  This is especially true if you've got the editor open for the relevant file at the time, since you can end up with two different conflicting versions of the file---one in the editor and one on disk;  saving in the editor can undo the changes that patchcheck made on disk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 22 13:23:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Jun 2010 11:23:46 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1277205826.64.0.675917460342.issue8912@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Agreed. reindent.py has a dry-run mode too, so adding such a global flag and making it the default is okay with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Tue Jun 22 13:25:38 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 22 Jun 2010 11:25:38 +0000
Subject: [issue9056] Adding additional level of bookmarks and section numbers
	in python pdf documents.
In-Reply-To: <1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za>
Message-ID: <20100622112524.GA12768@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

You mean "Table of Contents"? The index at the end serves as a
bookmark, right?  Also, Table of Contents might add up couple of more
pages to traverse.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9056>
_______________________________________

From orsenthil at gmail.com  Tue Jun 22 12:10:34 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Tue, 22 Jun 2010 15:40:34 +0530
Subject: [issue9021] no copy.copy problem description
In-Reply-To: <1277147633.03.0.107110137762.issue9021@psf.upfronthosting.co.za>
References: <1276816713.34.0.416523004663.issue9021@psf.upfronthosting.co.za>
	<1277147633.03.0.107110137762.issue9021@psf.upfronthosting.co.za>
Message-ID: <20100622101034.GA9303@remy>

I am +0 on this change. The existing introduction is fine and the
discussion where shallow and deep copy is discussed is more important.

It is okay to assume that the reader is aware of the assignment
operation nature, i.e. it does not create a copy and you need this
module.  

The doc change suggested by Terry could be helpful in the tutorial
where a copy module is mentioned.

From orsenthil at gmail.com  Tue Jun 22 12:38:30 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Tue, 22 Jun 2010 16:08:30 +0530
Subject: [issue9035] os.path.ismount on windows doesn't support windows
	mount	points
In-Reply-To: <4C1DE5A5.3000801@timgolden.me.uk>
References: <1277025111.41.0.220519660485.issue9035@psf.upfronthosting.co.za>
	<4C1DE5A5.3000801@timgolden.me.uk>
Message-ID: <20100622103830.GB9303@remy>

I see that ismount like function on windows is provide by the various
Win32 extensions. 

If Windows supported is added to ismount function itself, then it might be
a good idea to have attributes or list_attributes function as well.

But for posix, how will it be different from details provided by stat?
Would not it add redundancy?

Or would it be better to provide file attributes as part of stat
itself (if some are missing in Windows).

From orsenthil at gmail.com  Tue Jun 22 13:25:24 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Tue, 22 Jun 2010 16:55:24 +0530
Subject: [issue9056] Adding additional level of bookmarks and section
	numbers in python pdf documents.
In-Reply-To: <1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za>
References: <1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za>
	<1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za>
Message-ID: <20100622112524.GA12768@remy>

You mean "Table of Contents"? The index at the end serves as a
bookmark, right?  Also, Table of Contents might add up couple of more
pages to traverse.

From report at bugs.python.org  Tue Jun 22 14:43:53 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 22 Jun 2010 12:43:53 +0000
Subject: [issue8988] import + coding = failure (3.1.2/win32)
In-Reply-To: <1276426235.15.0.873898512927.issue8988@psf.upfronthosting.co.za>
Message-ID: <1277210633.31.0.891059085362.issue8988@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> now tell me how the hell can file system encoding be related 
> to file content encoding?!

Why do you say so? I can reproduce your issue, but changing the first line of a.py:
# coding: cp1252
to:
# coding: utf-8
did not change anything.

In the meantime, you should refrain from creating directories with characters not representable in the terminal window.

@haypo: The problem still exists with py3k at r82150.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8988>
_______________________________________

From report at bugs.python.org  Tue Jun 22 15:22:08 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 13:22:08 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4
In-Reply-To: <1277145356.65.0.792770780459.issue9046@psf.upfronthosting.co.za>
Message-ID: <1277212928.48.0.901553979994.issue9046@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Marc-Andre: what version of Xcode do you use? (the version in the About menu of Xcode.app).

I'm getting clean builds with '--enable-universalsdk' on OSX 10.4.11 (PPC) with Xcode 2.5 (the last Xcode for OSX 10.4). That is, all extension build, except for the ones grouped with '_bsddb' in your initial message (and that's expected).  Furthermore all tests passed.

I had one oddity in the tests: make test prints "Warning -- sys.path was modified by test_site". I don't get this warning on OSX 10.6.

BTW. universal builds work fine on OSX 10.6, that's how I do most of my development.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Tue Jun 22 15:29:12 2010
From: report at bugs.python.org (Malcolm Box)
Date: Tue, 22 Jun 2010 13:29:12 +0000
Subject: [issue1349106] email.Generators does not separates headers with "\r\n"
Message-ID: <1277213352.61.0.108648954226.issue1349106@psf.upfronthosting.co.za>


Malcolm Box <malcolm.box at gmail.com> added the comment:

Echoing the comment of Thomas Viehmann, the current behaviour makes it impossible to use this library to generate a correct multipart/mixed message with 7_or_8_bit encoding on Unix.

The MIME standard specifies that headers are to be CRLF terminated - this is independent of any lower-level transport encoding.  

Binary bodies are simply octet sequences - so may contain \n or \r characters.

The correct MIME encoding would have the headers terminated with CRLF, and the bodies as raw byte sequences.  However on Unix, since the headers are generated with \n not CRLF, you can't even post-process this (e.g. message.as_string().replace('\n', '\r\n') as that will screw up the binary body data.

The current behaviour is basically wrong and should be fixed.

----------
nosy: +Malcolm.Box

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1349106>
_______________________________________

From report at bugs.python.org  Tue Jun 22 15:41:16 2010
From: report at bugs.python.org (pengyu.ut)
Date: Tue, 22 Jun 2010 13:41:16 +0000
Subject: [issue9056] Adding additional level of bookmarks and section numbers
	in python pdf documents.
In-Reply-To: <20100622112524.GA12768@remy>
Message-ID: <AANLkTikoRUWqKeKKk6YOGNge1vFnCMLk-cpicE3kykBq@mail.gmail.com>


pengyu.ut <pengyu.ut at gmail.com> added the comment:

On Tue, Jun 22, 2010 at 6:25 AM, Senthil Kumaran <report at bugs.python.org> wrote:
>
> Senthil Kumaran <orsenthil at gmail.com> added the comment:
>
> You mean "Table of Contents"? The index at the end serves as a
> bookmark, right? ?Also, Table of Contents might add up couple of more
> pages to traverse.

I don't need subsubsections to be in the table of content. But I think
it is making sense to add them in the bookmarks, as the bookmarks can
be folded even if there are many bookmarks for subsubsections. I'm not
refereeing to index.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9056>
_______________________________________

From report at bugs.python.org  Tue Jun 22 15:46:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Jun 2010 13:46:18 +0000
Subject: [issue8252] add a metadata section in setup.cfg
In-Reply-To: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>
Message-ID: <1277214378.56.0.419798686887.issue8252@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m starting on this now. Monitor http://bitbucket.org/Merwok/distutils2-killsetup for updates.

----------
keywords: +gsoc
resolution:  -> accepted
stage:  -> needs patch
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8252>
_______________________________________

From report at bugs.python.org  Tue Jun 22 15:47:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Jun 2010 13:47:31 +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: <1277214451.03.0.678913608533.issue8253@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m doing this after #8252. Monitor that bug and http://bitbucket.org/Merwok/distutils2-killsetup for updates.

----------
dependencies: +add a metadata section in setup.cfg
keywords: +gsoc
resolution:  -> accepted
stage:  -> needs patch
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8253>
_______________________________________

From report at bugs.python.org  Tue Jun 22 15:47:47 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Tue, 22 Jun 2010 13:47:47 +0000
Subject: [issue8252] add a metadata section in setup.cfg
In-Reply-To: <1277214378.56.0.419798686887.issue8252@psf.upfronthosting.co.za>
Message-ID: <AANLkTil3B4sLKTdA2kAeL2dIOpko7IHgdAZODayEpC29@mail.gmail.com>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Is "+gsoc" a keyword too ? :O

On Tue, Jun 22, 2010 at 7:16 PM, ??ric Araujo <report at bugs.python.org> wrote:

>
> ??ric Araujo <merwok at netwok.org> added the comment:
>
> I???m starting on this now. Monitor
> http://bitbucket.org/Merwok/distutils2-killsetup for updates.
>
> ----------
> keywords: +gsoc
> resolution:  -> accepted
> stage:  -> needs patch
> versions:  -Python 3.3
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8252>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file17742/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8252>
_______________________________________
-------------- next part --------------
Is &quot;+gsoc&quot; a keyword too ? :O<br><br><div class="gmail_quote">On Tue, Jun 22, 2010 at 7:16 PM, ??ric Araujo <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>
??ric Araujo &lt;<a href="mailto:merwok at netwok.org">merwok at netwok.org</a>&gt; added the comment:<br>
<br>
I???m starting on this now. Monitor <a href="http://bitbucket.org/Merwok/distutils2-killsetup" target="_blank">http://bitbucket.org/Merwok/distutils2-killsetup</a> for updates.<br>
<br>
----------<br>
keywords: +gsoc<br>
resolution: ??-&gt; accepted<br>
stage: ??-&gt; needs patch<br>
versions: ??-Python 3.3<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/issue8252" target="_blank">http://bugs.python.org/issue8252</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Tue Jun 22 15:48:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Jun 2010 13:48:52 +0000
Subject: [issue8252] add a metadata section in setup.cfg
In-Reply-To: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>
Message-ID: <1277214532.43.0.025935358394.issue8252@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file17742/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8252>
_______________________________________

From report at bugs.python.org  Tue Jun 22 15:51:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Jun 2010 13:51:02 +0000
Subject: [issue8252] add a metadata section in setup.cfg
In-Reply-To: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>
Message-ID: <1277214662.63.0.384906170776.issue8252@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

?keywords: +gsoc? means that the ?gsoc? keyword has been added, yes. Tarek asked for this keyword to track things.

(P.S. Please remove unnecessary quotes from your replies, it?s clutter,  and don?t send HTML email to the tracker, that creates a useless unnamed file. Thanks :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8252>
_______________________________________

From report at bugs.python.org  Tue Jun 22 16:00:01 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 14:00:01 +0000
Subject: [issue9033] cmd module tab misbehavior
In-Reply-To: <1276960216.2.0.17858038653.issue9033@psf.upfronthosting.co.za>
Message-ID: <1277215201.27.0.625257798912.issue9033@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Reaction from scot w.r.t. my questions:


os x 10.5.8

python 2.5.1

/System/Library/Frameworks/Python.framework/Versions/2.5

came default with system

i'm going to try activestate python 2.6 and see if that solves the problem.

import readline does work

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9033>
_______________________________________

From report at bugs.python.org  Tue Jun 22 16:06:09 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 14:06:09 +0000
Subject: [issue9033] cmd module tab misbehavior
In-Reply-To: <1276960216.2.0.17858038653.issue9033@psf.upfronthosting.co.za>
Message-ID: <1277215569.64.0.587178381972.issue9033@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Some notes: The system python on OSX 10.5 and 10.6 is linked to libedit, not GNU readline, and doesn't seem to contain patches that convert stdlib usage of readline APIs to the correct way to bind keystrokes to action with libedit.

This results in failure to use libedit at all.

AFAIK this also affects the generic stdlib when linking libedit, which is supported in 2.6.5, 2.7 and 3.2. Therefore adding more versions.

----------
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9033>
_______________________________________

From report at bugs.python.org  Tue Jun 22 16:11:46 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 14:11:46 +0000
Subject: [issue9033] cmd module tab misbehavior
In-Reply-To: <1276960216.2.0.17858038653.issue9033@psf.upfronthosting.co.za>
Message-ID: <1277215906.81.0.811807858499.issue9033@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This (untested) patch should fix the issue for the cmd module:


+++ Lib/cmd.py	(working copy)
@@ -112,7 +112,18 @@
                 import readline
                 self.old_completer = readline.get_completer()
                 readline.set_completer(self.complete)
-                readline.parse_and_bind(self.completekey+": complete")
+
+                if 'libedit' in readline.__doc__:
+                    # readline linked to BSD libedit
+                    if self.completekey == 'tab':
+                        key = '^I'
+                    else:
+                        key = self.completekey
+                    readline.parse_and_bind("bind %s rl_complete"%(key,))
+
+                else:
+                    # readline linked to the real readline
+                    readline.parse_and_bind(self.completekey+": complete")
             except ImportError:
                 pass
         try:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9033>
_______________________________________

From report at bugs.python.org  Tue Jun 22 16:17:20 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Tue, 22 Jun 2010 14:17:20 +0000
Subject: [issue9056] Adding additional level of bookmarks and section numbers
	in python pdf documents.
In-Reply-To: <1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za>
Message-ID: <AANLkTimph8SSXEJ_Zyn2Lof21Oym8dBDQ6JE5FKhcjhu@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

On Mon, Jun 21, 2010 at 11:00 PM, pengyu.ut <report at bugs.python.org> wrote:
> Current pdf version of python documents don't have bookmarks for
> sussubsection. For example, there is no bookmark for the following
> section in python_2.6.5_reference.pdf.

This would be nice to have.

> Also the bookmarks don't have
> section numbers in them. I suggest to include the section numbers.

Hmm.  I'm not a huge fan of section numbers, but so long as we use them,
there's some rationale to include them in the PDF bookmarks.  So I guess
that's up to whoever creates the patch.

  -Fred

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9056>
_______________________________________

From report at bugs.python.org  Tue Jun 22 16:17:40 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 22 Jun 2010 14:17:40 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4
In-Reply-To: <1277212928.48.0.901553979994.issue9046@psf.upfronthosting.co.za>
Message-ID: <4C20C602.7020108@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ronald Oussoren wrote:
> 
> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
> 
> Marc-Andre: what version of Xcode do you use? (the version in the About menu of Xcode.app).

We have Xcode 2.5 and all updates on the machine. Python 2.6 and
older versions compile just fine.

The changes you added for the SDK builds in Python 2.7 made the problem
appear.

What I don't understand is why you are redirecting files under
/usr to the SDK virtual root dir. We install all the local
builds under /usr/local/ and as result, the build itself
also happens under a /usr path.

The function definition appears to be a bit coarse in this respect:

def is_macosx_sdk_path(path):
    """
    Returns True if 'path' can be located in an OSX SDK
    """
    return path.startswith('/usr/') or path.startswith('/System/')

I believe that this function should really only return True if
the path in question does exists in the SDK virtual root.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Tue Jun 22 16:27:16 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 22 Jun 2010 14:27:16 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>
Message-ID: <1277216836.46.0.599833830018.issue9020@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Re: EOF checking in Py_ISXXX() for consistency with C functions.

After reflecting on this a bit I think it's ultimately not a good
idea. While it is possible to do the EOF check, the macros would
then take either an int in [EOF, 0-UCHAR_MAX] or a signed/unsigned
char. This would be another inconsistency with the C functions,
which are not supposed to take a signed char.


I checked every usage of Py_IS* in the tree and this is an isolated
case. So I think it's better to do the check explicitly and add a
comment to the Py_IS* macros.


Does the patch look good?

----------
Added file: http://bugs.python.org/file17743/check_eof.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Tue Jun 22 16:31:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Jun 2010 14:31:07 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1277217067.49.0.738458446193.issue8254@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have a working configure command at http://bitbucket.org/Merwok/distutils2-configure which works. (Read my short reports on https://wokslog.wordpress.com/ for more details.) It?s not completely finished, though:

1) I import build and install to get their user_options, to avoid duplicating these lines. Is that bad?

2) Test coverage is not exhaustive. This will be done incrementally.

3) I tried directly using Distribution and configure objects in the tests, but couldn?t get them to work; I temporarily settled for running Python (sys.executable) in a subprocess. I?m looking for help to change that.

4) As it is now, the configure command just records options without checking for conflicts (e.g. using both ?prefix and ?user for install). While not in the original description of the task, I think that it should be added. Prior art like 4Suite?s config command or a prototype for configure done by Tarek that I discovered only today support this idea. Is that okay? I?ll have to avoid code duplication between configure, build and install.

----------
resolution:  -> accepted
stage:  -> patch review
type:  -> feature request
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8254>
_______________________________________

From report at bugs.python.org  Tue Jun 22 16:32:14 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 14:32:14 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4
In-Reply-To: <1277145356.65.0.792770780459.issue9046@psf.upfronthosting.co.za>
Message-ID: <1277217134.08.0.516349664803.issue9046@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

What I don't quite understand is why the build fails for you but passes for me. What configure flags did you use?

This version should fare better:

def is_macosx_sdk_path(path):
    """
    Returns True if 'path' can be located in an OSX SDK
    """
    return (path.startswith('/usr/') and not path.startswith('/usr/local')) or path.startswith('/System/')

This explicitly tests for paths that must be in the SDK:

* Anything in /System is owned by the system, and should be fetched
  through the SDK
* Likewise for anything in /usr that isn't in /usr/local
 
IMHO anyone that installs additional libraries in /usr/lib, or /System/Libraries/Frameworks is confused at best, and we shouldn't even try to support that.


The repository contains an simpler (but in hindsight too simple) version because ${SDKROOT}/usr/local/lib is a symlink to the real /usr/local/lib. That works fine when looking for libraries, but not when looking for other files (such as headers).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Tue Jun 22 16:37:35 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 22 Jun 2010 14:37:35 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1277216836.46.0.599833830018.issue9020@psf.upfronthosting.co.za>
Message-ID: <4C20CAD0.10903@trueblade.com>


Eric Smith <eric at trueblade.com> added the comment:

I agree with this approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Tue Jun 22 16:42:50 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 22 Jun 2010 14:42:50 +0000
Subject: [issue8999] Add Mercurial support to patchcheck
In-Reply-To: <1276593572.4.0.720668123002.issue8999@psf.upfronthosting.co.za>
Message-ID: <1277217770.42.0.0290239777309.issue8999@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

A small suggestion: rather than having bool hg which means Mercurial if true and SVN if false, consider a string valued vc variable with 'svn' for  SVN and 'hg' for Mercurial.  This way it will be straightforward to add support for other VC systems in the future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8999>
_______________________________________

From report at bugs.python.org  Tue Jun 22 16:53:31 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Tue, 22 Jun 2010 14:53:31 +0000
Subject: [issue1349106] email.Generators does not separates headers with "\r\n"
Message-ID: <1277218411.75.0.120333772986.issue1349106@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1349106>
_______________________________________

From report at bugs.python.org  Tue Jun 22 16:56:43 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Tue, 22 Jun 2010 14:56:43 +0000
Subject: [issue8252] add a metadata section in setup.cfg
In-Reply-To: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>
Message-ID: <1277218603.38.0.960572764553.issue8252@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

merwok: Pont noted. I replied it via Gmail, was unaware of the fact that it adds an unnamed file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8252>
_______________________________________

From report at bugs.python.org  Tue Jun 22 16:58:06 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Tue, 22 Jun 2010 14:58:06 +0000
Subject: [issue9057] Needs a home page
In-Reply-To: <1277218686.54.0.776970165473.issue9057@psf.upfronthosting.co.za>
Message-ID: <1277218686.54.0.776970165473.issue9057@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

This project needs a home page. I want to link to it from Ryppl docs, but anyone following a link to, e.g. the bitbucket wiki would think this project was weak at best.

----------
assignee: tarek
components: Distutils2
messages: 108390
nosy: dabrahams, tarek
priority: normal
severity: normal
status: open
title: Needs a home page

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9057>
_______________________________________

From report at bugs.python.org  Tue Jun 22 17:00:15 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Tue, 22 Jun 2010 15:00:15 +0000
Subject: [issue1100562] deepcopying listlike and dictlike objects
Message-ID: <1277218815.49.0.0269954955234.issue1100562@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

Ported to Py3k.

----------
versions: +Python 3.2 -Python 2.6, Python 2.7
Added file: http://bugs.python.org/file17744/issue1100562_py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100562>
_______________________________________

From report at bugs.python.org  Tue Jun 22 17:08:31 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Tue, 22 Jun 2010 15:08:31 +0000
Subject: [issue1100562] deepcopying listlike and dictlike objects
Message-ID: <1277219311.35.0.00372790178488.issue1100562@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Removed file: http://bugs.python.org/file17744/issue1100562_py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100562>
_______________________________________

From report at bugs.python.org  Tue Jun 22 17:09:29 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Tue, 22 Jun 2010 15:09:29 +0000
Subject: [issue1100562] deepcopying listlike and dictlike objects
Message-ID: <1277219369.07.0.888647061382.issue1100562@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Added file: http://bugs.python.org/file17745/issue1100562_py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100562>
_______________________________________

From report at bugs.python.org  Tue Jun 22 17:15:28 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Tue, 22 Jun 2010 15:15:28 +0000
Subject: [issue9033] cmd module tab misbehavior
In-Reply-To: <1276960216.2.0.17858038653.issue9033@psf.upfronthosting.co.za>
Message-ID: <1277219728.17.0.440270819159.issue9033@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Tested the patch and it works for trunk and python3.2 alpha.
Without adding SDK flag with configure readline module failed to build.

Python build finished, but the necessary bits to build these modules were not found:
_gdbm              ossaudiodev        readline        
spwd

However for cmd module, tab completion and history(up|down arrow) worked fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9033>
_______________________________________

From report at bugs.python.org  Tue Jun 22 17:16:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 22 Jun 2010 15:16:38 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1277219798.11.0.368345027552.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Ronald,

Please see my python-dev post in "red buildbots on 2.7" thread: 

http://mail.python.org/pipermail/python-dev/2010-June/100873.html

I argue that we should apply a fix along the lines of no-darwin-ext.diff while waiting for Apple to fix their bugs and support more than 16 groups in getgroups properly.

Your latest patch, while prevents getgroups from raising an exception, does not change the fact that getgroups return wrong values if group membership changes within the process.

Note that I propose to undefine _DARWIN_C_SOURCE for posixmodule.c only.  I think that is the right thing to do because defining _DARWIN_C_SOURCE is for invoking non-POSIX behavior.  If you still thing there may be other functions in posixmodule.c that require _DARWIN_C_SOURCE, we can probably find a way to change only getgroups, but I cannot figure out how to do it without adding extra source files.

For your reference, here is how getgroups is declared in unistd.h:


#if defined(_DARWIN_UNLIMITED_GETGROUPS) || defined(_DARWIN_C_SOURCE)
int      getgroups(int, gid_t []) __DARWIN_EXTSN(getgroups);
#else /* !_DARWIN_UNLIMITED_GETGROUPS && !_DARWIN_C_SOURCE */
int      getgroups(int, gid_t []);
#endif /* _DARWIN_UNLIMITED_GETGROUPS || _DARWIN_C_SOURCE */

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Jun 22 17:18:04 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Jun 2010 15:18:04 +0000
Subject: [issue1749662] New byte packing format for the struct module
Message-ID: <1277219884.92.0.855351397266.issue1749662@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1749662>
_______________________________________

From report at bugs.python.org  Tue Jun 22 17:42:00 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 22 Jun 2010 15:42:00 +0000
Subject: [issue9055] test_issue_8959_b fails when run from a service
In-Reply-To: <1277159969.39.0.181729867437.issue9055@psf.upfronthosting.co.za>
Message-ID: <1277221320.11.0.989664694962.issue9055@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

To test windows callbacks, I suggest to use EnumResourceTypes() instead, which is more likely to work in any condition:

def test():
    from ctypes.wintypes import BOOL, HMODULE, LONG, LPARAM
    import ctypes
    EnumResourceTypes = ctypes.windll.kernel32.EnumResourceTypesA
    EnumResTypeProc = ctypes.WINFUNCTYPE(
        BOOL, HMODULE, LONG, LPARAM)

    resource_types = []
    def callback(hModule, typeid, lParam):
        resource_types.append(typeid)
        return True # keep enumerating

    hModule = None   # Main executable
    RT_MANIFEST = 24 # from winuser.h
    EnumResourceTypes(hModule, EnumResTypeProc(callback), None)

    assert RT_MANIFEST in resource_types

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9055>
_______________________________________

From report at bugs.python.org  Tue Jun 22 17:50:24 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Jun 2010 15:50:24 +0000
Subject: [issue9057] Needs a home page
In-Reply-To: <1277218686.54.0.776970165473.issue9057@psf.upfronthosting.co.za>
Message-ID: <1277221824.35.0.89462524004.issue9057@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

What "project" are you talking about? This issue tracker?

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9057>
_______________________________________

From report at bugs.python.org  Tue Jun 22 18:08:27 2010
From: report at bugs.python.org (Ryan Coyner)
Date: Tue, 22 Jun 2010 16:08:27 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1277222907.1.0.902097317396.issue6715@psf.upfronthosting.co.za>


Changes by Ryan Coyner <rcoyner at gmail.com>:


----------
nosy: +rcoyner

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue Jun 22 18:44:40 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Tue, 22 Jun 2010 16:44:40 +0000
Subject: [issue9057] Needs a home page
In-Reply-To: <1277218686.54.0.776970165473.issue9057@psf.upfronthosting.co.za>
Message-ID: <1277225080.3.0.353101063602.issue9057@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

Distutils2, sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9057>
_______________________________________

From report at bugs.python.org  Tue Jun 22 19:13:13 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 22 Jun 2010 17:13:13 +0000
Subject: [issue3439] create a numbits() method for int and long types
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1277226793.0.0.358739001937.issue3439@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Minor addendum to Mark's last message: in the near release version of 2.7 (rc2), note 2 in 5.4. "Numeric Types ? int, float, long, complex" now starts "Conversion from floats using int() or long() truncates toward zero like the related function, math.trunc()" and no longer marks the usage of long as deprecated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Tue Jun 22 19:46:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Jun 2010 17:46:27 +0000
Subject: [issue9057] Needs a home page
In-Reply-To: <1277218686.54.0.776970165473.issue9057@psf.upfronthosting.co.za>
Message-ID: <1277228787.56.0.0591866464139.issue9057@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

d2 is still under heavy development. It is not recommended to rely on it. We work on features including documentation, you can monitor http://packages.python.org/Distutils2/ every two weeks to get updates.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9057>
_______________________________________

From report at bugs.python.org  Tue Jun 22 19:46:34 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 22 Jun 2010 17:46:34 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4
In-Reply-To: <1277217134.08.0.516349664803.issue9046@psf.upfronthosting.co.za>
Message-ID: <4C20F6F7.9070404@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ronald Oussoren wrote:
> 
> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
> 
> What I don't quite understand is why the build fails for you but passes for me. What configure flags did you use?

I posted the configure options in the first message on this ticket.

The failure appears to be due to the fact that we run and install
our software in /usr/local (which is the standard we use on all
Unix systems).

> This version should fare better:
> 
> def is_macosx_sdk_path(path):
>     """
>     Returns True if 'path' can be located in an OSX SDK
>     """
>     return (path.startswith('/usr/') and not path.startswith('/usr/local')) or path.startswith('/System/')

With this variant, the build works correctly, however, see below...

> This explicitly tests for paths that must be in the SDK:
> 
> * Anything in /System is owned by the system, and should be fetched
>   through the SDK
> * Likewise for anything in /usr that isn't in /usr/local
>  
> IMHO anyone that installs additional libraries in /usr/lib, or /System/Libraries/Frameworks is confused at best, and we shouldn't even try to support that.

...wouldn't it be better to check whether the SDK does indeed provide
the path in question and only then redirect to the SDK path instead
of the normal system one ?

I'm not sure whether these will ever be needed by Python,
but it would certainly make the function more robust:

There are quite a few things in /usr/lib that you don't find in
the SDK usr/lib/ dir. For /System the situation is even more obvious:
the SDK version only has these entries:

# ls -l /Developer/SDKs/MacOSX10.4u.sdk/System/Library/
total 0
drwxr-xr-x     3 root  wheel   102 Oct 27  2007 CFMSupport
drwxr-xr-x    92 root  wheel  3128 Oct 27  2007 Frameworks
drwxr-xr-x     3 root  wheel   102 Oct 27  2007 Printers
drwxr-xr-x   123 root  wheel  4182 Oct 27  2007 PrivateFrameworks

whereas the OS directory has dozens of entries.

> The repository contains an simpler (but in hindsight too simple) version because ${SDKROOT}/usr/local/lib is a symlink to the real /usr/local/lib. That works fine when looking for libraries, but not when looking for other files (such as headers).

Right, but really only that link. SDK also doesn't contain any links
for the missing /System/Library directories.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Tue Jun 22 19:49:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 22 Jun 2010 17:49:31 +0000
Subject: [issue9057] Distutils2 needs a home page
In-Reply-To: <1277218686.54.0.776970165473.issue9057@psf.upfronthosting.co.za>
Message-ID: <1277228971.8.0.370231204113.issue9057@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
components: +Documentation
title: Needs a home page -> Distutils2 needs a home page
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9057>
_______________________________________

From report at bugs.python.org  Tue Jun 22 19:56:44 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Tue, 22 Jun 2010 17:56:44 +0000
Subject: [issue9057] Distutils2 needs a home page
In-Reply-To: <1277218686.54.0.776970165473.issue9057@psf.upfronthosting.co.za>
Message-ID: <1277229404.61.0.292776728249.issue9057@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

Yes, I understand it's not ready for users.  However, even a project in process can benefit from having a home page, to boost awareness and link connectivity.  ATM there's no reasonably stable URL I can link to from http://ryppl.org/technology.html

I would be happy to create such a page if this is too much trouble.  It doesn't have to be very ambitious; just a notice saying D2 is under heavy development and links to relevant resources (e.g. bitbucket) would be fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9057>
_______________________________________

From report at bugs.python.org  Tue Jun 22 20:00:03 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Jun 2010 18:00:03 +0000
Subject: [issue3439] create a numbits() method for int and long types
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1277229603.82.0.238529024758.issue3439@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

So there are two issues here:

 - deprecation of int(my_float) and long(my_float)
 - removal of long in 3.x

I'm not sure which Terry is referring to here.

On the first, I don't think use of int() with float arguments actually *is* deprecated in any meaningful way.  At one point there was a push (related to PEP 3141) to deprecate truncating uses of int and introduce a new builtin trunk, but it never really took hold (and trunc ended up being relegated to the math module0;  I certainly don't expect to see such deprecation happen within the lifetime of Python 3.x, so I don't think it would be appropriate to mention it in the 2.x docs.

On the second, it's possible that there should be a mention somewhere in the 2.x docs that long() no longer exists in 3.x, and that for almost all uses int() works just as well.  A separate issue should probably be opened for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Tue Jun 22 20:00:54 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Jun 2010 18:00:54 +0000
Subject: [issue3439] create a numbits() method for int and long types
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1277229654.29.0.868261616227.issue3439@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Aargh!
'a new builtin trunk' -> 'a new builtin trunc'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Tue Jun 22 20:04:28 2010
From: report at bugs.python.org (Jon Seger)
Date: Tue, 22 Jun 2010 18:04:28 +0000
Subject: [issue9016] IDLE won't launch (Win XP)
In-Reply-To: <1276747536.03.0.234603288057.issue9016@psf.upfronthosting.co.za>
Message-ID: <1277229868.93.0.931581736066.issue9016@psf.upfronthosting.co.za>


Jon Seger <seger at biology.utah.edu> added the comment:

Here's the result of doing what Martin asked (and then launching the interpreter, to confirm that it's the 2.5.4 version that I installed on Thursday just before submitting my original bug report).

C:\PYTHON25 is the first item in the PATH. 
C:\Python25\Lib\idlelib\idle.py exists, and IDLE launches properly when I double-click its icon on the desktop.  But Python scripts (including idle.py and all of my own) do not show the Python icon.

Renaming .idlerc has no effect except that IDLE now doesn't have a list of recent files.  Or did you mean to try this after installing one of the later (2.6) versions of Python, under which IDLE would not launch?

Is this looking like a registry problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9016>
_______________________________________

From report at bugs.python.org  Tue Jun 22 20:08:45 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 22 Jun 2010 18:08:45 +0000
Subject: [issue9058] PyUnicodeDecodeError_Create asserts that various
	arguments are less than INT_MAX
In-Reply-To: <1277230125.41.0.418580473823.issue9058@psf.upfronthosting.co.za>
Message-ID: <1277230125.41.0.418580473823.issue9058@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

Running this code (seen via http://bugs.python.org/file10013/python-2.5.2-unicode_resize-utf16.py for issue 2620):
>>> msg = 'A'*2147483647 ; msg.decode('utf16')
leads to the python process exiting with an assertion failure:
python: Objects/exceptions.c:1787: PyUnicodeDecodeError_Create: Assertion `length < 2147483647' failed.

The reaason is that PyUnicodeDecodeError_Create contains this code:
PyObject *
PyUnicodeDecodeError_Create(
    const char *encoding, const char *object, Py_ssize_t length,
    Py_ssize_t start, Py_ssize_t end, const char *reason)
{
    assert(length < INT_MAX);
    assert(start < INT_MAX);
    assert(end < INT_MAX);
    return PyObject_CallFunction(PyExc_UnicodeDecodeError, "ss#nns",
                                 encoding, object, length, start, end, reason);
}

In the example above, we're creating a buffer containing a very large but odd-numbered of bytes, and trying to UTF-16 decode it, which requires an even number of bytes.

This leads to a UnicodeDecodeError with a very large value for each of length, start, and end, and although they fit in Py_ssize_t on 64-bit, they don't fit in an int.  

It seems that this will affect any other decoding errors for buffers that are >= INT_MAX in size: unicode decode errors will cause the python process to bail out with an assert failure.

It appears that throughout the UnicodeDecodeError representation that length, start and size are to be of size Py_ssize_t, rather than int: they are stored in fields of type Py_ssize_t, they are printed using format "%zd", which is indeed a Py_ssize_t (see http://docs.python.org/c-api/string.html#PyString_FromFormat ).

In PyUnicodeDecodeError_Create, "ss#nns" is:
  - "s" (string) [char *]: "encoding"
  - "s#" (string) [char *, int]:"object", "length"

  - "n" (int) [Py_ssize_t]: "start"
  - "n" (int) [Py_ssize_t]: "end"
  - "s" (string) [char *]: "reason"

See Python/modsupport.c: do_mkvalue: "s#" uses this logic:
				if (flags & FLAG_SIZE_T)
					n = va_arg(*p_va, Py_ssize_t);
				else
					n = va_arg(*p_va, int);
where FLAG_SIZE_T is set by _Py_BuildValue_SizeT, but not by Py_BuildValue.  The latter is what's called by PyObject_CallFunction.

Hence, as written, "length" must fit within an "int", but "start" and "end" don't have to.

"s#" calls PyString_FromStringAndSize(str, n) upon the data, which takes a Py_ssize_t.  It's going to be big, but may well fit in RAM (but might not).

The invoked function leads to a call to: UnicodeError_init, which calls:
    if (!PyArg_ParseTuple(args, "O!O!nnO!",
        &PyString_Type, &self->encoding,
        objecttype, &self->object,
        &self->start,
        &self->end,
        &PyString_Type, &self->reason)) {

"O!": (object) [typeobject, PyObject *]: &PyString_Type, &self->encoding,
"O!": (object) [typeobject, PyObject *]: objecttype, &self->object  (objecttype is passed as &PyString_Type)
"n": (integer) [Py_ssize_t]: &self->start,
"n": (integer) [Py_ssize_t]: &self->end,
"O!": (object) [typeobject, PyObject *]: &PyString_Type, &self->reason,

So it looks like the only place in construction where we actually restrict to "int" is in that "s#" in PyUnicodeDecodeError_Create, which looks fixable.

After construction:  various calls to PyString_FromFormat for start and end using format "%zd", which is indeed a Py_ssize_t (see http://docs.python.org/c-api/string.html#PyString_FromFormat )

So it looks like the only issue here is the restriction to "int" in PyUnicodeDecodeError_Create due to the use of "s#" in the call to PyObject_CallFunction; apart from that, it looks like the assertions can be removed.  

I'll attach a patch which removes this restriction.

(for my reference, I'm tracking this as https://bugzilla.redhat.com/show_bug.cgi?id=540518 )

----------
components: Unicode
messages: 108404
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: PyUnicodeDecodeError_Create asserts that various arguments are less than INT_MAX
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9058>
_______________________________________

From report at bugs.python.org  Tue Jun 22 20:10:57 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Jun 2010 18:10:57 +0000
Subject: [issue8455] buildbot: test_urllib2_localnet failures (Connection
	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1277230257.55.0.0102617272389.issue8455@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Just to confirm that with this fix test_urllib2_localnet is now passing for me.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8455>
_______________________________________

From report at bugs.python.org  Tue Jun 22 20:14:31 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 22 Jun 2010 18:14:31 +0000
Subject: [issue9058] PyUnicodeDecodeError_Create asserts that various
	arguments are less than INT_MAX
In-Reply-To: <1277230125.41.0.418580473823.issue9058@psf.upfronthosting.co.za>
Message-ID: <1277230471.53.0.857796110154.issue9058@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Patch to remove the restriction that the fields be < INT_MAX

Tested on x86_64 on a machine with > 12GB of RAM, leads to this exception, rather than the python process bailing out:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "Lib/encodings/utf_16.py", line 16, in decode
    return codecs.utf_16_decode(input, errors, True)
UnicodeDecodeError: 'utf16' codec can't decode byte 0x41 in position 2147483646: truncated data

I'm not sure about automated testing for this; the reproducer seems to need >=12GB of RAM - in borderline cases it drives my machine deep into swap, which can take a long time to recover from, and might be unacceptable in the test suite.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file17746/remove-PyUnicodeDecodeError_Create-assertions-issue9058.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9058>
_______________________________________

From report at bugs.python.org  Tue Jun 22 20:25:44 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 22 Jun 2010 18:25:44 +0000
Subject: [issue9058] PyUnicodeDecodeError_Create asserts that various
	arguments are less than INT_MAX
In-Reply-To: <1277230125.41.0.418580473823.issue9058@psf.upfronthosting.co.za>
Message-ID: <1277231144.11.0.180877650081.issue9058@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Actually, you should be able to just remove the asserts.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9058>
_______________________________________

From report at bugs.python.org  Tue Jun 22 20:39:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 22 Jun 2010 18:39:07 +0000
Subject: [issue9051] Cannot pickle timezone instances
In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za>
Message-ID: <1277231947.84.0.708506921314.issue9051@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Python version is fixed in sandbox and committed in r82154.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9051>
_______________________________________

From report at bugs.python.org  Tue Jun 22 21:06:11 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 22 Jun 2010 19:06:11 +0000
Subject: [issue9058] PyUnicodeDecodeError_Create asserts that various
	arguments are less than INT_MAX
In-Reply-To: <1277230125.41.0.418580473823.issue9058@psf.upfronthosting.co.za>
Message-ID: <1277233571.65.0.356221860324.issue9058@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

>>> Actually, you should be able to just remove the asserts.

Aha, thanks! 

Yes: #define PY_SSIZE_T_CLEAN is defined at the top of Objects/exceptions.c, so yes, Py_VaBuildValue is redirected to _Py_VaBuildValue_SizeT, so that 
  PyEval_CallFunction
calls:
  Py_VaBuildValue(format, vargs)
which is preprocessed to:
  _Py_VaBuildValue_SizeT
which calls:
  return va_build_value(format, va, FLAG_SIZE_T);
which means that "s#" is processed with flags==FLAG_SIZE_T, and thus as "Py_ssize_t" within do_mkvalue:
				if (flags & FLAG_SIZE_T)
					n = va_arg(*p_va, Py_ssize_t);
				else
					n = va_arg(*p_va, int);

So, yes, it does look like the three assert lines can simply be removed.

----------
Added file: http://bugs.python.org/file17747/remove-PyUnicodeDecodeError_Create-assertions-issue9058-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9058>
_______________________________________

From report at bugs.python.org  Tue Jun 22 21:17:22 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 22 Jun 2010 19:17:22 +0000
Subject: [issue9058] PyUnicodeDecodeError_Create asserts that various
	arguments are less than INT_MAX
In-Reply-To: <1277230125.41.0.418580473823.issue9058@psf.upfronthosting.co.za>
Message-ID: <1277234242.93.0.378043868497.issue9058@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Removed them in r82157.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9058>
_______________________________________

From report at bugs.python.org  Tue Jun 22 21:25:04 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Jun 2010 19:25:04 +0000
Subject: [issue6105] json.dumps doesn't respect OrderedDict's iteration order
In-Reply-To: <1243243366.01.0.202838739816.issue6105@psf.upfronthosting.co.za>
Message-ID: <1277234704.72.0.283434357864.issue6105@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Benjamin, it's a little late for this one for 2.7.  Do you prefer to close it forever or to treat it as a bug fix for 2.7.1?

----------
assignee: rhettinger -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6105>
_______________________________________

From report at bugs.python.org  Tue Jun 22 21:28:00 2010
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 22 Jun 2010 19:28:00 +0000
Subject: [issue9055] test_issue_8959_b fails when run from a service
In-Reply-To: <1277221320.11.0.989664694962.issue9055@psf.upfronthosting.co.za>
Message-ID: <4C210EB8.7050406@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

> To test windows callbacks, I suggest to use EnumResourceTypes()
> instead, which is more likely to work in any condition:

Unfortunately the proposed test doesn't detect the problem in Python2.7 rc1.
It runs without crashing, even if enumerating the resources in shell32.dll
which contains a lot more stuff than python.exe.

Maybe we should just remove the 'self.assertFalse()' call
in the current test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9055>
_______________________________________

From report at bugs.python.org  Tue Jun 22 21:58:10 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 22 Jun 2010 19:58:10 +0000
Subject: [issue9021] no copy.copy problem description
In-Reply-To: <20100622101034.GA9303@remy>
Message-ID: <AANLkTinGwAeqS3i0Ka7taN2hAEL6iV6SbOq72rG9Ah-z@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

> The doc change suggested by Terry could be helpful in the tutorial
> where a copy module is mentioned.

Can you post a link to this tutorial here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9021>
_______________________________________

From report at bugs.python.org  Tue Jun 22 22:19:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Jun 2010 20:19:20 +0000
Subject: [issue8999] Add Mercurial support to patchcheck
In-Reply-To: <1276593572.4.0.720668123002.issue8999@psf.upfronthosting.co.za>
Message-ID: <1277237960.18.0.472429094255.issue8999@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file17674/hg-support.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8999>
_______________________________________

From report at bugs.python.org  Tue Jun 22 22:21:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Jun 2010 20:21:19 +0000
Subject: [issue8999] Add Mercurial support to patchcheck
In-Reply-To: <1276593572.4.0.720668123002.issue8999@psf.upfronthosting.co.za>
Message-ID: <1277238079.61.0.92476680649.issue8999@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Updated. I also changed two sets to lists, to retain usage. I?m sure that Mercurial won?t print the same filename twice, and I?m nearly sure Subversion won?t either. Retaining order will make the report a bit more readable.

----------
Added file: http://bugs.python.org/file17748/hg-support.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8999>
_______________________________________

From report at bugs.python.org  Tue Jun 22 22:21:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Jun 2010 20:21:54 +0000
Subject: [issue8999] Add Mercurial support to patchcheck
In-Reply-To: <1276593572.4.0.720668123002.issue8999@psf.upfronthosting.co.za>
Message-ID: <1277238114.58.0.441177303823.issue8999@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

s/usage/order/ *sigh*

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8999>
_______________________________________

From report at bugs.python.org  Tue Jun 22 22:42:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Jun 2010 20:42:10 +0000
Subject: [issue9048] no OS X buildbots in the stable list
In-Reply-To: <1277148342.98.0.18086046529.issue9048@psf.upfronthosting.co.za>
Message-ID: <1277239330.54.0.0992149693623.issue9048@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9048>
_______________________________________

From report at bugs.python.org  Tue Jun 22 23:06:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 22 Jun 2010 21:06:01 +0000
Subject: [issue9018] os.path.normcase(None) does not raise an error on linux
	and should
In-Reply-To: <1276782016.7.0.192519527211.issue9018@psf.upfronthosting.co.za>
Message-ID: <1277240761.15.0.640796401591.issue9018@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

My understanding is that there is a deep problem here, in that file system case (and in some cases encoding) is not OS/platform dependent, but is rather *file system* dependent.

Adding lower to normcase on OS X is probably not going to break much code (he says with no evidence to back it up), but someday it would be nice to address the various file system type dependencies in the os module :(

In any case, it is probably better to address the 'lower' issue in a separate issue/patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9018>
_______________________________________

From report at bugs.python.org  Tue Jun 22 23:08:04 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jun 2010 21:08:04 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4
In-Reply-To: <1277145356.65.0.792770780459.issue9046@psf.upfronthosting.co.za>
Message-ID: <1277240884.82.0.596788245342.issue9046@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The search code must look in the SDK and not fall back on looking into the system to avoid finding new headers and libraries when trying to build using an older SDK on a newer system.

I don't think this is a problem at the moment, but it could be in the future. 

The reason I added the SDK support code was that Snow Leopard contained a newer version of the OpenSSL libraries and the Python build picked up version information from the system version of OpenSSL instead of the SDK, and that resulted in a disfunctional build (IIRC hashlib was incomplete and that caused numerous test failures).

Falling back to looking in the current system would be needed when looking for a file that isn't a header of library, but AFAIK we don't do that in setup.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Tue Jun 22 23:09:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Jun 2010 21:09:48 +0000
Subject: [issue3439] create a numbits() method for int and long types
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1277240988.51.0.648979543512.issue3439@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Please open a new issue for the documentation problems, it's no more related to "numbits()" method and this issue is closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Tue Jun 22 23:11:33 2010
From: report at bugs.python.org (Thomas Jollans)
Date: Tue, 22 Jun 2010 21:11:33 +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: <1277241093.72.0.414147105063.issue8990@psf.upfronthosting.co.za>


Thomas Jollans <thomas at jollans.com> added the comment:

OK, here's the new patch. I added tests for array(typecode, bytearray(b'abab')), a.extend(b'123') and a.extend(bytearray(b'123')). 

@Victor: int itemsize is the array's item size, buffer.itemsize is the strings' (and must be 1)

PROBLEM with this patch:

I changed "s#" to "y*". This means that str arguments are no longer accepted by fromstring. I don't think they ever should have been in 3.x, but it is an incompatible change and this got the test suite, which (I assume the code hasn't changed since 2.x) used a str argument. (changed in patch). It might be best to use "s*" instead of "y*", especially if this is applied to 3.1?

----------
Added file: http://bugs.python.org/file17749/array2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8990>
_______________________________________

From report at bugs.python.org  Tue Jun 22 23:20:13 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 22 Jun 2010 21:20:13 +0000
Subject: [issue8930] messed up formatting after reindenting
In-Reply-To: <1275862117.51.0.974367285734.issue8930@psf.upfronthosting.co.za>
Message-ID: <1277241613.77.0.897357765094.issue8930@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

The following command also finds files, in which tabs are preceded only by spaces:

find -name '*.[ch]' -exec grep -El $'^ *\t' {} \;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8930>
_______________________________________

From report at bugs.python.org  Tue Jun 22 23:32:06 2010
From: report at bugs.python.org (Tal Einat)
Date: Tue, 22 Jun 2010 21:32:06 +0000
Subject: [issue9016] IDLE won't launch (Win XP)
In-Reply-To: <1276747536.03.0.234603288057.issue9016@psf.upfronthosting.co.za>
Message-ID: <1277242326.09.0.65320670017.issue9016@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

Let's focus on the problem you're having with Python 2.6, with which you said IDLE won't launch.

Please try to run IDLE using Python 2.6.5:
1) Install Python 2.6.5, say to C:\Python26
2) Rename/move your .idlerc directory so there isn't any such directory under C:\Documents and Settings\<username>
3) Then go to that directory and run:

C:\Python26> .\python.exe Lib\idlelib\idle.py

Post the output of that here, so that we can help diagnose the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9016>
_______________________________________

From report at bugs.python.org  Tue Jun 22 23:34:17 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 22 Jun 2010 21:34:17 +0000
Subject: [issue3439] create a numbits() method for int and long types
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1277242457.71.0.0947318514325.issue3439@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Whoops, sorry to create confusion when I was trying to put this issue to rest completely. Let me try better. 

In his last message, Raymond said "Other possible wording:
 ... so that ``k`` is approximately ``1 + int(log(abs(x), 2))``."

That is what the current 2.7rc2 doc says.

In response, Mark said "I guess that could work." but quoted footnote 2, which implied that 'int' should be changed to 'trunc' in the example above. 

This implied to me that there was a lingering .numbits doc issue.
But footnote 2 is now changed, so I not longer think there is a doc issue, so I reported that, so no one else would think so.

I hope this is the end of this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Tue Jun 22 23:38:19 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 22 Jun 2010 21:38:19 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4
In-Reply-To: <1277240884.82.0.596788245342.issue9046@psf.upfronthosting.co.za>
Message-ID: <4C212D48.8050603@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ronald Oussoren wrote:
> 
> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
> 
> The search code must look in the SDK and not fall back on looking into the system to avoid finding new headers and libraries when trying to build using an older SDK on a newer system.

Right, but at least there should be an option to fall back to
the system provided libs. This is currently not the case.

The code would need some refactoring to make this possible,
though, e.g. a combined version of the SDK functions you added
to return the corrected path instead of just True/False.

> I don't think this is a problem at the moment, but it could be in the future. 
> 
> The reason I added the SDK support code was that Snow Leopard contained a newer version of the OpenSSL libraries and the Python build picked up version information from the system version of OpenSSL instead of the SDK, and that resulted in a disfunctional build (IIRC hashlib was incomplete and that caused numerous test failures).
> 
> Falling back to looking in the current system would be needed when looking for a file that isn't a header of library, but AFAIK we don't do that in setup.py.

I guess you should at least add a note pointing to this potential future
problem to the code and perhaps also reference this ticket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Tue Jun 22 23:42:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 22 Jun 2010 21:42:33 +0000
Subject: [issue9018] os.path.normcase(None) does not raise an error on linux
	and should
In-Reply-To: <1276782016.7.0.192519527211.issue9018@psf.upfronthosting.co.za>
Message-ID: <1277242953.16.0.378060491283.issue9018@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, I see my lack of knowledge of OS X has betrayed me.  Apparently you can set the case sensitivity of OS X file systems....so the deep problem is even deeper than I thought :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9018>
_______________________________________

From report at bugs.python.org  Tue Jun 22 23:46:02 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 22 Jun 2010 21:46:02 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1277243162.16.0.821874668847.issue7900@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Here is a (untested) work-around that won't require undefining _DARWIN_C_SOURCE: After all includes, say

#ifdef __APPLE__
int	 posix_getgroups(int, gid_t []) __asm("_getgroups");
#define getgroups posix_getgroups
#endif

This should cause linking to the same symbol as without _DARWIN_UNLIMITED_GETGROUPS/_DARWIN_C_SOURCE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Jun 22 23:57:59 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 22 Jun 2010 21:57:59 +0000
Subject: [issue9048] no OS X buildbots in the stable list
In-Reply-To: <1277203222.65.0.121825356892.issue9048@psf.upfronthosting.co.za>
Message-ID: <4C2131E3.3030305@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Am 22.06.2010 12:40, schrieb Ronald Oussoren:
>
> Ronald Oussoren<ronaldoussoren at mac.com>  added the comment:
>
> Then why bother providing binaries?

How is that related? There was no OSX build slave until very recently,
but binaries had been provided for years. I see no reason to stop doing
so.

 > to hunt down issues that were introduced by other bugfixes.

That's appreciated. However, I fail to see the relationship to the 
buildbot stable list. The port was in good shape, and *still* didn't
pass all tests. That's partially because the test suite tests boundary
behaviour that doesn't affect the shape of the port.

 > that there seem to be very few core developers that care about
 > OSX beyond it being some odd flavor of unix.

The problem at hand is the port *doesn't* pass the test suite on
a regular manner. If it would, it could be added, and somebody
breaking the port could be asked to revert the change, or fix it
on OSX. As it stands, changes being made cannot be easily correlated
with new failures on that platform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9048>
_______________________________________

From report at bugs.python.org  Tue Jun 22 23:59:55 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 22 Jun 2010 21:59:55 +0000
Subject: [issue9016] IDLE won't launch (Win XP)
In-Reply-To: <1277229868.93.0.931581736066.issue9016@psf.upfronthosting.co.za>
Message-ID: <4C213259.7020004@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Here's the result of doing what Martin asked (and then launching the
> interpreter, to confirm that it's the 2.5.4 version that I installed
> on Thursday just before submitting my original bug report).
>
> C:\PYTHON25 is the first item in the PATH.
> C:\Python25\Lib\idlelib\idle.py exists, and IDLE launches properly
> when I double-click its icon on the desktop.  But Python scripts
> (including idle.py and all of my own) do not show the Python icon.

Unfortunately, this is not what I asked. Instead, I asked you to
run idle.py IN A CONSOLE WINDOW (i.e. not by double-clicking),
and to report any output you see in that console window.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9016>
_______________________________________

From report at bugs.python.org  Wed Jun 23 00:01:03 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 22 Jun 2010 22:01:03 +0000
Subject: [issue9018] os.path.normcase(None) does not raise an error on linux
	and should
In-Reply-To: <1276782016.7.0.192519527211.issue9018@psf.upfronthosting.co.za>
Message-ID: <1277244063.12.0.980538918175.issue9018@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This problem should be addressed in another issue though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9018>
_______________________________________

From report at bugs.python.org  Wed Jun 23 01:09:12 2010
From: report at bugs.python.org (Christophe Kalt)
Date: Tue, 22 Jun 2010 23:09:12 +0000
Subject: [issue8893] file.{read,readlines} behaviour on Solaris
In-Reply-To: <1275861493.5.0.825742188873.issue8893@psf.upfronthosting.co.za>
Message-ID: <AANLkTim8cTn5DQHE4NGjwUwRvBjNgJ-UEEC6KAm-uL8S@mail.gmail.com>


Christophe Kalt <kalt at taranis.org> added the comment:

I haven't had a chance to build Python to check, but from the test output I
suspect the problem to be different on FreeBSD.

----------
Added file: http://bugs.python.org/file17750/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8893>
_______________________________________
-------------- next part --------------
I haven&#39;t had a chance to build Python to check, but from the test output I suspect the problem to be different on FreeBSD.<br>

From report at bugs.python.org  Wed Jun 23 02:19:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Jun 2010 00:19:11 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1277252351.16.0.852358112613.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Martin's solution works.  I don't think we need to worry about non-gcc compilers on OSX.  I am attaching a patch with tests where getgroups to id -G comparison test is skipped if id -G shows more than 16 groups.

Some of the added tests are skipped for non-privileged user.

----------
Added file: http://bugs.python.org/file17751/issue7900-trunk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Wed Jun 23 04:00:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 23 Jun 2010 02:00:17 +0000
Subject: [issue7192] webbrowser.get("firefox") does not work on Mac with
	installed Firefox
In-Reply-To: <1256306857.19.0.981560840081.issue7192@psf.upfronthosting.co.za>
Message-ID: <1277258417.65.0.979395884315.issue7192@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Sorry, I have no idea where that issue number came from.  The correct issue is #812089.

I just retested, and despite -remote being currently undocumented, it works on my windows VM with a current (3.6) version of firefox, and that the actions (eg: new-window) work as well.

I don't currently have an OS X machine to test on, although that may change this week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7192>
_______________________________________

From report at bugs.python.org  Wed Jun 23 04:14:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 23 Jun 2010 02:14:59 +0000
Subject: [issue812089] webbrowser.open_new() opens in an existing browser
	window
Message-ID: <1277259299.62.0.601015953366.issue812089@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note: the -remote switch actually works on windows firefox (just tested on 3.6).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue812089>
_______________________________________

From report at bugs.python.org  Wed Jun 23 05:13:18 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 23 Jun 2010 03:13:18 +0000
Subject: [issue9021] no copy.copy problem description
In-Reply-To: <AANLkTinGwAeqS3i0Ka7taN2hAEL6iV6SbOq72rG9Ah-z@mail.gmail.com>
Message-ID: <20100623031307.GA4532@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

> Can you post a link to this tutorial here?

Section 9.1 and 9.2 of the docs.python.org/tutorial
It may not be as explicit as you might want it to be, but it does sets
up background that assignments do not copy the object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9021>
_______________________________________

From report at bugs.python.org  Wed Jun 23 07:33:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 23 Jun 2010 05:33:12 +0000
Subject: [issue8893] file.{read,readlines} behaviour on Solaris
In-Reply-To: <1275609044.71.0.537925857344.issue8893@psf.upfronthosting.co.za>
Message-ID: <1277271192.82.0.325910770856.issue8893@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file17750/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8893>
_______________________________________

From report at bugs.python.org  Wed Jun 23 07:48:46 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 23 Jun 2010 05:48:46 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4
In-Reply-To: <1277145356.65.0.792770780459.issue9046@psf.upfronthosting.co.za>
Message-ID: <1277272126.74.0.748628725725.issue9046@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I don't agree that there must be an option to fall back to system provided libs. The point of using an SDK is to avoid doing that because you might end up with a binary that won't work on an earlier version of the OS (the OpenSSL one is an example of that).

I agree that the documentation/comments should be extended to not that additional work would be needed when we start looking for files that aren't headers or libraries.

BTW. I still don't quite understand why the build did fail for you in the first place. Is your source tree in /usr/local as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Wed Jun 23 07:49:15 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 23 Jun 2010 05:49:15 +0000
Subject: [issue7192] webbrowser.get("firefox") does not work on Mac with
	installed Firefox
In-Reply-To: <1256306857.19.0.981560840081.issue7192@psf.upfronthosting.co.za>
Message-ID: <1277272155.11.0.0289497726803.issue7192@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I tested on OSX with a current version of FF and it didn't work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7192>
_______________________________________

From report at bugs.python.org  Wed Jun 23 09:29:08 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 23 Jun 2010 07:29:08 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4
In-Reply-To: <1277272126.74.0.748628725725.issue9046@psf.upfronthosting.co.za>
Message-ID: <4C21B7C0.2090002@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ronald Oussoren wrote:
> 
> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
> 
> I don't agree that there must be an option to fall back to system provided libs. The point of using an SDK is to avoid doing that because you might end up with a binary that won't work on an earlier version of the OS (the OpenSSL one is an example of that).

If you don't and the SDK doesn't include the files Python is looking
for, then the build will fail, so I don't see an improvement in not
doing so ;-)

Also note that a user may not have a require to be able to use the
built Python on some previous version of the OS.

Note that if you use MacPorts it's fairly common to use e.g.
use their Tcl version for Python which resides in /Library
as well.

The SDK logic should not redirect such paths to the SDK were they
don't exist.

> I agree that the documentation/comments should be extended to not that additional work would be needed when we start looking for files that aren't headers or libraries.
> 
> BTW. I still don't quite understand why the build did fail for you in the first place. Is your source tree in /usr/local as well?

Yes, we build and install from /usr/local/src - as is standard for
Unix platforms. I know that Mac OS X is different in some way, but
at least the Mac ports collection uses the same approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Wed Jun 23 09:53:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 23 Jun 2010 07:53:25 +0000
Subject: [issue3439] create a numbits() method for int and long types
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1277279605.95.0.565086938124.issue3439@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ah; sorry for misunderstanding.  Thanks for the explanation, Terry!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Wed Jun 23 09:54:32 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Jun 2010 07:54:32 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1277279672.45.0.454607609945.issue9025@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, here are two approaches to getting an equi-distributed version of int(n*random()) where 0 < n <= 2**53.  The first mirrors the approach currently in the code.  The second approach makes fewer calls to random().

def rnd1(n):
    assert 0 < n <= 2**53
    N = 1 << (n-1).bit_length()
    r = int(N * random())
    while r >= n:
        r = int(N * random())
    return r

def rnd2(n, N=1<<53):
    assert 0 < n <= N
    NN = N - (N % n) + 0.0  # largest multiple of n <= N
    r = N * random()        # a float with an integral value
    while r >= NN:
        r = N * random()
    return int(r) % n

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Wed Jun 23 10:24:37 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 23 Jun 2010 08:24:37 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4
In-Reply-To: <1277145356.65.0.792770780459.issue9046@psf.upfronthosting.co.za>
Message-ID: <1277281477.07.0.232720019536.issue9046@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

That (/usr/local/src) explains why I haven't been able to reproduce the problem, that worried me a little.

W.r.t. to the SDK:

1) You don't have to use an SDK: use 

     configure --enable-universalsdk=/  MACOSX_DEPLOYMENT_TARGET=10.5

  (or whatever target you wish to support)

2) The SDK should only affect system files, that is anything in /System
   and /usr (except for /usr/local). /Library is not part of the SDK
   and is not affected by SDK settings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Wed Jun 23 10:35:53 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 23 Jun 2010 08:35:53 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4
In-Reply-To: <1277281477.07.0.232720019536.issue9046@psf.upfronthosting.co.za>
Message-ID: <4C21C765.7030907@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ronald Oussoren wrote:
> 
> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
> 
> That (/usr/local/src) explains why I haven't been able to reproduce the problem, that worried me a little.
> 
> W.r.t. to the SDK:
> 
> 1) You don't have to use an SDK: use 
> 
>      configure --enable-universalsdk=/  MACOSX_DEPLOYMENT_TARGET=10.5
> 
>   (or whatever target you wish to support)

Well, we want to build universal binaries, so we do need the SDK.

> 2) The SDK should only affect system files, that is anything in /System
>    and /usr (except for /usr/local). /Library is not part of the SDK
>    and is not affected by SDK settings.

Sorry, I should have written /System/Library/. You find Tcl
in /System/Library, but not in
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/

Anyway, this doesn't appear to matter, since setup.py picks up the
files from a different dir: /System/Library/Frameworks/Tk.framework
and that is included in the SDK.

As I said: The fix makes the build work, so it's good enough for
now. In the future all this may will have to be revisited.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Wed Jun 23 10:41:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 23 Jun 2010 08:41:55 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1277282515.08.0.848728028886.issue9025@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Either of these looks good to me.

If the last line of the second is changed from "return int(r) % n" to "return int(r) // (N // n)" then it'll use the high-order bits of random()  instead of the low-order bits.  This doesn't matter for MT, but might matter for subclasses of Random using a different underlying generator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Wed Jun 23 10:44:03 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 23 Jun 2010 08:44:03 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1277282643.14.0.424707720718.issue7900@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Wrt. non-gcc compilers: we do need to worry about those (there have been bugreports in the past about using the Intel compiler), but those compilers still have to be able to process system headers and Martin's patch basicly adds the definition from the system headers to posixmodule.c.

As mentioned on python-dev I'm still not happy about reverting to the previous behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Wed Jun 23 11:26:15 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 23 Jun 2010 09:26:15 +0000
Subject: [issue8930] messed up formatting after reindenting
In-Reply-To: <1275862117.51.0.974367285734.issue8930@psf.upfronthosting.co.za>
Message-ID: <1277285175.43.0.147657608414.issue8930@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Patch for ceval.c. If you agree with the macro indentation (starting
in line 815) I can commit it and port it to the other branches.

----------
keywords: +patch
nosy: +skrah
Added file: http://bugs.python.org/file17752/trunk-ceval-indent.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8930>
_______________________________________

From report at bugs.python.org  Wed Jun 23 11:51:13 2010
From: report at bugs.python.org (Raven Demeyer)
Date: Wed, 23 Jun 2010 09:51:13 +0000
Subject: [issue9059] Backwards compatibility
In-Reply-To: <1277286673.12.0.243169003813.issue9059@psf.upfronthosting.co.za>
Message-ID: <1277286673.12.0.243169003813.issue9059@psf.upfronthosting.co.za>


New submission from Raven Demeyer <raven.demeyer at gmail.com>:

Python 3 is not backwards compatible with Python 2.

Example:
Python 2: print 'foo'
Python 3: print(bar)

Problem:
Code written for Python during version 2 cannot be used/compiled in version 3

Solution:
Just like any decent self-respecting programming language, add backwards compatibility.

----------
components: Regular Expressions
messages: 108444
nosy: Raven
priority: normal
severity: normal
status: open
title: Backwards compatibility
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9059>
_______________________________________

From report at bugs.python.org  Wed Jun 23 11:51:33 2010
From: report at bugs.python.org (Torne Wuff)
Date: Wed, 23 Jun 2010 09:51:33 +0000
Subject: [issue9060] Python/dup2.c doesn't compile on (at least) newlib
In-Reply-To: <1277286692.98.0.844862215955.issue9060@psf.upfronthosting.co.za>
Message-ID: <1277286692.98.0.844862215955.issue9060@psf.upfronthosting.co.za>


New submission from Torne Wuff <torne-pythonbugs at wolfpuppy.org.uk>:

On systems without dup2(), Python tries to compile its own from Python/dup2.c, but this file refers to close() without including unistd.h. This causes it to not compile with newlib (and possibly other C libraries, presumably it was relying on fcntl.h indirectly including it?).

This is probably true of all older versions as well, but Python 2.x doesn't appear to actually bother to compile dup2.c even if the system lacks dup2, so it doesn't actually cause a build error there.

(building python for a semi-freestanding environment is "fun")

----------
components: Interpreter Core
files: fix_dup2.patch
keywords: patch
messages: 108445
nosy: torne
priority: normal
severity: normal
status: open
title: Python/dup2.c doesn't compile on (at least) newlib
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file17753/fix_dup2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9060>
_______________________________________

From report at bugs.python.org  Wed Jun 23 12:08:53 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 23 Jun 2010 10:08:53 +0000
Subject: [issue9059] Backwards compatibility
In-Reply-To: <1277286673.12.0.243169003813.issue9059@psf.upfronthosting.co.za>
Message-ID: <1277287733.96.0.681535767573.issue9059@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

as stated in
http://www.python.org/download/releases/3.1.2/
python 3 is designed to be backwards incompatible.

I suggest you to follow the link "Conversion tool for Python 2.x code".

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9059>
_______________________________________

From report at bugs.python.org  Wed Jun 23 12:37:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Jun 2010 10:37:25 +0000
Subject: [issue9059] Backwards compatibility
In-Reply-To: <1277286673.12.0.243169003813.issue9059@psf.upfronthosting.co.za>
Message-ID: <1277289445.98.0.860795017126.issue9059@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Code written for Python during version 2 cannot be 
> used/compiled in version 3

Use 2to3 script to convert your Python2 program to Python3. More information at:
http://docs.python.org/py3k/whatsnew/3.0.html#porting-to-python-3-0

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9059>
_______________________________________

From report at bugs.python.org  Wed Jun 23 12:44:06 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 23 Jun 2010 10:44:06 +0000
Subject: [issue9059] Backwards compatibility
In-Reply-To: <1277286673.12.0.243169003813.issue9059@psf.upfronthosting.co.za>
Message-ID: <1277289846.71.0.258562760537.issue9059@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Python 2 is also forward compatible with several Python 3 features, for example:

>>> from __future__ import print_function
>>> print('foo')
foo

----------
components:  -Regular Expressions
nosy: +ezio.melotti
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9059>
_______________________________________

From report at bugs.python.org  Wed Jun 23 15:34:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 23 Jun 2010 13:34:18 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1277300058.45.0.180462726489.issue8254@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

5) Should the command write different files per Python version and platform? 4Suite?s config command does that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8254>
_______________________________________

From report at bugs.python.org  Wed Jun 23 16:00:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Jun 2010 14:00:14 +0000
Subject: [issue8930] messed up formatting after reindenting
In-Reply-To: <1275862117.51.0.974367285734.issue8930@psf.upfronthosting.co.za>
Message-ID: <1277301614.75.0.475578433417.issue8930@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Stefan: it's ok with me, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8930>
_______________________________________

From report at bugs.python.org  Wed Jun 23 16:23:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Jun 2010 14:23:32 +0000
Subject: [issue9060] Python/dup2.c doesn't compile on (at least) newlib
In-Reply-To: <1277286692.98.0.844862215955.issue9060@psf.upfronthosting.co.za>
Message-ID: <1277303012.33.0.00411264298482.issue9060@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(as a sidenote, the last significant changes to dup2.c date back from 1994)

----------
nosy: +gvanrossum, loewis, pitrou
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9060>
_______________________________________

From report at bugs.python.org  Wed Jun 23 16:25:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Jun 2010 14:25:12 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1277303112.94.0.818153811858.issue8254@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Shouldn't "config" and "configure" have more distinguishable names?
(if I understand correctly, they both are distutils2 commands)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8254>
_______________________________________

From report at bugs.python.org  Wed Jun 23 16:37:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Jun 2010 14:37:18 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1277303838.85.0.715677314178.issue9025@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This wouldn't be the first time reproduceability is dropped, since reading from the docs:

?As an example of subclassing, the random module provides the WichmannHill class that implements an alternative generator in pure Python. The class provides a backward compatible way to reproduce results from earlier versions of Python, which used the Wichmann-Hill algorithm as the core generator.?

Also:

> FWIW, we spent ten years maintaining the ability to reproduce
> sequences.  It has become an implicit promise.

IMO it should either be documented explicitly, or be taken less dearly. There's not much value in an "implicit promise" that's only known by a select few.

(besides, as Terry said, I think most people are more concerned by the quality of the random distribution than by the reproduceability of sequences)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Wed Jun 23 16:42:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 23 Jun 2010 14:42:28 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1277304148.98.0.123132370861.issue8254@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

4Suite?s DistExt has a config command similar to the new Distutils2 configure command described in this bug report. The Distutils config command is an unfinished command with use similar to autotools configure scripts. From the module docstring:

?a (mostly) empty command class that exists mainly to be sub-classed by specific module distributions and applications.  The idea is that while every "config" command is different, at least they're all named the same, and users always see "config" in the list of standard commands.  Also, this is a good place to put common configure-like tasks: "try to compile this C code", or "figure out where this header file lives"?.

The module has seen 26 commits in 10 years. I find the name clash confusing too for end users and wanted to bring the issue later. If I understand autotools correctly, it encompasses both config and configure commands. Since there are no conflicts in options or functionality (config.run is a no-op, configure.run writes a file), I think dropping config or merging it with configure would make a lot of sense. But first things first, configure needs to be reviewed and accepted (5 open questions :) and then I?ll propose a merge into a unified config command (short names win).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8254>
_______________________________________

From report at bugs.python.org  Wed Jun 23 16:48:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Jun 2010 14:48:23 +0000
Subject: [issue8999] Add Mercurial support to patchcheck
In-Reply-To: <1276593572.4.0.720668123002.issue8999@psf.upfronthosting.co.za>
Message-ID: <1277304503.36.0.99109426913.issue8999@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The purpose of patchcheck.py is not obvious to me. If it's meant to be used by committers (rather than contributors), than we should wait for the actual hg migration and the definition of our new workflow. Also, we might "need" two separate scripts: one for individual changesets and one for pushes.

("need" is in quotes because I'm not sure anyone actually uses patchcheck.py)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8999>
_______________________________________

From report at bugs.python.org  Wed Jun 23 17:39:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Jun 2010 15:39:45 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1277307585.75.0.799128208144.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Reposting from python-dev. See "os.getgroups() on MacOS X" <http://mail.python.org/pipermail/python-dev/2010-June/100960.html>.

"""
On Wed, Jun 23, 2010 at 2:08 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
..
>>
>>> * [Ronald's proposal] results in posix.getgroups not reflecting results of posix.setgroups
>>>
>>
>> This effectively substitutes getgrouplist called on the current user
>> for getgroups.  In 3.x, I believe the correct action will be to
>> provide direct access to getgrouplist which is while not POSIX (yet?),
>> is widely available.
>
> I don't mind adding getgrouplist, but that issue is seperator from this one. BTW. Appearently getgrouplist is posix
> (<http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/libc.html>), although this isn't a
> requirement for being added to the posix module.
>

(The link you provided leads to "Linux Standard Base Core
Specification," which is different from POSIX, but the distinction is
not relevant for our discussion.)

>
> It is still my opinion that the second option is preferable for better compatibility with system tools, even if the patch
> is more complicated and the library function we use can be considered to be broken.

Let me try to formulate what the disagreement is.  There are two
different group lists that can be associated with a running process:
1) The list of current supplementary group IDs maintained by the
system for each process and stored in per-process system tables; and
2) The list of the groups that include the uid under which the process
is running as a member.

The first list is returned by a system call getgroups and the second
can be obtained using system database access functions as follows:

pw = getpwuid(getuid())
getgrouplist(pw->pw_name, ..)

The first list can be modified by privileged processes using setgroups
system call, while the second changes when system databases change.

The problem that _DARWIN_C_SOURCE introduces is that it replaces
system getgroups with a database query effectively making the true
process' list of supplementary group IDs inaccessible to programs.
See source code at
<http://www.opensource.apple.com/source/Libc/Libc-594.1.4/sys/getgroups.c>.

The problem is complicated by the fact that OSX true getgroups call
appears to truncate the list of groups to NGROUPS_MAX=16.  Note,
however that it is not clear whether the system call truncates the
list or the underlying process tables are limited to 16 entries and
additional groups are ignored when the process is created.

In my view, getgroups and getgrouplist are two fundamentally different
operations and both should be provided by the os module.  Redefining
os.getgroups to invoke getgrouplist instead of system getgroups on one
particular platform to work around that platform's system call
limitation is not right.
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From orsenthil at gmail.com  Wed Jun 23 05:13:07 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Wed, 23 Jun 2010 08:43:07 +0530
Subject: [issue9021] no copy.copy problem description
In-Reply-To: <AANLkTinGwAeqS3i0Ka7taN2hAEL6iV6SbOq72rG9Ah-z@mail.gmail.com>
References: <20100622101034.GA9303@remy>
	<AANLkTinGwAeqS3i0Ka7taN2hAEL6iV6SbOq72rG9Ah-z@mail.gmail.com>
Message-ID: <20100623031307.GA4532@remy>

> Can you post a link to this tutorial here?

Section 9.1 and 9.2 of the docs.python.org/tutorial
It may not be as explicit as you might want it to be, but it does sets
up background that assignments do not copy the object.

From report at bugs.python.org  Wed Jun 23 17:46:35 2010
From: report at bugs.python.org (Craig Younkins)
Date: Wed, 23 Jun 2010 15:46:35 +0000
Subject: [issue9061] cgi.escape Can Lead To XSS Vulnerabilities
In-Reply-To: <1277307995.11.0.923855376948.issue9061@psf.upfronthosting.co.za>
Message-ID: <1277307995.11.0.923855376948.issue9061@psf.upfronthosting.co.za>


New submission from Craig Younkins <cyounkins at gmail.com>:

The method in question: http://docs.python.org/library/cgi.html#cgi.escape
http://svn.python.org/view/python/tags/r265/Lib/cgi.py?view=markup   # at the bottom
http://code.python.org/hg/trunk/file/3be6ff1eebac/Lib/cgi.py#l1031

"Convert the characters '&', '<' and '>' in string s to HTML-safe sequences. Use this if you need to display text that might contain such characters in HTML. If the optional flag quote is true, the quotation mark character ('"') is also translated; this helps for inclusion in an HTML attribute value, as in <A HREF="...">. If the value to be quoted might include single- or double-quote characters, or both, consider using the quoteattr() function in the xml.sax.saxutils module instead."

cgi.escape never escapes single quote characters, which can easily lead to a Cross-Site Scripting (XSS) vulnerability. This seems to be known by many, but a quick search reveals many are using cgi.escape for HTML attribute escaping.

The intended use of this method is unclear to me. Up to and including Mako 0.3.3, this method was the HTML escaping method. Used in this manner, single-quoted attributes with user-supplied data are easily susceptible to cross-site scripting vulnerabilities.

While the documentation says "if the value to be quoted might include single- or double-quote characters... [use the] xml.sax.saxutils module instead," it also implies that this method will make input safe for HTML. Because this method escapes 4 of the 5 key XML characters, it is reasonable to expect some will use it for HTML escaping.

I suggest rewording the documentation for the method making it more clear what it should and should not be used for. I would like to see the method changed to properly escape single-quotes, but if it is not changed, the documentation should explicitly say this method does not make input safe for inclusion in HTML.

This is definitely affecting the security of some Python web applications. I already mentioned Mako, but I've found this type of bug in other frameworks and engines because the creators either called cgi.escape directly or modeled their own after it.

Craig Younkins

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 108457
nosy: Craig.Younkins, docs at python
priority: normal
severity: normal
status: open
title: cgi.escape Can Lead To XSS Vulnerabilities
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/issue9061>
_______________________________________

From report at bugs.python.org  Wed Jun 23 17:47:38 2010
From: report at bugs.python.org (Craig Younkins)
Date: Wed, 23 Jun 2010 15:47:38 +0000
Subject: [issue9061] cgi.escape Can Lead To XSS Vulnerabilities
In-Reply-To: <1277307995.11.0.923855376948.issue9061@psf.upfronthosting.co.za>
Message-ID: <1277308058.3.0.934037641342.issue9061@psf.upfronthosting.co.za>


Changes by Craig Younkins <cyounkins at gmail.com>:


----------
type:  -> security

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9061>
_______________________________________

From report at bugs.python.org  Wed Jun 23 18:15:00 2010
From: report at bugs.python.org (Olivier Berten)
Date: Wed, 23 Jun 2010 16:15:00 +0000
Subject: [issue9062] urllib.urlopen crashes when launched from a thread
In-Reply-To: <1277309700.12.0.0164704754681.issue9062@psf.upfronthosting.co.za>
Message-ID: <1277309700.12.0.0164704754681.issue9062@psf.upfronthosting.co.za>


New submission from Olivier Berten <olivier.berten at gmail.com>:

I'm writing SwatchBooker <https://launchpad.net/swatchbooker>, an app that's (among other things) reading some data from the web. When urllib.urlopen is called first from within a secondary thread, the app crashes (or freezes). If it's been called first from the main thread, there's no problem.

You can reproduce that by downloading http://launchpad.net/swatchbooker/trunk/0.7/+download/SwatchBooker-0.7.noinstall.zip

1. Launch swatchbooker.pyw
2. Open from web
3. Select ICI Dulux, Pantone or RAL
4. Cancel
5. Close the program
6. Relaunch swatchbooker.pyw
7. Open from web
8. Choose any swatch from ICI Dulux, Pantone or RAL (Don't click ColorCharts.org or Digital Colour Atlas!)
9. OK
10. Crash

For ColorCharts.org and Digital Colour Atlas, the list itself is loaded through urllib.urlopen from the main thread so it makes the rest go smoothly...

----------
components: None
messages: 108458
nosy: olivier-berten
priority: normal
severity: normal
status: open
title: urllib.urlopen crashes when launched from a thread
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9062>
_______________________________________

From report at bugs.python.org  Wed Jun 23 18:49:24 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 23 Jun 2010 16:49:24 +0000
Subject: [issue8798] tkinter build variants on OSX
In-Reply-To: <1274692007.27.0.519809230611.issue8798@psf.upfronthosting.co.za>
Message-ID: <1277311764.62.0.412038760834.issue8798@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +hobbs, srid, trentm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8798>
_______________________________________

From report at bugs.python.org  Wed Jun 23 18:57:24 2010
From: report at bugs.python.org (Jon Seger)
Date: Wed, 23 Jun 2010 16:57:24 +0000
Subject: [issue9016] IDLE won't launch (Win XP)
In-Reply-To: <1276747536.03.0.234603288057.issue9016@psf.upfronthosting.co.za>
Message-ID: <1277312244.21.0.225891638762.issue9016@psf.upfronthosting.co.za>


Jon Seger <seger at biology.utah.edu> added the comment:

Actually I did do exactly what Martin requested, but then somehow I failed to include the output in my message, which doesn't really make sense as a result.  How embarrassing!  I apologize.  I thought I had included something like the following:

C:\Documents and Settings\jon\Desktop>python Lib\idlelib\idle.py
python: can't open file 'Lib\idlelib\idle.py': [Errno 2] No such file or directory

Same response with forward or back slashes in the argument.  However, if I give python the full path (either with forward or back slashes), then it successfully launches IDLE:

C:\Documents and Settings\jon\Desktop>python c:/python25/Lib/idlelib/
idle.py

Now my remark about c:\Python25 being the first item in the path should make more sense than it did in the message as I sent it!

Again, this is all with 2.5.4, the installation that DOES launch IDLE when I click the desktop icon.  I'll try later today with 2.6.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9016>
_______________________________________

From report at bugs.python.org  Wed Jun 23 19:00:09 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 23 Jun 2010 17:00:09 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1277303838.85.0.715677314178.issue9025@psf.upfronthosting.co.za>
Message-ID: <20100623165955.GA2645@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I guess, Antoine wanted to point out this:

"Changed in version 2.3: MersenneTwister replaced Wichmann-Hill as the
default generator."

But as the paragraph points out Python did provide non default WichmanHill
class for generating repeatable sequences with older python.

My brief reading on this topic, does suggest that 'repeatability' is
an important requirement for any PRNG.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Wed Jun 23 19:02:42 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 23 Jun 2010 17:02:42 +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: <1277312562.46.0.754498704993.issue5672@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5672>
_______________________________________

From report at bugs.python.org  Wed Jun 23 19:05:52 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 23 Jun 2010 17:05:52 +0000
Subject: [issue8999] Add Mercurial support to patchcheck
In-Reply-To: <1276593572.4.0.720668123002.issue8999@psf.upfronthosting.co.za>
Message-ID: <1277312752.79.0.928814447954.issue8999@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So patchcheck is meant for both contributors and committers. I originally wrote it for me, but it helps make sure the patch is in a reasonable state before someone submits a patch.

As for Hg support, enough people seem to run mq on top of svn to make this a reasonable thing to add now and to change once the transition occurs.

----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8999>
_______________________________________

From report at bugs.python.org  Wed Jun 23 19:14:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Jun 2010 17:14:47 +0000
Subject: [issue9063] TZ examples in datetime.rst are incorrect
In-Reply-To: <1277313287.04.0.19115846548.issue9063@psf.upfronthosting.co.za>
Message-ID: <1277313287.04.0.19115846548.issue9063@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

With python started at the root of the source tree and TZ=US/Eastern in the environment,

>>> exec(open('Doc/includes/tzinfo-examples.py').read())
>>> import os
>>> os.environ['TZ']
'US/Eastern'
>>> from datetime import *
>>> x = datetime(2010, 11, 7, 5, tzinfo=timezone.utc)
>>> print(x, x.astimezone(Local), x.astimezone(Eastern))
2010-11-07 05:00:00+00:00 2010-11-07 01:00:00-04:00 2010-11-07 01:00:00-05:00
>>> x.astimezone(Local).dst() == x.astimezone(Eastern).dst() 
False

Note that according to my understanding of the long comment at the end of datetimemodule.c, zone conversion from UTC is a well defined operation unless there is a bug in tzinfo subclass implementation.

----------
assignee: docs at python
components: Documentation
messages: 108462
nosy: belopolsky, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: TZ examples in datetime.rst are incorrect
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9063>
_______________________________________

From report at bugs.python.org  Wed Jun 23 19:33:33 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 23 Jun 2010 17:33:33 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1277314413.19.0.0339409186421.issue9025@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

BTW, the Wichmann-Hill code is gone in py3k, so that doc paragraph needs removing or updating.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Wed Jun 23 19:37:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Jun 2010 17:37:29 +0000
Subject: [issue9063] TZ examples in datetime.rst are incorrect
In-Reply-To: <1277313287.04.0.19115846548.issue9063@psf.upfronthosting.co.za>
Message-ID: <1277314649.67.0.0693015747916.issue9063@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The result given when Eastern tzinfo object is used is clearly wrong.  The timezone shift should not change the actual time, but

>>> x == x.astimezone(Eastern)
False

while

>>> x == x.astimezone(Local)
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9063>
_______________________________________

From report at bugs.python.org  Wed Jun 23 19:47:10 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 23 Jun 2010 17:47:10 +0000
Subject: [issue9062] urllib.urlopen crashes when launched from a thread
In-Reply-To: <1277309700.12.0.0164704754681.issue9062@psf.upfronthosting.co.za>
Message-ID: <1277315230.88.0.478389976617.issue9062@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

There isn't a problem with urllib with respect to threading as such. 
There are programs and examples which use this module in multi-threading environment. 

I could not run your app, I am not on Mac, but some of the changes you could try is:
- Not to pollute module namespace with from somemodule import *  ( And in the process importing urllib).
- Use the 'import urllib' in each of the module that you using.

If you have specific traceback, post it here. ( An smaller snippet/example to reproduce will help). Feel free to reopen the issue if you see that it indeed a bug.

----------
nosy: +orsenthil
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9062>
_______________________________________

From report at bugs.python.org  Wed Jun 23 20:01:22 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Jun 2010 18:01:22 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1277316082.09.0.450786899993.issue9025@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks guys, I've got it from here.

Some considerations for the PRNG are:
* equidistribution (for quality)
* repeatability from the same seed (even in multithreaded environments)
* quality and simplicity of API (for usability)
* speed (it matters whether a Monte Carlo simulation takes 5 minutes or 30 minutes).

I'm looking at several ideas:
* updating the new randrange() to use rnd2() algorithm shown above (for equidistribution).
* possibly providing a C version of rnd2() and using it in randrange() for speed and for thread-safety.
* possibly updating shuffle() and choice() to use rnd2().
* moving the existing randrange() to randrange_quick() -- uses int(n * random) for speed and for reproducibility of previously created sequences.  Alternatively, adding a recipe to the docs for recreating old sequences and not cluttering the code with backwards compatibility cruft.

Am raising the priority to normal because I think some effort needs to be made to address equidistribution in 3.2.  Will take some time to come-up with a good patch that balances quality, simplicity, speed, thread-safety, and reproducibility.   

May also consult with Tim Peters who has previously voiced concerns about stripping bits off of multiple calls to random() because the MT proofs make no guarantees about quality in those cases.  I don't think this is an issue in practice, but in theory when we start tossing out some of the calls to random(), we're also throwing away the guarantees of a long periodic, 623 dimensions, uniformity, and equidistribution.

----------
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Wed Jun 23 20:03:08 2010
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 23 Jun 2010 18:03:08 +0000
Subject: [issue9048] no OS X buildbots in the stable list
In-Reply-To: <1277148342.98.0.18086046529.issue9048@psf.upfronthosting.co.za>
Message-ID: <1277316188.56.0.592798281077.issue9048@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Bit of a chicken/egg issue here.  Since we haven't had OS X buildbots for very long, and the ones we do have represent odd configurations, I think it's premature to say that "the port *doesn't* pass the test suite on
a regular manner".  I think it's just as reasonable to say that the developers making changes just aren't aware of bad side-effects on OS X.  A good way to remedy that would be to make those bad side-effects more apparent, for example by adding an OS X buildbot into the "stable" set.

Another issue is that none of the three OS X buildbots now running are really good representatives of the technology that most people I know who use OS X really use.  That would be an Intel Core 2 Duo machine running Snow Leopard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9048>
_______________________________________

From report at bugs.python.org  Wed Jun 23 20:07:37 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Wed, 23 Jun 2010 18:07:37 +0000
Subject: [issue9048] no OS X buildbots in the stable list
In-Reply-To: <1277148342.98.0.18086046529.issue9048@psf.upfronthosting.co.za>
Message-ID: <1277316457.16.0.701056005687.issue9048@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9048>
_______________________________________

From report at bugs.python.org  Wed Jun 23 20:19:37 2010
From: report at bugs.python.org (flashk)
Date: Wed, 23 Jun 2010 18:19:37 +0000
Subject: [issue8901] Windows registry path not ignored with -E option
In-Reply-To: <1275705565.03.0.753930892849.issue8901@psf.upfronthosting.co.za>
Message-ID: <1277317177.91.0.350430374632.issue8901@psf.upfronthosting.co.za>


flashk <flashk at gmail.com> added the comment:

Any chance of getting this into 2.7 final? This fix is important for embedding Python in Windows applications.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8901>
_______________________________________

From report at bugs.python.org  Wed Jun 23 20:22:42 2010
From: report at bugs.python.org (Craig Younkins)
Date: Wed, 23 Jun 2010 18:22:42 +0000
Subject: [issue9061] cgi.escape Can Lead To XSS Vulnerabilities
In-Reply-To: <1277307995.11.0.923855376948.issue9061@psf.upfronthosting.co.za>
Message-ID: <1277317362.05.0.143587672652.issue9061@psf.upfronthosting.co.za>


Craig Younkins <cyounkins at gmail.com> added the comment:

Proof of concept:
print """<body class='%s'></body>""" % cgi.escape("' onload='alert(1);' bad='")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9061>
_______________________________________

From report at bugs.python.org  Wed Jun 23 20:29:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Jun 2010 18:29:51 +0000
Subject: [issue9063] TZ examples in datetime.rst are incorrect
In-Reply-To: <1277313287.04.0.19115846548.issue9063@psf.upfronthosting.co.za>
Message-ID: <1277317791.39.0.255972459527.issue9063@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Let's establish what is the correct wall clock sequence around EDT to EST transition:

>>> import time
>>> def print_time(s):
...    tt = time.localtime(s)
...    print(time.strftime('%c %z %Z', tt))

x = datetime(2010, 11, 7, 5)
>>> s = (x - datetime(1970, 1, 1))//timedelta(seconds=1)

>>> for i in range(-3600, 5000, 1200):
...   print_time(s + i)
... 
Sun Nov  7 00:00:00 2010 -0400 EDT
Sun Nov  7 00:20:00 2010 -0400 EDT
Sun Nov  7 00:40:00 2010 -0400 EDT
Sun Nov  7 01:00:00 2010 -0400 EDT
Sun Nov  7 01:20:00 2010 -0400 EDT
Sun Nov  7 01:40:00 2010 -0400 EDT
Sun Nov  7 01:00:00 2010 -0500 EST
Sun Nov  7 01:20:00 2010 -0500 EST

However, neither Local nor Eastern tzinfo instance is capable of reproducing this sequence:


>>> for i in range(-3600, 5000, 1200):
...   print(datetime.fromtimestamp(s + i, Eastern).strftime('%c %z %Z'))

Sun Nov  7 00:00:00 2010 -0400 EDT
Sun Nov  7 00:20:00 2010 -0400 EDT
Sun Nov  7 00:40:00 2010 -0400 EDT
Sun Nov  7 01:00:00 2010 -0500 EST
Sun Nov  7 01:20:00 2010 -0500 EST
Sun Nov  7 01:40:00 2010 -0500 EST
Sun Nov  7 01:00:00 2010 -0500 EST
Sun Nov  7 01:20:00 2010 -0500 EST

>>> for i in range(-3600, 5000, 1200):
...   print(datetime.fromtimestamp(s + i, Local).strftime('%c %z %Z'))
 
Sun Nov  7 00:00:00 2010 -0400 EDT
Sun Nov  7 00:20:00 2010 -0400 EDT
Sun Nov  7 00:40:00 2010 -0400 EDT
Sun Nov  7 01:00:00 2010 -0400 EDT
Sun Nov  7 01:20:00 2010 -0400 EDT
Sun Nov  7 01:40:00 2010 -0400 EDT
Sun Nov  7 02:00:00 2010 -0500 EST
Sun Nov  7 02:20:00 2010 -0500 EST

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9063>
_______________________________________

From report at bugs.python.org  Wed Jun 23 20:38:59 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 23 Jun 2010 18:38:59 +0000
Subject: [issue9048] no OS X buildbots in the stable list
In-Reply-To: <1277316188.56.0.592798281077.issue9048@psf.upfronthosting.co.za>
Message-ID: <4C2254C0.7010607@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Bit of a chicken/egg issue here.  Since we haven't had OS X buildbots
> for very long, and the ones we do have represent odd configurations,
> I think it's premature to say that "the port *doesn't* pass the test
> suite on a regular manner".

And I didn't mean that literally. Rather, I meant "the build slave that 
you are proposing to add to the stable list don't pass the test suite on 
a regular manner" - it's ultimately the individual slave (OS, compiler 
installation, buildbot version, network connectivity) that can be 
questioned for stability.

So that's not really a chicken-and-egg problem. If people keep working 
on the OSX port, they might ultimately arrive in a state where even the 
odd configurations become stable.

> I think it's just as reasonable to say
> that the developers making changes just aren't aware of bad
> side-effects on OS X.  A good way to remedy that would be to make
> those bad side-effects more apparent, for example by adding an OS X
> buildbot into the "stable" set.

I am not convinced that this is a good way. First, they are all 
volunteers, so they chose to do whatever they like to do. Then, even if 
they *are* willing to fix OSX problems, they might never look at the 
buildbot results. So any estimation of the effect that the proposed 
change might have is pure guessing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9048>
_______________________________________

From report at bugs.python.org  Wed Jun 23 20:40:54 2010
From: report at bugs.python.org (Kamil Kisiel)
Date: Wed, 23 Jun 2010 18:40:54 +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: <1277318454.07.0.0417233895391.issue7951@psf.upfronthosting.co.za>


Kamil Kisiel <kisielk at users.sourceforge.net> added the comment:

While I agree this functionality isn't strictly necessary I think it makes sense from a semantic point of view. I ran in to this issue today while writing some code and I simply expected the negative syntax to work, given that the format string syntax otherwise very closely resembles standard array and attribute access.

It would be nice to see this make it in eventually for consistency's sake.

----------
nosy: +kisielk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Wed Jun 23 20:41:40 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 23 Jun 2010 18:41:40 +0000
Subject: [issue9061] cgi.escape Can Lead To XSS Vulnerabilities
In-Reply-To: <1277307995.11.0.923855376948.issue9061@psf.upfronthosting.co.za>
Message-ID: <20100623184129.GB2645@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Wed, Jun 23, 2010 at 03:46:35PM +0000, Craig Younkins wrote:
> cgi.escape never escapes single quote characters, which can easily
> lead to a Cross-Site Scripting (XSS) vulnerability. This seems to be
> known by many, but a quick search reveals many are using cgi.escape
> for HTML attribute escaping.

cgi.escape is for HTML attribute escaping only.  I guess, you should
explain or point out to resources where 'single quotes' representation
in a non-entity format in a HTML page has lead to XSS.

> The intended use of this method is unclear to me. 

Escape HTML characters (most commonly), >,<, & and ". And mostly when
constructing responses where these characters are literally required.

> While the documentation says "if the value to be quoted might
> include single- or double-quote characters... [use the]
> xml.sax.saxutils module instead," it also implies that this method
> will make input safe for HTML. Because this method escapes 4 of the

"More suitable" for HTML would be the correct interpretation rather
make the "input safe". You might check the reference documentation
leading to xml.sax.saxutils.

> I suggest rewording the documentation for the method making it more
> clear what it should and should not be used for. 

The very next paragraph seems to address the security considerations
while using the cgi module itself, rather than limiting it to
cgi.escape. It says that:

"To be on the safe side, if you must pass a string gotten from a form
to a shell command, you should make sure the string contains only
alphanumeric characters, dashes, underscores, and periods."

With respect your bug report:

1. Any doc change suggestions you propose?  (After pointing out the
resources requested in first para)

2. If cgi.escape needs to escape single quotes, what should it be as:
lsquo/rsquo (for XHTML) and &#x27; or &#39; for Others?

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9061>
_______________________________________

From report at bugs.python.org  Wed Jun 23 20:43:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Jun 2010 18:43:25 +0000
Subject: [issue9048] no OS X buildbots in the stable list
In-Reply-To: <1277148342.98.0.18086046529.issue9048@psf.upfronthosting.co.za>
Message-ID: <1277318605.83.0.488620231818.issue9048@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh -None

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9048>
_______________________________________

From report at bugs.python.org  Wed Jun 23 20:58:53 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 23 Jun 2010 18:58:53 +0000
Subject: [issue8930] messed up formatting after reindenting
In-Reply-To: <1275862117.51.0.974367285734.issue8930@psf.upfronthosting.co.za>
Message-ID: <1277319533.62.0.749410537105.issue8930@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Antoine, thanks. ceval.c fixes committed in r82177, r82179, r82181
and r82182.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8930>
_______________________________________

From report at bugs.python.org  Wed Jun 23 21:06:01 2010
From: report at bugs.python.org (Craig Younkins)
Date: Wed, 23 Jun 2010 19:06:01 +0000
Subject: [issue9061] cgi.escape Can Lead To XSS Vulnerabilities
In-Reply-To: <1277307995.11.0.923855376948.issue9061@psf.upfronthosting.co.za>
Message-ID: <1277319961.03.0.841710792659.issue9061@psf.upfronthosting.co.za>


Craig Younkins <cyounkins at gmail.com> added the comment:

> cgi.escape is for HTML attribute escaping only.

It is not safe for HTML attribute escaping because it does not encode single quotes.

> "More suitable" for HTML would be the correct interpretation rather make the "input safe".

"More suitable, but not quite secure"

Regardless of the intended use of this method, many many people are using it for insecure HTML entity escaping.

> you should explain or point out to resources where 
> 'single quotes' representation in a non-entity format 
> in a HTML page has lead to XSS.

print "<body class='%s'></body>" % cgi.escape("' onload='alert(1);' bad='")

> The very next paragraph seems to address the security considerations
> while using the cgi module itself, rather than limiting it to
> cgi.escape. It says that:
> "To be on the safe side, if you must pass a string gotten from a form
> to a shell command, you should make sure the string contains only
> alphanumeric characters, dashes, underscores, and periods."

The security concerns related to output on the web are very different from the concerns related sending user input to a shell command. The needed escaping is completely different. Also, the security advice above is woefully inadequate. 

> Any doc change suggestions you propose?

Convert the characters '&', '<' and '>' in string s to their HTML entity encoded values. If the optional flag quote is true, the double-quotation mark character ('"') is also encoded. Note that the output of this method is not safe to put in an HTML attribute because it does not escape single quotes. If the value to be quoted might include single- or double-quote characters, or both, consider using the quoteattr() function in the xml.sax.saxutils module instead.

> If cgi.escape needs to escape single quotes, what should it be as:
> lsquo/rsquo (for XHTML) and &#x27; or &#39; for Others?

Sorry, I should have included that in the OP. It should escape to &#x27; 
It is also advised to escape the forward slash character ('/') to &#x2F;

See OWASP.org for an explanation of the complexities of the escaping:
http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9061>
_______________________________________

From report at bugs.python.org  Wed Jun 23 21:21:26 2010
From: report at bugs.python.org (Andrew Valencia)
Date: Wed, 23 Jun 2010 19:21:26 +0000
Subject: [issue9064] pdb enhancement up/down traversals
In-Reply-To: <1277320886.89.0.906554449905.issue9064@psf.upfronthosting.co.za>
Message-ID: <1277320886.89.0.906554449905.issue9064@psf.upfronthosting.co.za>


New submission from Andrew Valencia <ajv-611-065-2175 at vsta.org>:

In very deep stack traces (like runaway recursion) it can be a pain to get up to the top of the stack to see what kicked it off.  I've enhanced up/down to take a numeric argument for the number of positions to traverse, or -1 to go to the top/bottom.  Sample patch included.

----------
components: Demos and Tools
files: pdb_up.pat
messages: 108476
nosy: vandyswa
priority: normal
severity: normal
status: open
title: pdb enhancement up/down traversals
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file17754/pdb_up.pat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9064>
_______________________________________

From report at bugs.python.org  Wed Jun 23 21:23:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Jun 2010 19:23:30 +0000
Subject: [issue8999] Add Mercurial support to patchcheck
In-Reply-To: <1277312752.79.0.928814447954.issue8999@psf.upfronthosting.co.za>
Message-ID: <1277321003.3202.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> As for Hg support, enough people seem to run mq on top of svn to make
> this a reasonable thing to add now and to change once the transition
> occurs.

Yes, but the question is what workflow it should assume. If you are
running mq for example (or pbranch, or doing local named branches),
using a simple "hg status" of the working copy will not do the right
thing.

(and, by the way, you can't assume mq is the favourite workflow out of
there: I for example use clones + local named branches instead)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8999>
_______________________________________

From report at bugs.python.org  Wed Jun 23 21:26:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Jun 2010 19:26:22 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1277316082.09.0.450786899993.issue9025@psf.upfronthosting.co.za>
Message-ID: <1277321179.3202.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Some considerations for the PRNG are:
> * equidistribution (for quality)
> * repeatability from the same seed (even in multithreaded environments)

I believe a reasonable (com)promise would be to guarantee repeatability
accross a given set of bugfix releases (for example, accross all 2.6.x
releases). We shouldn't necessarily commit to repeatability accross
feature releases, especially if it conflicts with desireable
opportunities for improvement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Wed Jun 23 21:26:26 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 23 Jun 2010 19:26:26 +0000
Subject: [issue1004] MultiMethods with type annotations in 3000
In-Reply-To: <1187905288.26.0.195051257185.issue1004@psf.upfronthosting.co.za>
Message-ID: <1277321186.53.0.550177383804.issue1004@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Let's close for now.

----------
nosy: +benjamin.peterson
resolution:  -> postponed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1004>
_______________________________________

From report at bugs.python.org  Wed Jun 23 21:27:47 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 23 Jun 2010 19:27:47 +0000
Subject: [issue8999] Add Mercurial support to patchcheck
In-Reply-To: <1276593572.4.0.720668123002.issue8999@psf.upfronthosting.co.za>
Message-ID: <1277321267.9.0.292937763308.issue8999@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Good point, Antoine. Then I might leave this patch for now and come back to it when we do the Hg transition.

----------
assignee: brett.cannon -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8999>
_______________________________________

From report at bugs.python.org  Wed Jun 23 21:37:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 23 Jun 2010 19:37:55 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1277321875.89.0.663018502243.issue9025@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> * possibly providing a C version of rnd2()

If recoding in C is acceptable, I think there may be better ( = simpler and faster) ways than doing a direct translation of rnd2.

For example, for small k, the following algorithm for randrange(k) suffices:

 - take a single 32-bit deviate (generated using genrand_int32)
 - multiply by k (a 32-by-32 to 64-bit widening multiply) and return
   the high 32-bits of the result, provided that the bottom half
   of the product is <= 2**32 - k (almost always true, for small k).
 - consume extra random words as necessary in the case that the bottom
   half of the product is > 2**32 - k.

I can provide code (with that 3rd step fully expanded) if you're interested in this approach.

This is likely to be significantly faster than a direct translation of rnd32, since in the common case it requires only: one 32-bit deviate from MT, one integer multiplication, one subtraction, and one comparison.  By comparison, rnd2 uses (at least) two 32-bit deviates and massages them into a float, before doing arithmetic with that float.

Though it's possible (even probable) that any speed gain would be insignificant in comparison to the rest of the Python machinery involved in a single randrange call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Wed Jun 23 21:41:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 23 Jun 2010 19:41:23 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1277322083.6.0.783637056793.issue7900@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't know how relevant this is to OS X, but on FreeBSD 6.3, kern.ngroups (maximum number of groups a uid may belong to) defaults to 16.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Wed Jun 23 22:07:43 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 23 Jun 2010 20:07:43 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1277322083.6.0.783637056793.issue7900@psf.upfronthosting.co.za>
Message-ID: <4C22698C.6090709@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I don't know how relevant this is to OS X, but on FreeBSD 6.3,
> kern.ngroups (maximum number of groups a uid may belong to) defaults
> to 16.

It probably is: "sysctl kern.ngroups" also gives 16 on OSX 10.6.4
(Darwin 10.4.0).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Wed Jun 23 22:21:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 23 Jun 2010 20:21:24 +0000
Subject: [issue9048] no OS X buildbots in the stable list
In-Reply-To: <1277148342.98.0.18086046529.issue9048@psf.upfronthosting.co.za>
Message-ID: <1277324484.62.0.897867042283.issue9048@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Data point: on #python-dev we get announcements when buildbots (any buildbots, not just stable ones) *change state*.  That is, when a buildbot that was passing fails, or a buildbot that was failing passes.  We do look at the failures, though not all the time (if no one is around or it is one of that flaky buildbots that change state often they won't get checked or will get checked only randomly).

So, from the #python-dev perspective, the OS X buildbots will only be useful once they start being normally green.  Then we'll notice when they go red and, if we can, fix it, or open an issue.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9048>
_______________________________________

From report at bugs.python.org  Wed Jun 23 22:28:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Jun 2010 20:28:16 +0000
Subject: [issue9048] no OS X buildbots in the stable list
In-Reply-To: <1277148342.98.0.18086046529.issue9048@psf.upfronthosting.co.za>
Message-ID: <1277324896.62.0.211425636126.issue9048@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I think it's just as reasonable to say that the developers making
> changes just aren't aware of bad side-effects on OS X.  A good way to
> remedy that would be to make those bad side-effects more apparent, for 
> example by adding an OS X buildbot into the "stable" set.

I can't speak for other developers, but I generally look into the "unstable" set when I fear one of my changes might break something (and, sure enough, some of the SSL changes I did had to be adapted so that test_ssl pass again on the OS X buildots).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9048>
_______________________________________

From report at bugs.python.org  Wed Jun 23 22:39:08 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 23 Jun 2010 20:39:08 +0000
Subject: [issue9048] no OS X buildbots in the stable list
In-Reply-To: <1277148342.98.0.18086046529.issue9048@psf.upfronthosting.co.za>
Message-ID: <1277325548.87.0.198934660755.issue9048@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Martin: sorry about my first question. My interpretation of your first message was that you thought that the OSX port itself wasn't stable, and you've already mentioned that you didn't mean to imply that.

I'm unassigning the issue from my as I won't be able to actually move the osx buildbots in the stable list, at least not beyond trying to get the OSX port rock solid.

Is is possible to get e-mail about changes of buildbot status? I'd be interested in two sets of mail: any buildbot failures caused by my checkins and state changes for the OSX buildbots.

BTW. None of the buildbots currently test the configuration that is used for release builds: a 2-way or 3-way universal framework build.

----------
assignee: ronaldoussoren -> nobody
nosy: +nobody

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9048>
_______________________________________

From report at bugs.python.org  Wed Jun 23 22:43:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 23 Jun 2010 20:43:55 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1277325835.44.0.61947346913.issue9025@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Just to illustrate, here's a patch that adds a method Random._smallrandbelow, based on the algorithm I described above.

----------
Added file: http://bugs.python.org/file17755/_smallrandbelow.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Wed Jun 23 23:23:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Jun 2010 21:23:45 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1277216836.46.0.599833830018.issue9020@psf.upfronthosting.co.za>
Message-ID: <1277328220.3202.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I checked every usage of Py_IS* in the tree and this is an isolated
> case. So I think it's better to do the check explicitly and add a
> comment to the Py_IS* macros.
> 
> 
> Does the patch look good?

Nice. I suppose Py_CHARMASK still needs fixing for the general case,
though).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Wed Jun 23 23:41:07 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 23 Jun 2010 21:41:07 +0000
Subject: [issue9048] no OS X buildbots in the stable list
In-Reply-To: <1277325548.87.0.198934660755.issue9048@psf.upfronthosting.co.za>
Message-ID: <4C227F70.1090005@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Is is possible to get e-mail about changes of buildbot status? I'd be
> interested in two sets of mail: any buildbot failures caused by my
> checkins and state changes for the OSX buildbots.

Buildbot failure reports are sent to python-checkins. In theory, at 
least; I think that isn't working very well.

Sending them to individual developers might be tricky. IOW, don't expect 
to see this happen within the next months unless somebody else 
volunteers to look into the buildbot configuration.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9048>
_______________________________________

From report at bugs.python.org  Wed Jun 23 23:46:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Jun 2010 21:46:17 +0000
Subject: [issue9048] no OS X buildbots in the stable list
In-Reply-To: <4C227F70.1090005@v.loewis.de>
Message-ID: <1277329572.3202.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Buildbot failure reports are sent to python-checkins. In theory, at 
> least; I think that isn't working very well.

ISTR we disabled them because there was too much churn from both
unreliable buildbots and unreliable tests, which made the noise annoying
and useless (everyone was ignoring failure notifications, I think).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9048>
_______________________________________

From report at bugs.python.org  Wed Jun 23 23:52:06 2010
From: report at bugs.python.org (David Kirkby)
Date: Wed, 23 Jun 2010 21:52:06 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1277329926.23.0.357438538044.issue8852@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Has anyone done anything about fixing this issue? The patch I attached appears to allow _socket to build on OpenSolaris and when I run the test suite, there is no failure of _socket. 

I've just downloaded the latest source code for the 3.1.2, 2.6.5 and Python-2.7rc2. All three have this problems, so it needs fixing. 

As far as I can ascertain, the patch socketmodule.c.patch solves it. 

Dave

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Thu Jun 24 00:20:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Jun 2010 22:20:34 +0000
Subject: [issue9051] Cannot pickle timezone instances
In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za>
Message-ID: <1277331634.4.0.700856242916.issue9051@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r82184.  Leaving the issue open pending a more thorough review of pickling in datetime module.

----------
keywords:  -easy, patch
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9051>
_______________________________________

From report at bugs.python.org  Thu Jun 24 00:27:37 2010
From: report at bugs.python.org (Justin Bronder)
Date: Wed, 23 Jun 2010 22:27:37 +0000
Subject: [issue9065] tarfile:  default root:root ownership is incorrect.
In-Reply-To: <1277332057.13.0.313961006951.issue9065@psf.upfronthosting.co.za>
Message-ID: <1277332057.13.0.313961006951.issue9065@psf.upfronthosting.co.za>


New submission from Justin Bronder <jsbronder at gentoo.org>:

According to the tar spec [1], uname/gname should only be filled
when they have successfully been resolved from the uid/gid.  The
tarfile module incorrectly defaults to root:root in this case.

A patch against svn trunk r82183 is included.  All tarfile unit
tests still pass with this patch.  I did not include a new unit
test as chown() is required.

Example using tarfile:
$ ls -l tarfile_user
-rw-r--r-- 1 65533 jbronder 0 2010-06-23 17:44 tarfile_user
$ python -c "import tarfile;a = tarfile.open('bleh.tar', 'w:');a.add('tarfile_user');a.list()"
-rw-r--r-- root/jbronder          0 2010-06-23 17:44:55 tarfile_user

Example using GNU tarball:
$ tar -cf bleh.tar tarfile_user
$ python -c "import tarfile;a = tarfile.open('bleh.tar').list()"
-rw-r--r-- 65533/jbronder          0 2010-06-23 17:44:55 tarfile_user

1. http://www.gnu.org/software/tar/manual/tar.html#SEC170

----------
files: python-2.7-tarfile-uid-gid.patch
keywords: patch
messages: 108493
nosy: jsbronder
priority: normal
severity: normal
status: open
title: tarfile:  default root:root ownership is incorrect.
versions: Python 2.5, Python 2.7
Added file: http://bugs.python.org/file17756/python-2.7-tarfile-uid-gid.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9065>
_______________________________________

From report at bugs.python.org  Thu Jun 24 00:31:42 2010
From: report at bugs.python.org (Justin Bronder)
Date: Wed, 23 Jun 2010 22:31:42 +0000
Subject: [issue9065] tarfile:  default root:root ownership is incorrect.
In-Reply-To: <1277332057.13.0.313961006951.issue9065@psf.upfronthosting.co.za>
Message-ID: <1277332302.56.0.551369804293.issue9065@psf.upfronthosting.co.za>


Changes by Justin Bronder <jsbronder at gentoo.org>:


----------
components: +Library (Lib)
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9065>
_______________________________________

From report at bugs.python.org  Thu Jun 24 01:01:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 23 Jun 2010 23:01:05 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1277329926.23.0.357438538044.issue8852@psf.upfronthosting.co.za>
Message-ID: <4C22922E.7010302@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Has anyone done anything about fixing this issue?

AFAICT, nobody did.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Thu Jun 24 01:37:01 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Jun 2010 23:37:01 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1277336221.04.0.0873723559089.issue9025@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Antoine, there does need to be repeatablity; there's no question about that.  The open question for me is how to offer that repeatability in the cleanest manner.

People use random.seed() for reproducible tests.  They need it to have their studies become independently validatable, etc.  Some people are pickling the state of the RNG and need to restart where they left off, etc.

Mark, thanks for the alternative formulation.  I'll take a look when I get a chance.

I've got it from here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Thu Jun 24 01:49:21 2010
From: report at bugs.python.org (David Kirkby)
Date: Wed, 23 Jun 2010 23:49:21 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1277336961.26.0.545883346374.issue8852@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Is there anything I can do to get someone to do something about it? I would have thought with a patch, it would not be hard for someone to fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Thu Jun 24 03:13:19 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 24 Jun 2010 01:13:19 +0000
Subject: [issue8413] String interpolation doesn't work with sys.version_info
In-Reply-To: <1271381290.83.0.815567007844.issue8413@psf.upfronthosting.co.za>
Message-ID: <1277341999.47.0.683457942718.issue8413@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Should this regression block final release of 2.7 or can it be fixed in e.g. 2.7.1?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8413>
_______________________________________

From report at bugs.python.org  Thu Jun 24 03:41:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jun 2010 01:41:34 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1277343694.45.0.410156973012.issue9025@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

randint.py: another algorithm to generate a random integer in a range. It uses only operations on unsigned integers (no evil floatting point number). It calls tick() multiple times to generate enough entropy. It has an uniform distribution (if the input generator has an uniform distribution).

tick() is simply the output of the Mersenne Twister generator. The algorithm can be optimized (especially the part computing ndigits and scale).

----------
Added file: http://bugs.python.org/file17757/randint.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Thu Jun 24 04:35:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Jun 2010 02:35:30 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1277336221.04.0.0873723559089.issue9025@psf.upfronthosting.co.za>
Message-ID: <1277346924.3097.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, there does need to be repeatablity; there's no question about
> that.

Well, that doesn't address my proposal of making it repeatable accross
bugfix releases only. There doesn't seem to be a strong use case for
perpetual repeatability.

If some people really need perpetual repeatability, I don't understand
how they can rely on Python anyway, since we don't make any such promise
explicitly (or do they somehow manage to read in your mind?). So,
realistically, they should already be using their custom-written
deterministic generators.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Thu Jun 24 06:46:53 2010
From: report at bugs.python.org (Craig McQueen)
Date: Thu, 24 Jun 2010 04:46:53 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1277354813.34.0.11361071316.issue1172711@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

So it looks as though this isn't going in to Python 2.7.

How about 3.x?

----------
nosy: +cmcqueen1975

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1172711>
_______________________________________

From report at bugs.python.org  Thu Jun 24 06:58:30 2010
From: report at bugs.python.org (Craig McQueen)
Date: Thu, 24 Jun 2010 04:58:30 +0000
Subject: [issue9066] Standard type codes for array.array, same as struct
In-Reply-To: <1277355510.37.0.62223618655.issue9066@psf.upfronthosting.co.za>
Message-ID: <1277355510.37.0.62223618655.issue9066@psf.upfronthosting.co.za>


New submission from Craig McQueen <python at craig.mcqueen.id.au>:

The type codes for array.array are platform-dependent.

The type codes are similar to those for the struct module. It would be helpful for array.array to adopt the struct module's "=" format specifier prefix, to specify "standard" sizes. E.g.

    array_object = array.array("=L")  # 4-byte elements on all platforms

----------
components: Library (Lib)
messages: 108501
nosy: cmcqueen1975
priority: normal
severity: normal
status: open
title: Standard type codes for array.array, same as struct
type: feature request
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9066>
_______________________________________

From report at bugs.python.org  Thu Jun 24 07:13:00 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 24 Jun 2010 05:13:00 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1277336961.26.0.545883346374.issue8852@psf.upfronthosting.co.za>
Message-ID: <4C22E958.5030109@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Is there anything I can do to get someone to do something about it? I
> would have thought with a patch, it would not be hard for someone to
> fix.

Sure. Unfortunately, the day has only 24 hours.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Thu Jun 24 09:19:31 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 24 Jun 2010 07:19:31 +0000
Subject: [issue9065] tarfile:  default root:root ownership is incorrect.
In-Reply-To: <1277332057.13.0.313961006951.issue9065@psf.upfronthosting.co.za>
Message-ID: <1277363971.92.0.303256984166.issue9065@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9065>
_______________________________________

From report at bugs.python.org  Thu Jun 24 09:46:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jun 2010 07:46:59 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1277365619.87.0.20974344517.issue9025@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Distribution with my algorithm:

...
from collections import Counter
print Counter(_randint(6755399441055744) % 3 for _ in xrange(100000000))

=> Counter({0L: 33342985, 2L: 33335781, 1L: 33321234})

Distribution: {0: 0.33342985000000003, 2: 0.33335780999999998, 1: 0.33321234}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From orsenthil at gmail.com  Wed Jun 23 18:59:55 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Wed, 23 Jun 2010 22:29:55 +0530
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1277303838.85.0.715677314178.issue9025@psf.upfronthosting.co.za>
References: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
	<1277303838.85.0.715677314178.issue9025@psf.upfronthosting.co.za>
Message-ID: <20100623165955.GA2645@remy>

I guess, Antoine wanted to point out this:

"Changed in version 2.3: MersenneTwister replaced Wichmann-Hill as the
default generator."

But as the paragraph points out Python did provide non default WichmanHill
class for generating repeatable sequences with older python.

My brief reading on this topic, does suggest that 'repeatability' is
an important requirement for any PRNG.

From orsenthil at gmail.com  Wed Jun 23 20:41:29 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Thu, 24 Jun 2010 00:11:29 +0530
Subject: [issue9061] cgi.escape Can Lead To XSS Vulnerabilities
In-Reply-To: <1277307995.11.0.923855376948.issue9061@psf.upfronthosting.co.za>
References: <1277307995.11.0.923855376948.issue9061@psf.upfronthosting.co.za>
	<1277307995.11.0.923855376948.issue9061@psf.upfronthosting.co.za>
Message-ID: <20100623184129.GB2645@remy>

On Wed, Jun 23, 2010 at 03:46:35PM +0000, Craig Younkins wrote:
> cgi.escape never escapes single quote characters, which can easily
> lead to a Cross-Site Scripting (XSS) vulnerability. This seems to be
> known by many, but a quick search reveals many are using cgi.escape
> for HTML attribute escaping.

cgi.escape is for HTML attribute escaping only.  I guess, you should
explain or point out to resources where 'single quotes' representation
in a non-entity format in a HTML page has lead to XSS.

> The intended use of this method is unclear to me. 

Escape HTML characters (most commonly), >,<, & and ". And mostly when
constructing responses where these characters are literally required.

> While the documentation says "if the value to be quoted might
> include single- or double-quote characters... [use the]
> xml.sax.saxutils module instead," it also implies that this method
> will make input safe for HTML. Because this method escapes 4 of the

"More suitable" for HTML would be the correct interpretation rather
make the "input safe". You might check the reference documentation
leading to xml.sax.saxutils.

> I suggest rewording the documentation for the method making it more
> clear what it should and should not be used for. 

The very next paragraph seems to address the security considerations
while using the cgi module itself, rather than limiting it to
cgi.escape. It says that:

"To be on the safe side, if you must pass a string gotten from a form
to a shell command, you should make sure the string contains only
alphanumeric characters, dashes, underscores, and periods."

With respect your bug report:

1. Any doc change suggestions you propose?  (After pointing out the
resources requested in first para)

2. If cgi.escape needs to escape single quotes, what should it be as:
lsquo/rsquo (for XHTML) and &#x27; or &#39; for Others?


From report at bugs.python.org  Thu Jun 24 11:33:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Jun 2010 09:33:41 +0000
Subject: [issue9025] Non-uniformity in randrange for large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1277372021.59.0.780183421966.issue9025@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

A couple of points:

(1) In addition to documenting the extent of the repeatability, it would be good to have tests to prevent changes that inadvertently change the sequence of randrange values.

(2) For large arguments, cross-platform reproducibility is already a bit fragile.  For example, the _randbelow function depends on the system _log function---see the line

    k = int(1.00001 + _log(n-1, 2.0))

Now that we have the bit_length method available, it might be better to use that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9025>
_______________________________________

From report at bugs.python.org  Thu Jun 24 12:40:09 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Thu, 24 Jun 2010 10:40:09 +0000
Subject: [issue1685453] email package should work better with unicode
Message-ID: <1277376009.08.0.65905433359.issue1685453@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1685453>
_______________________________________

From report at bugs.python.org  Thu Jun 24 12:46:41 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 24 Jun 2010 10:46:41 +0000
Subject: [issue9067] Use macros from pyctype.h
In-Reply-To: <1277376401.69.0.151009302074.issue9067@psf.upfronthosting.co.za>
Message-ID: <1277376401.69.0.151009302074.issue9067@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

While investigating issue 9020, I noticed that there are several places
where the pyctype.h macros could/should be used.

----------
messages: 108505
nosy: eric.smith, skrah
priority: normal
severity: normal
status: open
title: Use macros from pyctype.h
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9067>
_______________________________________

From report at bugs.python.org  Thu Jun 24 13:04:14 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 24 Jun 2010 11:04:14 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>
Message-ID: <1277377454.03.0.564867861929.issue9020@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Committed fix in r82191. Thanks Sridhar for tracking this down.


New issues emerging from this one:

  1) Simplify Py_CHARMASK: issue 9036

  2) Use macros from pyctype.h: issue 9067



Additionally, I noticed that the macros is_potential_identifier* from
py3k/Parser/tokenizer.c assume a contiguous mapping for A-Z, a-z. Is
it ok in Python to assume this (in C it isn't)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Thu Jun 24 13:46:44 2010
From: report at bugs.python.org (Haoyu Bai)
Date: Thu, 24 Jun 2010 11:46:44 +0000
Subject: [issue9068] "from . import *"
In-Reply-To: <1277380004.45.0.44974456995.issue9068@psf.upfronthosting.co.za>
Message-ID: <1277380004.45.0.44974456995.issue9068@psf.upfronthosting.co.za>


New submission from Haoyu Bai <divinekid at gmail.com>:

"from . import *" is valid syntax in CPython (both 2.6 and py3k) but in the language reference it is not allowed:

http://docs.python.org/dev/py3k/reference/simple_stmts.html#the-import-statement

----------
components: Interpreter Core
messages: 108507
nosy: bhy
priority: normal
severity: normal
status: open
title: "from . import *"
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9068>
_______________________________________

From report at bugs.python.org  Thu Jun 24 14:21:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Jun 2010 12:21:09 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1277382069.11.0.60118264981.issue1172711@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Seems like a reasonable addition to me.  Anyone feel like refreshing the patch so that it applies to py3k?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1172711>
_______________________________________

From report at bugs.python.org  Thu Jun 24 14:25:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Jun 2010 12:25:37 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1277382337.94.0.391975117299.issue1172711@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

BTW, the PyLong_AsUnsignedLongLong BadInternalCall has long since disappeared.  I agree with Armin Rigo that the conversion functions in longobject.c are a mess, though (and also that cleanup is difficult).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1172711>
_______________________________________

From report at bugs.python.org  Thu Jun 24 14:44:46 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 24 Jun 2010 12:44:46 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1277383486.76.0.864712310284.issue1172711@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1172711>
_______________________________________

From report at bugs.python.org  Thu Jun 24 14:55:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Jun 2010 12:55:17 +0000
Subject: [issue9066] Standard type codes for array.array, same as struct
In-Reply-To: <1277355510.37.0.62223618655.issue9066@psf.upfronthosting.co.za>
Message-ID: <1277384117.3.0.0671227920308.issue9066@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I agree that it might be useful to have some way of specifying fixed-width integers.  It's not clear to me that importing specifier prefixes from the struct module is the best way to go about this, though.

----------
nosy: +mark.dickinson
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9066>
_______________________________________

From report at bugs.python.org  Thu Jun 24 14:59:39 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Jun 2010 12:59:39 +0000
Subject: [issue9064] pdb enhancement up/down traversals
In-Reply-To: <1277320886.89.0.906554449905.issue9064@psf.upfronthosting.co.za>
Message-ID: <1277384379.89.0.964156318433.issue9064@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is a good idea, but tab characters are disallowed in core python code; please replace them with spaces.
Then, please provide an "unified" diff patch (with "diff -u"), and name it with the ".patch" extension, this will make it easier to read.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9064>
_______________________________________

From report at bugs.python.org  Thu Jun 24 16:34:44 2010
From: report at bugs.python.org (Andrew Valencia)
Date: Thu, 24 Jun 2010 14:34:44 +0000
Subject: [issue9064] pdb enhancement up/down traversals
In-Reply-To: <1277320886.89.0.906554449905.issue9064@psf.upfronthosting.co.za>
Message-ID: <1277390084.14.0.889846036423.issue9064@psf.upfronthosting.co.za>


Andrew Valencia <ajv-611-065-2175 at vsta.org> added the comment:

Here's the patch, hopefully updated as requested.  Thanks!

----------
keywords: +patch
Added file: http://bugs.python.org/file17758/pdb_up.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9064>
_______________________________________

From report at bugs.python.org  Thu Jun 24 16:47:34 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 24 Jun 2010 14:47:34 +0000
Subject: [issue9036] Simplify Py_CHARMASK
In-Reply-To: <1277040424.45.0.292669416337.issue9036@psf.upfronthosting.co.za>
Message-ID: <20100624144713.GA1188@yoda.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Antoine Pitrou <report at bugs.python.org> wrote:
> > Thus,
> > ((unsigned char)((c) & 0xff)) and ((unsigned char)(c)) should produce
> > the same results.
> 
> If it's the case, it's probably optimized away by the compiler anyway.

Yes, the asm output is the same. I was more concerned about readability.

Historically, Py_CHARMASK started as ((c) & 0xff), hence the name. In r34974
UCHAR_MAX = 2**CHAR_BIT-1 = 255 was enforced. In r61936 the cast was added.

> > There is no reason not to do the cast when __CHAR_UNSIGNED__ is
> > defined (it will be a no-op).
> 
> Agreed. It also reduces the opportunity for bugs :)

Ok, let's say we use ((unsigned char)((c) & 0xff)) also for __CHAR_UNSIGNED__.

What should the comment say about the intended argument? I've examined all
occurrences in the tree and almost always Py_CHARMASK is used with either
char arguments or int arguments that are directly derived from a char, so
no EOF issues arise.

Exceptions:
===========

Index: Objects/unicodeobject.c
===================================================================
--- Objects/unicodeobject.c     (revision 82192)
+++ Objects/unicodeobject.c     (working copy)
@@ -8417,6 +8417,7 @@
                 else if (c >= '0' && c <= '9') {
                     prec = c - '0';
                     while (--fmtcnt >= 0) {
+                        /* XXX: c and *fmt are Py_UNICODE */
                         c = Py_CHARMASK(*fmt++);
                         if (c < '0' || c > '9')
                             break;

Index: Modules/_json.c
===================================================================
--- Modules/_json.c     (revision 82192)
+++ Modules/_json.c     (working copy)
@@ -603,6 +603,7 @@
             }
         }
         else {
+            /* XXX: c is Py_UNICODE */
             char c_char = Py_CHARMASK(c);
             chunk = PyString_FromStringAndSize(&c_char, 1);
             if (chunk == NULL) {

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9036>
_______________________________________

From report at bugs.python.org  Thu Jun 24 16:53:23 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 24 Jun 2010 14:53:23 +0000
Subject: [issue9036] Simplify Py_CHARMASK
In-Reply-To: <1277039528.15.0.539020018856.issue9036@psf.upfronthosting.co.za>
Message-ID: <1277391203.97.0.579299370084.issue9036@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

> In r61936 the cast was added.

Actually r61987

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9036>
_______________________________________

From report at bugs.python.org  Thu Jun 24 16:54:04 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Jun 2010 14:54:04 +0000
Subject: [issue9064] pdb enhancement up/down traversals
In-Reply-To: <1277320886.89.0.906554449905.issue9064@psf.upfronthosting.co.za>
Message-ID: <1277391244.15.0.661835409271.issue9064@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Two remarks:
- when int(arg) fails, an error message should be printed, like with the function do_commmands().
- the "for" loop seems unnecessary, something like "self.curindex -= nup" should be enough

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9064>
_______________________________________

From report at bugs.python.org  Thu Jun 24 17:02:23 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Jun 2010 15:02:23 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1277391743.4.0.915499856395.issue9009@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Another issue to consider, brought to my attention by Rick Regan:  

Python's dtoa.c code likely misbehaves (i.e., returns incorrectly rounded results) if the FPU rounding mode is anything other than the round-half-to-even default.  (This is also true of Gay's original dtoa.c, I suspect.)  For example, the quick-return path in strtod does a single floating-point operation on exact arguments, so will end up behaving according to the FPU rounding mode.  The long integer-arithmetic-based path will likely return round-half-to-even results, independently of the FPU rounding mode.

It's debatable what Python should do if the FPU rounding mode is something other than round-half-to-even.  It can either:

 - try to honour the FPU rounding mode, or
 - ignore the rounding mode completely, always doing round-half-to-even.

I'd prefer the latter behaviour, for various reasons:

 - it maintains consistency across platforms

 - it's consistent with many other Python operations, that already do round-half-to-even regardless of FPU rounding mode---examples include float.fromhex and float.hex, true division of integers, the round() function...

It seems possible that Python might one day want to be able to control the rounding direction of decimal <-> binary conversions, but when that day comes I don't think playing with the FPU rounding mode is going to be the best control mechanism.

I don't regard this as a terribly serious issue, though:  most normal users are unlikely to end up in a situation where the FPU rounding mode has changed unless they've been deliberately and knowingly messing with FPU settings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Thu Jun 24 17:06:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Jun 2010 15:06:11 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1277391971.91.0.639558007858.issue9009@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> - ignore the rounding mode completely, always doing round-half-to-even.
+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Thu Jun 24 17:12:24 2010
From: report at bugs.python.org (Martin Marcher)
Date: Thu, 24 Jun 2010 15:12:24 +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: <1277392344.37.0.0711432340437.issue5672@psf.upfronthosting.co.za>


Martin Marcher <martin at marcher.name> added the comment:

Hi,

just scanned the messages. As I read it "wontfix" actually means:

Ats some point in the future when the "setproctitle" project (http://code.google.com/p/py-setproctitle/source/list) has matured it will be reconsidered, correct?

Yes sorry for reopening this after quite some time (~6 months), just happened to pop up in my inbox due to the latest nosy list changes...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5672>
_______________________________________

From report at bugs.python.org  Thu Jun 24 17:15:57 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 24 Jun 2010 15:15:57 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1277391971.91.0.639558007858.issue9009@psf.upfronthosting.co.za>
Message-ID: <f76fd679d0f31be210a3aa7405b4e594.squirrel@mail.trueblade.com>


Eric Smith <eric at trueblade.com> added the comment:

>
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
>
>> - ignore the rounding mode completely, always doing round-half-to-even.
> +1

Agreed. +1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Thu Jun 24 17:19:41 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 24 Jun 2010 15:19:41 +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: <1277392781.2.0.902694725979.issue5672@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

If it has matured, has shown to be as a "best of breed" library of it's type, and has gone through the PEP process, it could make it. That takes quite a bit of time and isn't likely to occur within the next few years (3.3 at the earliest assuming the project matures quickly).

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5672>
_______________________________________

From report at bugs.python.org  Thu Jun 24 17:25:05 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Jun 2010 15:25:05 +0000
Subject: [issue9036] Simplify Py_CHARMASK
In-Reply-To: <20100624144713.GA1188@yoda.bytereef.org>
Message-ID: <4C2378CD.10805@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Stefan Krah wrote:
> 
> Stefan Krah <stefan-usenet at bytereef.org> added the comment:
> 
> Antoine Pitrou <report at bugs.python.org> wrote:
>>> Thus,
>>> ((unsigned char)((c) & 0xff)) and ((unsigned char)(c)) should produce
>>> the same results.
>>
>> If it's the case, it's probably optimized away by the compiler anyway.
> 
> Yes, the asm output is the same. I was more concerned about readability.
> 
> Historically, Py_CHARMASK started as ((c) & 0xff), hence the name. In r34974
> UCHAR_MAX = 2**CHAR_BIT-1 = 255 was enforced. In r61936 the cast was added.
> 
>>> There is no reason not to do the cast when __CHAR_UNSIGNED__ is
>>> defined (it will be a no-op).
>>
>> Agreed. It also reduces the opportunity for bugs :)
> 
> Ok, let's say we use ((unsigned char)((c) & 0xff)) also for __CHAR_UNSIGNED__.
> 
> What should the comment say about the intended argument? I've examined all
> occurrences in the tree and almost always Py_CHARMASK is used with either
> char arguments or int arguments that are directly derived from a char, so
> no EOF issues arise.

Why not just make the casts in those cases explicit instead of
using Py_CHARMASK ?

> Exceptions:
> ===========
> 
> Index: Objects/unicodeobject.c
> ===================================================================
> --- Objects/unicodeobject.c     (revision 82192)
> +++ Objects/unicodeobject.c     (working copy)
> @@ -8417,6 +8417,7 @@
>                  else if (c >= '0' && c <= '9') {
>                      prec = c - '0';
>                      while (--fmtcnt >= 0) {
> +                        /* XXX: c and *fmt are Py_UNICODE */
>                          c = Py_CHARMASK(*fmt++);

If both are Py_UNICODE, why do you need the cast at all ?

Note that the above use also appears to be wrong, since if *fmt
is Py_UNICODE, the following if() will also match if the higher
order bytes of the Py_UNICODE value are non-0.

>                          if (c < '0' || c > '9')
>                              break;
> 
> Index: Modules/_json.c
> ===================================================================
> --- Modules/_json.c     (revision 82192)
> +++ Modules/_json.c     (working copy)
> @@ -603,6 +603,7 @@
>              }
>          }
>          else {
> +            /* XXX: c is Py_UNICODE */
>              char c_char = Py_CHARMASK(c);

In this case you should get a compiler warning due to the
different signedness of the arguments.

Same comment as above: the high order bytes of c are lost
in this conversion.

Why can't _json.c use one of the existing Unicode conversion
APIs ?

>              chunk = PyString_FromStringAndSize(&c_char, 1);
>              if (chunk == NULL) {
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue9036>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/mal%40egenix.com

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9036>
_______________________________________

From report at bugs.python.org  Thu Jun 24 17:30:03 2010
From: report at bugs.python.org (Andrew Valencia)
Date: Thu, 24 Jun 2010 15:30:03 +0000
Subject: [issue9064] pdb enhancement up/down traversals
In-Reply-To: <1277320886.89.0.906554449905.issue9064@psf.upfronthosting.co.za>
Message-ID: <1277393403.73.0.292141298218.issue9064@psf.upfronthosting.co.za>


Andrew Valencia <ajv-611-065-2175 at vsta.org> added the comment:

Debugging tools which have bugs are a real pain... thanks for your comments and attention.  Here's another try.  With all the loop baggage gone the argument handling really called for factoring out.

----------
Added file: http://bugs.python.org/file17759/pdb_up2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9064>
_______________________________________

From report at bugs.python.org  Thu Jun 24 17:31:52 2010
From: report at bugs.python.org (Andrew Valencia)
Date: Thu, 24 Jun 2010 15:31:52 +0000
Subject: [issue9064] pdb enhancement up/down traversals
In-Reply-To: <1277320886.89.0.906554449905.issue9064@psf.upfronthosting.co.za>
Message-ID: <1277393512.57.0.138850856825.issue9064@psf.upfronthosting.co.za>


Andrew Valencia <ajv-611-065-2175 at vsta.org> added the comment:

My bad (new editor session lost the tab setting).  Please consider this one with no tabs instead.

----------
Added file: http://bugs.python.org/file17760/pdb_up3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9064>
_______________________________________

From report at bugs.python.org  Thu Jun 24 17:54:39 2010
From: report at bugs.python.org (Daniele Varrazzo)
Date: Thu, 24 Jun 2010 15:54:39 +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: <1277394879.49.0.402632825608.issue5672@psf.upfronthosting.co.za>


Daniele Varrazzo <piro at develer.com> added the comment:

setproctitle is quite stable, my company uses it in production environment very heavily with python 2.x. Probably its users base is not huge, but that's because it's a relatively specialized tool.

Python3 porting is not straightforward because python2 exports the original argv pointer using Py_GetArgcArgv() whereas python3 only exports a decoded version in a wchar_t* array. This may not be a showstopper: probably the original argv can still be found scanning backwards from environ: I want to test it but I haven't had requests for it yet, so it wasn't a top priority.

So, while I'd be pleased to have it included in the stdlib, I'm not really convinced it would be useful to such a large audience. Anyway I'm available for any improvement it would make the tool more useful and to anybody eager to push for its inclusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5672>
_______________________________________

From report at bugs.python.org  Thu Jun 24 18:05:25 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 24 Jun 2010 16:05:25 +0000
Subject: [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1277395525.55.0.115925045203.issue9009@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

+1, if the FPU mask is always restored (as I understand, this is the case
now).

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9009>
_______________________________________

From report at bugs.python.org  Thu Jun 24 18:09:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Jun 2010 16:09:12 +0000
Subject: [issue8682] _ssl.c uses PyWeakref_GetObject but doesn't incref result
In-Reply-To: <1273534331.53.0.523751841318.issue8682@psf.upfronthosting.co.za>
Message-ID: <1277395752.1.0.818578776676.issue8682@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch. Will commit soon if there's no remarks.

----------
keywords: +patch
nosy: +exarkun, giampaolo.rodola, janssen
Added file: http://bugs.python.org/file17761/sslweakref.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8682>
_______________________________________

From report at bugs.python.org  Thu Jun 24 18:19:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Jun 2010 16:19:25 +0000
Subject: [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1277377454.03.0.564867861929.issue9020@psf.upfronthosting.co.za>
Message-ID: <1277396361.3553.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Additionally, I noticed that the macros is_potential_identifier* from
> py3k/Parser/tokenizer.c assume a contiguous mapping for A-Z, a-z. Is
> it ok in Python to assume this (in C it isn't)?

I don't think we support writing Python source code in an encoding
that's not a superset of ASCII, so it should be fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9020>
_______________________________________

From report at bugs.python.org  Thu Jun 24 18:28:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Jun 2010 16:28:00 +0000
Subject: [issue9036] Simplify Py_CHARMASK
In-Reply-To: <1277039528.15.0.539020018856.issue9036@psf.upfronthosting.co.za>
Message-ID: <1277396880.64.0.967482715948.issue9036@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Ok, let's say we use ((unsigned char)((c) & 0xff)) also for
> __CHAR_UNSIGNED__.
> 
> What should the comment say about the intended argument?

That it's either in [-128; 127] or in [0; 255] ?

> Index: Objects/unicodeobject.c
> ===================================================================
> --- Objects/unicodeobject.c     (revision 82192)
> +++ Objects/unicodeobject.c     (working copy)
> @@ -8417,6 +8417,7 @@
>                  else if (c >= '0' && c <= '9') {
>                      prec = c - '0';
>                      while (--fmtcnt >= 0) {
> +                        /* XXX: c and *fmt are Py_UNICODE */
>                          c = Py_CHARMASK(*fmt++);

This is a funny bug:

>>> u"%.1\u1032f" % (1./3)
u'0.333333333333'

> Index: Modules/_json.c
> ===================================================================
> --- Modules/_json.c     (revision 82192)
> +++ Modules/_json.c     (working copy)
> @@ -603,6 +603,7 @@
>              }
>          }
>          else {
> +            /* XXX: c is Py_UNICODE */
>              char c_char = Py_CHARMASK(c);

This block can only be entered if c <= 0x7f (`has_unicode` is false), so it's not a problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9036>
_______________________________________

From report at bugs.python.org  Thu Jun 24 18:44:25 2010
From: report at bugs.python.org (=?utf-8?q?Marcelo_Fern=C3=A1ndez?=)
Date: Thu, 24 Jun 2010 16:44:25 +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: <1277397865.66.0.921141511365.issue5672@psf.upfronthosting.co.za>


Marcelo Fern?ndez <marcelo.fidel.fernandez at gmail.com> added the comment:

> So, while I'd be pleased to have it included in the stdlib, I'm not
> really convinced it would be useful to such a large audience.

I think different, if python becomes even more successful to be used in desktop apps, this feature will be *very* important, because the reasons I've exposed in this thread.

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5672>
_______________________________________

From report at bugs.python.org  Thu Jun 24 18:56:32 2010
From: report at bugs.python.org (David Kirkby)
Date: Thu, 24 Jun 2010 16:56:32 +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: <1277398592.88.0.0614841633864.issue8265@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

I'm seeing this failure on both Solaris 10 (SPARC processor) in 32-bit mode and OpenSolaris 06/2009 (Intel Xeon) in 64-bit mode using Python 2.6.4. So it is not just an ARM Linux issue. 

See 

http://trac.sagemath.org/sage_trac/ticket/9297
http://trac.sagemath.org/sage_trac/ticket/9299

Note, Solaris supports both a 32 and 64-bit ABI. Not  sure if that is relevant, but I see "ABI" in the title, so perhaps it might be. 

Dave

----------
nosy: +drkirkby

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8265>
_______________________________________

From report at bugs.python.org  Thu Jun 24 19:06:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Jun 2010 17:06:16 +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: <1277399176.85.0.487103084999.issue8265@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

David, thanks for the report.  This looks like a different issue to me, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8265>
_______________________________________

From report at bugs.python.org  Thu Jun 24 19:10:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Jun 2010 17:10:47 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Comment from David Kirkby in issue 8265;  moved here because it looks like a separate problem.

I'm seeing this failure on both Solaris 10 (SPARC processor) in 32-bit mode and OpenSolaris 06/2009 (Intel Xeon) in 64-bit mode using Python 2.6.4. So it is not just an ARM Linux issue. 

See 

http://trac.sagemath.org/sage_trac/ticket/9297
http://trac.sagemath.org/sage_trac/ticket/9299

Note, Solaris supports both a 32 and 64-bit ABI. Not  sure if that is relevant, but I see "ABI" in the title, so perhaps it might be.

----------
assignee: mark.dickinson
components: Extension Modules
messages: 108532
nosy: drkirkby, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: test_float failure on Solaris
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Thu Jun 24 19:11:42 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Jun 2010 17:11:42 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277399502.58.0.0595725574125.issue9069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

And the text of the failure (from the first link David provides):

test test_float failed -- Traceback (most recent call last):
  File "/export/home/drkirkby/sage-4.4.4.alpha1/spkg/build/python-2.6.4.p9/src/Lib/test/test_float.py", line 765, in test_roundtrip
    self.identical(-x, roundtrip(-x))
  File "/export/home/drkirkby/sage-4.4.4.alpha1/spkg/build/python-2.6.4.p9/src/Lib/test/test_float.py", line 375, in identical
    self.fail('%r not identical to %r' % (x, y))
AssertionError: -0.0 not identical to 0.0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Thu Jun 24 19:14:06 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Jun 2010 17:14:06 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277399646.61.0.870458917497.issue9069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

David, would it be possible for you to provide the results of:

>>> float.hex(-0.0)
>>> float.fromhex('-0x0.0p+0')

on those platforms, so that we can tell whether it's the float -> hex conversion or the hex -> float conversion that's losing the sign of the zero?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Thu Jun 24 19:14:52 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Jun 2010 17:14:52 +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: <1277399692.21.0.936997402665.issue8265@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

New issue for the Solaris failure opened:  issue 9069.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8265>
_______________________________________

From report at bugs.python.org  Thu Jun 24 20:02:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Jun 2010 18:02:07 +0000
Subject: [issue9070] Timestamps are rounded differently in py3k and trunk
In-Reply-To: <1277402527.75.0.74418180311.issue9070@psf.upfronthosting.co.za>
Message-ID: <1277402527.75.0.74418180311.issue9070@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

In the trunk:

>>> datetime.utcfromtimestamp(0.9999994)
datetime.datetime(1970, 1, 1, 0, 0, 1)

In py3k:

>>> datetime.utcfromtimestamp(0.9999994)
datetime.datetime(1970, 1, 1, 0, 0, 0, 999999)


See issue1478429 - it appears that rounding up was intentional, but I am adding 2.7 because py3k behavior seems to be more natural.

----------
assignee: belopolsky
components: Extension Modules
messages: 108536
nosy: belopolsky, georg.brandl, mark.dickinson, tim_one
priority: normal
severity: normal
stage: unit test needed
status: open
title: Timestamps are rounded differently in py3k and trunk
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9070>
_______________________________________

From report at bugs.python.org  Thu Jun 24 20:11:02 2010
From: report at bugs.python.org (Free Ekanayaka)
Date: Thu, 24 Jun 2010 18:11:02 +0000
Subject: [issue9071] TarFile doesn't support member files with a leading "./"
In-Reply-To: <1277403062.33.0.252734901258.issue9071@psf.upfronthosting.co.za>
Message-ID: <1277403062.33.0.252734901258.issue9071@psf.upfronthosting.co.za>


New submission from Free Ekanayaka <free at 64studio.com>:

The tar format allows to have memeber files whose path has a leading "./":

$ echo > foo
$ tar cf bar.tar ./foo
$ tar tf bar.tar 
./foo

However the tarfile module doesn't allow this:

>>> from StringIO import StringIO
>>> from tarfile import TarInfo, TarFile
>>> info = TarInfo("./foo")
>>> fd = open("bar.tar", "w")
>>> tar = TarFile.open(fileobj=fd, mode="w")
>>> tar.addfile(info, "")
>>> tar.close()

then:

$ tar tf bar.tar 
foo

So in practice the tarfile module forces the removal of leading "./"'s.

In particular this is a problem when creating .deb files (dpkg) programmatically as these contains tar files with members with a leading "./".

----------
components: Library (Lib)
messages: 108537
nosy: free.ekanayaka
priority: normal
severity: normal
status: open
title: TarFile doesn't support member files with a leading "./"
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9071>
_______________________________________

From report at bugs.python.org  Thu Jun 24 20:13:46 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Jun 2010 18:13:46 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277403226.17.0.330256853689.issue9069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

David, please could you also tell me whether HAVE_COPYSIGN is defined for those builds of Python?  It should be in pyconfig.h in the top level of the build directory, if it is.

And (just to double check), at configure time, there should be a line in the output of the configure script that looks like

checking for copysign... yes

Do you get 'yes' or 'no' there?

If I had to guess, I'd say that it's the float -> hex conversion that's going wrong (so that (-0.0).hex() produces '0x0.0p+0' instead of '-0x0.0p+0'), and that this is caused by either a buggy system copysign function, or by the system copysign function not being found and Python using a buggy workaround.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Thu Jun 24 20:21:07 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 24 Jun 2010 18:21:07 +0000
Subject: [issue9068] "from . import *"
In-Reply-To: <1277380004.45.0.44974456995.issue9068@psf.upfronthosting.co.za>
Message-ID: <1277403667.56.0.937821593986.issue9068@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

That's because while it is syntactically allowed, it is semantically disallowed. The grammar rules shown in the docs is a generalization of the actual grammar used to build the parser so that we can take shortcuts with it to simply not have rules that will pass the parser but fail in the compiler.

----------
assignee:  -> brett.cannon
components: +Documentation -Interpreter Core
nosy: +brett.cannon
priority: normal -> low
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9068>
_______________________________________

From report at bugs.python.org  Thu Jun 24 20:23:31 2010
From: report at bugs.python.org (Gustavo Niemeyer)
Date: Thu, 24 Jun 2010 18:23:31 +0000
Subject: [issue9071] TarFile doesn't support member files with a leading "./"
In-Reply-To: <1277403062.33.0.252734901258.issue9071@psf.upfronthosting.co.za>
Message-ID: <1277403811.15.0.582772118967.issue9071@psf.upfronthosting.co.za>


Gustavo Niemeyer <gustavo at niemeyer.net> added the comment:

Please note that even if unpacking such a tar might be semantically equivalent to a version which strips out the "./" prefix, it should be possible to create a tar with valid path names such as these.

In the case of debs, for instance, the files inside the tarball may contain expected path names, which means that some (badly done, perhaps) tools could *expect* the file to be exactly that which is created by the standard tools (e.g. "./debian/control"), and break down once it's not found.

With this in mind, it would indeed be nice to be able to use paths prefixed with "./" in Python's tarfile.

----------
nosy: +niemeyer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9071>
_______________________________________

From report at bugs.python.org  Thu Jun 24 20:27:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Jun 2010 18:27:34 +0000
Subject: [issue9070] Timestamps are rounded differently in py3k and trunk
In-Reply-To: <1277402527.75.0.74418180311.issue9070@psf.upfronthosting.co.za>
Message-ID: <1277404054.92.0.290357518542.issue9070@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

My mistake.  I had datetime.py from pypy in the directory from which I ran the trunk python.  The problem is also in the latest sandbox version of datetime.py, but this is not yet part of cpython proper.

Refiled as pypy bug at http://codespeak.net/issue/pypy-dev/issue548

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9070>
_______________________________________

From report at bugs.python.org  Thu Jun 24 20:47:48 2010
From: report at bugs.python.org (David Kirkby)
Date: Thu, 24 Jun 2010 18:47:48 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277405268.39.0.178887544328.issue9069@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Hi Mark, 

Here's the info on the two systems - first the SPARC system, secondly the Intel Xeon system.

1) SPARC

 * Sun Blade 2000, with 2 x UltraSPARC III+ 1200 MHZ processors
 * 8 GB RAM 
 * Solaris 10 update 8 10/09 release (This is the latest release of Solaris 10).

drkirkby at swan:~$ cat /etc/release
                      Solaris 10 10/09 s10s_u8wos_08a SPARC
           Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                           Assembled 16 September 2009
drkirkby at swan:~$ uname -a
SunOS swan 5.10 Generic_141444-09 sun4u sparc SUNW,Sun-Blade-1000

Python 2.6.4 (r264:75706, Jun 24 2010, 10:39:29) 
[GCC 4.4.4] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> float.hex(-0.0)
'0x0.0p+0'
>>> float.fromhex('-0x0.0p+0')
-0.0

When configure runs, I see:
"checking for copysign... yes"

In pyconfig.h I have:

/* Define to 1 if you have the `copysign' function. */
#define HAVE_COPYSIGN 1

======================================================
======================================================

2) Intel Xeon system. 

* Sun Ultra 27, quad core 3.33 GHz Intel Xeon processor
* 12 GB RAM
* OpenSolaris 06/2009, updated to build 134
* 64-bit installation. 
* Note, this is the native operating system on this machine, so VirtualBox is not used.  

drkirkby at hawk:~$ cat /etc/release
                       OpenSolaris Development snv_134 X86
           Copyright 2010 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                             Assembled 01 March 2010
drkirkby at hawk:~$ uname -a
SunOS hawk 5.11 snv_134 i86pc i386 i86pc

Python 2.6.4 (r264:75706, Jun 24 2010, 17:38:56) 
[GCC 4.4.4] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> float.hex(-0.0)
'0x0.0p+0'
>>> float.fromhex('-0x0.0p+0')
-0.0
>>> 

When configure runs, I see:

"checking for copysign... yes"

In pyconfig.h I have:
/* Define to 1 if you have the `copysign' function. */
#define HAVE_COPYSIGN 1


If you feel access to the SPARC system could help you debug this (or any of the other test failures I get), I can get you access to a machine 16-core Sun T5240 which was donated by Sun. 

I can't provide such easy access to the Xeon system, though you can install OpenSolaris as a Virtual machine in VirtualBox quite easily - its a free download. 

Dave

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Thu Jun 24 21:02:57 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Jun 2010 19:02:57 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277406177.8.0.434855118637.issue9069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the details.  So the relevant code (see the float_hex function in Objects/floatobject.c) looks like this:

    if (x == 0.0) {
        if(copysign(1.0, x) == -1.0)
            return PyString_FromString("-0x0.0p+0");
        else
            return PyString_FromString("0x0.0p+0");
    }

This *should* produce the correct string for -0.0 (because -0.0 compares equal to 0.0, and then copysign(1.0, x) should be -1.0);  I'm reasonably confident that the C code is correct, since the tests pass on all the other platforms that get tested regularly.

So a buggy system copysign function looks like a possibility.  Another more likely possibility occurs to me, though: and that's that there's a buggy compiler optimization going on:  the compiler sees that we're in an 'x == 0.0' branch, and decides that it can substitute '0.0' for 'x' everywhere in the 'if' block.  But this is just guessing.

Do you still get these failures in a debug build of Python (i.e., by passing --with-pydebug to the configure script)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Thu Jun 24 21:07:27 2010
From: report at bugs.python.org (David Kirkby)
Date: Thu, 24 Jun 2010 19:07:27 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277406447.47.0.653170173651.issue9069@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Just to clarify something, in case you notice something does not look quite right. 

The link I provided to the build failure on the SPARC machine

http://trac.sagemath.org/sage_trac/ticket/9297

was a Sun Blade 1000. It is *not* the same machine from which I just copied  the output, which was a Sun Blade 2000. The two machines are pretty similar though - the motherboards, processors, disks, RAM are interchangeable. In fact,'uname' shows Sun-Blade-1000 in both of them. I think the only real difference between them is that the Blade 2000 looks a bit nicer, and is officially supported with faster CPUs. 

The link I provided to the failure on the Xeon machine

http://trac.sagemath.org/sage_trac/ticket/9299

is the same machine where I just posted the output. 

If you need an account on a SPARC, it will be a more modern Sun T5240 with 32 GB RAM. 

Dave

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Thu Jun 24 21:32:49 2010
From: report at bugs.python.org (Slava)
Date: Thu, 24 Jun 2010 19:32:49 +0000
Subject: [issue9072] Unloading modules - memleaks?
In-Reply-To: <1277407969.42.0.292267385985.issue9072@psf.upfronthosting.co.za>
Message-ID: <1277407969.42.0.292267385985.issue9072@psf.upfronthosting.co.za>


New submission from Slava <bomboze at gmail.com>:

I don't know whether this is a bug, but my exhaustive search led me to "Python can't really unload modules" from every direction, which I find hard to believe, I don't know where else to go with this.

The problem:

  import gc, sys
  print len(gc.get_objects()) # 4073
  # starting with 4073 objects in memory

  import httplib
  del sys.modules["httplib"]
  del httplib

  # httplib should be unloaded 
  # and garbage collected as it is unreachable

  gc.collect()
  print len(gc.get_objects()) # 6745 
  # 6745 objects in memory (2000+ stray objects)

This applies to almost any module. 
Is this a bug or somehow correctable?

----------
components: None
messages: 108545
nosy: yappie
priority: normal
severity: normal
status: open
title: Unloading modules - memleaks?
type: resource usage
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9072>
_______________________________________

From report at bugs.python.org  Thu Jun 24 22:02:19 2010
From: report at bugs.python.org (David Kirkby)
Date: Thu, 24 Jun 2010 20:02:19 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277409739.05.0.493452621558.issue9069@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

I'll take a look at this in an hour or two. I'll restrict the testing to the Xeon machine, as it is a zillion times quicker than the old SPARCs. 

What comes to my mind, is that perhaps 'copysign' is only defined in C99.

Solaris header files are pretty strict about what gets defined and not defined depending on the mode of compilation. The compiler option -std=c99 is not being passed yet the man page for copysign on my OpenSolaris laptop (yet another system) says:

drkirkby at laptop:~$ man copysign

Mathematical Library Functions                       copysign(3M)

NAME
     copysign, copysignf, copysignl - number  manipulation  func-
     tion

SYNOPSIS
     c99 [ flag... ] file... -lm [ library... ]
     #include <math.h>

     double copysign(double x, double y);

     float copysignf(float x, float y);

     long double copysignl(long double x, long double y);

DESCRIPTION
     These functions produce a value with the magnitude of x  and
     the sign of y.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Thu Jun 24 22:03:07 2010
From: report at bugs.python.org (Roland Johnson)
Date: Thu, 24 Jun 2010 20:03:07 +0000
Subject: [issue9073] Tkinter module missing from install on OS X 10.6.4
In-Reply-To: <1277409787.07.0.389158105025.issue9073@psf.upfronthosting.co.za>
Message-ID: <1277409787.07.0.389158105025.issue9073@psf.upfronthosting.co.za>


New submission from Roland Johnson <rolandjohnson at acm.org>:

Tkinter no where to be found in the 3.1 install. No lib-tk folder either. There is a Tkinter folder but this conatains very few modules and none of the standard ones

----------
messages: 108547
nosy: RolandJ
priority: normal
severity: normal
status: open
title: Tkinter module missing from install on OS X 10.6.4
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9073>
_______________________________________

From report at bugs.python.org  Thu Jun 24 22:12:16 2010
From: report at bugs.python.org (Keith Rarick)
Date: Thu, 24 Jun 2010 20:12:16 +0000
Subject: [issue9074] [includes patch] subprocess module closes standard file
	descriptors when it should not
In-Reply-To: <1277410336.39.0.223644435027.issue9074@psf.upfronthosting.co.za>
Message-ID: <1277410336.39.0.223644435027.issue9074@psf.upfronthosting.co.za>


New submission from Keith Rarick <kr at xph.us>:

Transcript to reproduce in Python 2.6.5:

>>> import subprocess, sys
>>> subprocess.call(('echo', 'foo'), stderr=sys.stdout)
echo: write: Bad file descriptor
1
>>> 

Expected behavior:

>>> import subprocess, sys
>>> subprocess.call(('echo', 'foo'), stderr=sys.stdout)
foo
0
>>> 

This happens because we've asked the child's stderr to be redirected, but not its stdout. So in _execute_child, errwrite is 1 while c2pwrite is None. So fd 1 (errwrite) correctly gets duped to 2. But then, since errwrite is not None and it's not in (p2cread, c2pwrite, 2), the child closes fd 1.

The equivalent thing happens if you supply stdout=sys.stderr and the child attempts to write to its stderr.

I've attached a patch to fix this. It simply adds 2 and 2 to the list of fds not to close for c2pwrite and errwrite, respectively.

This patch is against the 2.6.5 release.

There is also a workaround, in case anyone else is affected by this bug before a fix has been released:

>>> import os, subprocess, sys
>>> subprocess.call(('echo', 'foo'), stderr=os.dup(sys.stdout.fileno()))
foo
0
>>> 

(There could be a similar bug relating to the child's stdin, but I haven't investigated that.)

----------
components: IO
files: fd-close.patch
keywords: patch
messages: 108548
nosy: kr
priority: normal
severity: normal
status: open
title: [includes patch] subprocess module closes standard file descriptors when it should not
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17762/fd-close.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9074>
_______________________________________

From report at bugs.python.org  Thu Jun 24 22:17:03 2010
From: report at bugs.python.org (Keith Rarick)
Date: Thu, 24 Jun 2010 20:17:03 +0000
Subject: [issue9074] [includes patch] subprocess module closes standard file
	descriptors when it should not
In-Reply-To: <1277410336.39.0.223644435027.issue9074@psf.upfronthosting.co.za>
Message-ID: <1277410623.24.0.599144933803.issue9074@psf.upfronthosting.co.za>


Keith Rarick <kr at xph.us> added the comment:

There was a typo in my description of the patch. It should read:

I've attached a patch to fix this. It simply adds 2 and *1* to the list of fds not to close for c2pwrite and errwrite, respectively.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9074>
_______________________________________

From report at bugs.python.org  Thu Jun 24 22:54:55 2010
From: report at bugs.python.org (David Kirkby)
Date: Thu, 24 Jun 2010 20:54:55 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277412895.12.0.941628076647.issue9069@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Using the compiler option -std=c99 allows this test to pass. 

Perhaps adding the macro 

AC_PROG_CC_C99

to autoconf to add the right compiler option might be a solution. I know Solaris headers are often quite strict, and will not define something in a header file if the right things are not defined to indicate C99. 

I would add, there is quite a serious problem on Solaris with _socket failing to build. 

http://bugs.python.org/issue8852

Unless one uses that workaround, which is not committed to the python source code yet, one can not run any tests of python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Thu Jun 24 23:18:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Jun 2010 21:18:07 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1277414287.36.0.533844127687.issue8860@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Similar problem affects fromtimestamp() constructors:

>>> datetime.fromtimestamp(0.0078125)-datetime.fromtimestamp(0)
datetime.timedelta(0, 0, 7813)
>>> datetime.utcfromtimestamp(0.0078125)-datetime.utcfromtimestamp(0)
datetime.timedelta(0, 0, 7813)

both rounded to odd, but

>>> 0.0078125*timedelta(seconds=1)
datetime.timedelta(0, 0, 7812)

is correctly rounded to even.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8860>
_______________________________________

From report at bugs.python.org  Thu Jun 24 23:30:57 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Jun 2010 21:30:57 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277415057.89.0.198636660716.issue9069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the update.

So I'm confused: when -std=c99 isn't given, where is the build finding the copysign function from?  That is, why isn't there a link error when building Python?

(I'm attempting to install OpenSolaris in Parallels at the moment, but it may take more time than I have available at the moment...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Fri Jun 25 00:04:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jun 2010 22:04:57 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1277417097.94.0.830855001197.issue7989@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Why do you need a pure Python version of datetime:
 - it's easier to work on a new feature first in Python: there are more people are able to write Python code, than people able to write C code (especially C code using the Python C API)
 - it helps datetime debuging
 - it helps other Python implementations (not only PyPy)
 - it improves the quality of the tests and so of the C version

I think that the first point is the most important, but datetime still lack many feature and is far from being perfect.

I don't think that the pure Python implementation should be used by default: the current C implementation should stay because it's faster and many people use it. I don't know the best name for the Python version, maybe pydatetime.py (or _pydatetime.py).

--

Questions:

 - @Alexander: did you contacted people from IronPython and Jython?
 - Is the Python version compatible with the C version about the serialization (pickle)?

--

r.david.murray> there may be more important stuff to python

You cannot force other developer to work on a specific topic since Python is only developed by hackers in their free time. If Alexander would like to work on this, he have to do it :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Fri Jun 25 00:11:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jun 2010 22:11:02 +0000
Subject: [issue8949] PyArg_Parse*(): "z" should not accept bytes
In-Reply-To: <1276032203.54.0.364398342729.issue8949@psf.upfronthosting.co.za>
Message-ID: <1277417462.21.0.537720269111.issue8949@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch commited to 3.2 (r82200), blocked in 3.1 (r82201).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8949>
_______________________________________

From report at bugs.python.org  Fri Jun 25 00:19:50 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 24 Jun 2010 22:19:50 +0000
Subject: [issue9045] 2.7rc1: 64-bit OSX installer is not built with 64-bit
	tkinter
In-Reply-To: <1277143341.0.0.74848452771.issue9045@psf.upfronthosting.co.za>
Message-ID: <1277417990.58.0.634665794983.issue9045@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

We can make this work on OSX 10.6 atleast, using Apple's system Tcl/Tk 8.5.

1. Get a 10.6 build machine with 10.5 SDK

2. Modify setup.py to use openssl 0.9.7 (*not* 0.9.8):

  search_for_ssl_incs_in=['/Developer/SDKs/MacOSX10.5.sdk/usr/include/'] 
  [...]
  s/ libraries = ['ssl', 'crypto'] / 
     libraries = ['ssl.0.9.7', 'crypto.0.9.7'] /g
  
3. Run ./configure with MACOSX_DEPLOYMENT_TARGET=10.5 env variable

Catch: 10.5 users will have to install Tcl/Tk manually (eg: ActiveTcl 8.5) and run IDLE with "arch -i386 idle2.7"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9045>
_______________________________________

From report at bugs.python.org  Fri Jun 25 00:33:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jun 2010 22:33:02 +0000
Subject: [issue8951] PyArg_Parse*(): factorize code of 's' and 'z' formats,
	and 'u' and 'Z' formats
In-Reply-To: <1276035065.31.0.617634960026.issue8951@psf.upfronthosting.co.za>
Message-ID: <1277418782.68.0.0268978177274.issue8951@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Done in 3.2 (r82202), blocked in 3.1 (r82203) because of #8949 and because I prefer to avoid touching a stable branch.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8951>
_______________________________________

From report at bugs.python.org  Fri Jun 25 00:38:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 24 Jun 2010 22:38:04 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1277392344.37.0.0711432340437.issue5672@psf.upfronthosting.co.za>
Message-ID: <4C23DE49.5060404@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Ats some point in the future when the "setproctitle" project
> (http://code.google.com/p/py-setproctitle/source/list) has matured it
> will be reconsidered, correct?

No. It will also be required that it's authors agree to contribute it to
Python, agree to stop maintaining the out-of-Python version
(eventually), and agree to fill out a contributor form.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5672>
_______________________________________

From report at bugs.python.org  Fri Jun 25 00:43:55 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 24 Jun 2010 22:43:55 +0000
Subject: [issue9072] Unloading modules - memleaks?
In-Reply-To: <1277407969.42.0.292267385985.issue9072@psf.upfronthosting.co.za>
Message-ID: <1277419435.1.0.961927616813.issue9072@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is not a bug. You didn't *nearly* reset Python to the state in which it was before the import: the modules that got imported recursively still hang in sys.modules.

Please accept that Python indeed does not support unloading modules for severe, fundamental, insurmountable, technical problems, in 2.x.

In 3.x, chances are slightly higher. In principle, unloading could be supported - but no module actually adds the necessary code, and the necessary code in the import machinery isn't implemented in 3.2 and earlier.

Supporting unloading will be (and was) a multi-year project. Don't expect any results in the next five years.

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9072>
_______________________________________

From report at bugs.python.org  Fri Jun 25 00:53:03 2010
From: report at bugs.python.org (Daniele Varrazzo)
Date: Thu, 24 Jun 2010 22:53:03 +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: <1277419983.27.0.398520910419.issue5672@psf.upfronthosting.co.za>


Daniele Varrazzo <piro at develer.com> added the comment:

> No. It will also be required that it's authors agree to contribute it to
> Python, agree to stop maintaining the out-of-Python version
> (eventually), and agree to fill out a contributor form.

I would have no problem with these points if the module is considered worthy for stdlib inclusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5672>
_______________________________________

From report at bugs.python.org  Fri Jun 25 01:00:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Jun 2010 23:00:18 +0000
Subject: [issue8682] _ssl.c uses PyWeakref_GetObject but doesn't incref result
In-Reply-To: <1273534331.53.0.523751841318.issue8682@psf.upfronthosting.co.za>
Message-ID: <1277420418.38.0.575708566936.issue8682@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r82204 (py3k) and r82205 (3.1).

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8682>
_______________________________________

From report at bugs.python.org  Fri Jun 25 01:03:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Jun 2010 23:03:15 +0000
Subject: [issue9075] ssl module sets "debug" flag on SSL struct
In-Reply-To: <1277420595.3.0.797937330193.issue9075@psf.upfronthosting.co.za>
Message-ID: <1277420595.3.0.797937330193.issue9075@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The ssl module sets a "debug" flag on the OpenSSL SSL struct at the end of PySSL_SSLdo_handshake():

    self->ssl->debug = 1;

The OpenSSL header files have this to say about this flag:

        /* set this flag to 1 and a sleep(1) is put into all SSL_read()
         * and SSL_write() calls, good for nbio debuging :-) */
        int debug;      

Some uses of it in the OpenSSL source are actually guarded by a macro (#ifdef PKT_DEBUG), but some are not. Bill, do you remember why you put that call? I would find it strongly preferrable to remove that assignment (doing so doesn't seem to break anything in the test suite).

----------
components: Library (Lib)
messages: 108561
nosy: exarkun, giampaolo.rodola, janssen, pitrou
priority: high
severity: normal
status: open
title: ssl module sets "debug" flag on SSL struct
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/issue9075>
_______________________________________

From report at bugs.python.org  Fri Jun 25 01:06:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jun 2010 23:06:50 +0000
Subject: [issue8926] getargs.c: release the buffer on error
In-Reply-To: <1275851470.16.0.472008534505.issue8926@psf.upfronthosting.co.za>
Message-ID: <1277420810.76.0.118853322378.issue8926@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed in r82206 and r82207.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8926>
_______________________________________

From report at bugs.python.org  Fri Jun 25 01:23:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Jun 2010 23:23:14 +0000
Subject: [issue9075] ssl module sets "debug" flag on SSL struct
In-Reply-To: <1277420595.3.0.797937330193.issue9075@psf.upfronthosting.co.za>
Message-ID: <1277421794.58.0.888491005776.issue9075@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, looking at the history of the SVN repo, this dates back to 1999 when the first SSL support was incorporated by Guido based on third-party patches, and no trace of a review discussion can be found. The only thing we can do is assume it's useless (and perhaps detrimental to performance) and remove it now.

Benjamin, do you think it's safe for 2.7 or should wait for 2.7.1?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9075>
_______________________________________

From report at bugs.python.org  Fri Jun 25 01:24:02 2010
From: report at bugs.python.org (David Kirkby)
Date: Thu, 24 Jun 2010 23:24:02 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277421842.54.0.604838606604.issue9069@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Hi Mark, 

Since 'copysign' is in the maths library, I would not expect the link phase to fail. Solaris does not ship with different maths libraries for C99 (one just links to libm). 

However, I would not be surprised if the behavior was ill defined if the compiler is not C99. Certainly header files behave differently on Solaris depending on the mode of the compiler. For example, trying to use the INFINITY macro when the compiler is not C99 seems to work on Linux, but fails on Solaris unless you force C99 mode with gcc -std=c99. 

The following bit of code gives the same results whether one uses 'gcc' or 'gcc -std=c99' on OpenSolaris or Linux. However, if one uses 'gcc -ansi' then the behavior is totally different. 

drkirkby at hawk:~$ cat cs.c
#include <stdio.h>
#include <math.h>


int main(int argc, char **argv) { 
   double x, y;

   /* Set x and y differently if a command line arguement is given. 
   This will avoid the compiler optimising the values out, as they
   will not be known in advance. */ 
   if (argc==1) { /* This will stop compiler optimising 0.0 out x */
      x=1.0; 
      y=0.0;
   } else {
      x=2.0;
      y=-0.0;
   }
   printf("copysign(%lf,%lf)=%lf\n", x, y, copysign(x, y));
}

drkirkby at hawk:~$ gcc -lm cs.c 
drkirkby at hawk:~$ ./a.out 
copysign(1.000000,0.000000)=1.000000
drkirkby at hawk:~$ ./a.out  z
copysign(2.000000,-0.000000)=-2.000000
drkirkby at hawk:~$ gcc -lm -std=c99 cs.c 
drkirkby at hawk:~$ ./a.out 
copysign(1.000000,0.000000)=1.000000
drkirkby at hawk:~$ ./a.out  z
copysign(2.000000,-0.000000)=-2.000000

Note how -ansi screws it up completely

drkirkby at hawk:~$ gcc -lm -ansi cs.c 
drkirkby at hawk:~$ ./a.out  
copysign(1.000000,0.000000)=0.000000
drkirkby at hawk:~$ ./a.out  z
copysign(2.000000,-0.000000)=0.000000

I also tried it on a Sun SPARC running a recent version of Solaris (2009 release). Again the results are the same. 

I then tried it on a Solaris box running the first release of Solaris 10 (03/2005). Then one gets even stranger behavior if one defines -ansi, where the results are almost right, but with poor rounding errors. 

drkirkby at redstart:~$ gcc -ansi -lm cs.c
drkirkby at redstart:~$ ./a.out
copysign(1.000000,0.000000)=1.000001
drkirkby at redstart:~$ ./a.out d
copysign(2.000000,-0.000000)=-2.000002

But in C99 mode, it works fine. 

drkirkby at redstart:~$ gcc -std=c99  -lm cs.c
drkirkby at redstart:~$ ./a.out
copysign(1.000000,0.000000)=1.000000
drkirkby at redstart:~$ ./a.out d
copysign(2.000000,-0.000000)=-2.000000

So I draw two conclusions. 


1) 'copysign' is in the maths library, so a program which tries to link to 'copysign' will succeed. 

2) The behavior of 'copysign' is ill defined unless the compiler is a C99 compiler. 

I don't think you should use copysign unless the compiler is C99. Trying to come up with a test for 'copysign' working is probably an impossible task, as it undefined. So you could try 99 different values of x and y and they all work, but its anyone guess what will happen with the 100th set of values. 

Dave

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Fri Jun 25 01:28:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jun 2010 23:28:51 +0000
Subject: [issue9076] Remove PyUnicode_AsDecodedObject/Unicode and
	PyUnicode_AsEncodedObject/Unicode?
In-Reply-To: <1277422131.02.0.354002642954.issue9076@psf.upfronthosting.co.za>
Message-ID: <1277422131.02.0.354002642954.issue9076@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The following 4 functions are public but not documented and not used in Python3:
 - PyUnicode_AsDecodedObject(), PyUnicode_AsEncodedObject()
 - PyUnicode_AsDecodedUnicode(), PyUnicode_AsEncodedUnicode()

In Python2, PyUnicode_AsDecodedObject() was used by unicode.decode() method, but Python3 has no more str.decode() method (see the recent discussion on python-dev mailing list about .transform() / .untransform()).

In Python2, unicode.encode() uses PyUnicode_AsEncodedObject(), but in Python3 str.encode() uses PyUnicode_AsEncodedString() which ensures that the result type is bytes.

PyUnicode_AsDecodedUnicode() and PyUnicode_AsEncodedUnicode() were added by Marc-Andre Lemburg in r63986. These functions may be used for .transform() / .untranform() proposition, but this proposition is not yet accepted and the functions are now unused.

If you decide to keep one of these functions, the function have to be documented.

----------
components: Unicode
files: remove_unicode_codec.patch
keywords: patch
messages: 108565
nosy: haypo, lemburg
priority: normal
severity: normal
status: open
title: Remove PyUnicode_AsDecodedObject/Unicode and PyUnicode_AsEncodedObject/Unicode?
versions: Python 3.2
Added file: http://bugs.python.org/file17763/remove_unicode_codec.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9076>
_______________________________________

From report at bugs.python.org  Fri Jun 25 01:34:51 2010
From: report at bugs.python.org (Slava)
Date: Thu, 24 Jun 2010 23:34:51 +0000
Subject: [issue9072] Unloading modules - memleaks?
In-Reply-To: <1277419435.1.0.961927616813.issue9072@psf.upfronthosting.co.za>
Message-ID: <AANLkTikhWS2FRqELSIXvn8wjE-XgTKJGMIJCwVTQMEy_@mail.gmail.com>


Slava <bomboze at gmail.com> added the comment:

Thank you for taking time to answer my question about unloading modules.
I really appreciate it!

Slava

On Fri, Jun 25, 2010 at 2:43 AM, Martin v. L??wis <report at bugs.python.org>wrote:

>
> Martin v. L??wis <martin at v.loewis.de> added the comment:
>
> This is not a bug. You didn't *nearly* reset Python to the state in which
> it was before the import: the modules that got imported recursively still
> hang in sys.modules.
>
> Please accept that Python indeed does not support unloading modules for
> severe, fundamental, insurmountable, technical problems, in 2.x.
>
> In 3.x, chances are slightly higher. In principle, unloading could be
> supported - but no module actually adds the necessary code, and the
> necessary code in the import machinery isn't implemented in 3.2 and earlier.
>
> Supporting unloading will be (and was) a multi-year project. Don't expect
> any results in the next five years.
>
> ----------
> nosy: +loewis
> resolution:  -> wont fix
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue9072>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file17764/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9072>
_______________________________________
-------------- next part --------------
Thank you for taking time to answer my question about unloading modules.??<div>I really appreciate it!</div><div><br></div><div>Slava<br><br><div class="gmail_quote">On Fri, Jun 25, 2010 at 2:43 AM, Martin v. L??wis <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>
Martin v. L??wis &lt;<a href="mailto:martin at v.loewis.de">martin at v.loewis.de</a>&gt; added the comment:<br>
<br>
This is not a bug. You didn&#39;t *nearly* reset Python to the state in which it was before the import: the modules that got imported recursively still hang in sys.modules.<br>
<br>
Please accept that Python indeed does not support unloading modules for severe, fundamental, insurmountable, technical problems, in 2.x.<br>
<br>
In 3.x, chances are slightly higher. In principle, unloading could be supported - but no module actually adds the necessary code, and the necessary code in the import machinery isn&#39;t implemented in 3.2 and earlier.<br>

<br>
Supporting unloading will be (and was) a multi-year project. Don&#39;t expect any results in the next five years.<br>
<br>
----------<br>
nosy: +loewis<br>
resolution: ??-&gt; wont fix<br>
status: open -&gt; closed<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/issue9072" target="_blank">http://bugs.python.org/issue9072</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Fri Jun 25 01:34:58 2010
From: report at bugs.python.org (Domen)
Date: Thu, 24 Jun 2010 23:34:58 +0000
Subject: [issue9077] argparse does not handle arguments correctly after --
In-Reply-To: <1277422498.3.0.635108415577.issue9077@psf.upfronthosting.co.za>
Message-ID: <1277422498.3.0.635108415577.issue9077@psf.upfronthosting.co.za>


New submission from Domen <ielectric at gmail.com>:

Sample code:

>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('-v', action='store_true')
>>> parser.add_argument('foo')
>>> parser.parse_args(['-v', '--', '--foo'])
Namespace(foo='--foo', v=True)

>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('-v', action='store_true')
>>> parser.parse_args(['--', '-f'])
usage: [-h] [-v]
: error: unrecognized arguments: -- -f

----------
components: Library (Lib)
messages: 108567
nosy: iElectric
priority: normal
severity: normal
status: open
title: argparse does not handle arguments correctly after --
type: security
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9077>
_______________________________________

From report at bugs.python.org  Fri Jun 25 01:35:14 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jun 2010 23:35:14 +0000
Subject: [issue9078] Fix C API documentation of unicode
Message-ID: <1277422513.82.0.685887790927.issue9078@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
assignee: docs at python
components: Documentation, Unicode
files: unicode_doc.patch
keywords: patch
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: Fix C API documentation of unicode
versions: Python 3.2
Added file: http://bugs.python.org/file17765/unicode_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9078>
_______________________________________

From report at bugs.python.org  Fri Jun 25 01:35:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jun 2010 23:35:54 +0000
Subject: [issue9078] Fix C API documentation of unicode
In-Reply-To: <1277422554.75.0.295241572037.issue9078@psf.upfronthosting.co.za>
Message-ID: <1277422554.75.0.295241572037.issue9078@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Attached patch fixes minor bugs in the C API documentation of unicode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9078>
_______________________________________

From report at bugs.python.org  Fri Jun 25 01:54:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jun 2010 23:54:56 +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: <1277423696.26.0.412369557769.issue8611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I think that #8988 is a duplicate of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Fri Jun 25 01:55:27 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 24 Jun 2010 23:55:27 +0000
Subject: [issue9075] ssl module sets "debug" flag on SSL struct
In-Reply-To: <1277420595.3.0.797937330193.issue9075@psf.upfronthosting.co.za>
Message-ID: <1277423727.74.0.252190591914.issue9075@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Let it die.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9075>
_______________________________________

From report at bugs.python.org  Fri Jun 25 02:02:45 2010
From: report at bugs.python.org (David Kirkby)
Date: Fri, 25 Jun 2010 00:02:45 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277424165.02.0.44186460756.issue9069@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Just to clarify the hostnames and hardware used, in case you look at the results here or the links to the Sage maths bug tracker and are not sure what is what. 

Note some are Solaris and some are OpenSolaris. Some have SPARC and some have Intel processors. All machines are 64-bit, but note that by default executables are created 32-bit on Solaris and OpenSolaris. 

 * hawk = Sun Ultra 27, 3.33 GHz quad core Xeon, OpenSolaris 06/2009, but updated to the latest build of OpenSolaris. 
 * laptop = Sony laptop, 2.0 GHz Intel CPU core2 duo, OpenSolaris 06/2009. 
 * swan = Sun Blade 2000, 2 x 1200 MHz SPARC processors, Solaris 10 10/2009 release (Latest release of Solaris 10 at the time I'm writing this)
 * redstart = Sun Blade 1000, 2 x 900 MHz SPARC processors, Solaris 10 03/2005 (First Solaris 10 release)

Although I've not shows the results from them, if I do show any others, likely candidates will be

 * sage = x86 Linux box (Ubunta I think) 24 cores. 
 * t2 = Sun T5240, T2+ SPARC processors, 16 cores 1167 MHz, Solaris 10 05/2009 (A recent, but not the very latest release of Solaris 10)
 * bsd = OS X box of some sort. 
 * hpbox = HP C3600 running HP-UX 11.11B, PA-RISC processors. 
 * chaffinch = Virtual machine running Solaris 10 10/2009. (Runs as a guest operating system in VirtualBox) 

Sometimes having access to different hardware can be useful, but it can get confusing if someone sees a lot of different host names! 

Dave

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Fri Jun 25 02:03:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Jun 2010 00:03:27 +0000
Subject: [issue8850] Remove "w" format of PyParse_ParseTuple()
In-Reply-To: <1275099860.74.0.46695580149.issue8850@psf.upfronthosting.co.za>
Message-ID: <1277424207.68.0.989109180889.issue8850@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited to 3.2 (r82208), blocked in 3.1 (r82209).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8850>
_______________________________________

From report at bugs.python.org  Fri Jun 25 02:03:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Jun 2010 00:03:40 +0000
Subject: [issue8850] Remove "w" format of PyParse_ParseTuple()
In-Reply-To: <1275099860.74.0.46695580149.issue8850@psf.upfronthosting.co.za>
Message-ID: <1277424220.88.0.108947713577.issue8850@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/issue8850>
_______________________________________

From report at bugs.python.org  Fri Jun 25 02:13:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jun 2010 00:13:36 +0000
Subject: [issue9075] ssl module sets "debug" flag on SSL struct
In-Reply-To: <1277420595.3.0.797937330193.issue9075@psf.upfronthosting.co.za>
Message-ID: <1277424816.36.0.00225034936423.issue9075@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks! Committed in r82210 (trunk), r82211 (py3k), r82212 (2.6), r82213 (3.1).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9075>
_______________________________________

From report at bugs.python.org  Fri Jun 25 02:13:58 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 00:13:58 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1277424838.07.0.720490837623.issue6608@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I've just noticed that time_strftime already has the range checks for tm structure fields.  These checks can be separated in a function and shared with asctime.  Marking this as "easy".  See also issue897625.

----------
keywords: +easy -patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Fri Jun 25 02:52:35 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 00:52:35 +0000
Subject: [issue9079] Make gettimeofday available in datetime module
In-Reply-To: <1277427154.32.0.0996770896527.issue9079@psf.upfronthosting.co.za>
Message-ID: <1277427154.32.0.0996770896527.issue9079@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Attached patch moves cross-platform logic of obtaining current time to _time.c which is shared between time and datetime modules.  This simplifies both modules and reduces the datetime module dependency on the time module.

----------
assignee: belopolsky
components: Extension Modules
files: gettimeofday.diff
keywords: needs review, patch
messages: 108575
nosy: belopolsky, mark.dickinson
priority: normal
severity: normal
stage: patch review
status: open
title: Make gettimeofday available in datetime module
versions: Python 3.2
Added file: http://bugs.python.org/file17766/gettimeofday.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9079>
_______________________________________

From report at bugs.python.org  Fri Jun 25 03:29:03 2010
From: report at bugs.python.org (David Kirkby)
Date: Fri, 25 Jun 2010 01:29:03 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1277429343.69.0.0573996843714.issue8852@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Hi Martin, 

I appreciate your point. But do you know if anyone has it on their TODO list? If not, is there anything I could do about it? I don't have commit access to the Python source code, but if there is anything else I can do I'd like to. 

This is a pretty serious bug, as it stops one running the self-tests. Although Python builds and 99% of it works with this bug, an attempt to run the self-tests exits fairly quickly, with no tests performed. So despite there being over 300 tests, note one of them gets run unless one works around this bug. 

Hence the implication is a lot more than the fact that one can't use _socket. 

Dave 

drkirkby at hawk:~/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src$ make test
running build
running build_ext
building '_socket' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/./Include -I. -IInclude -I./Include -I/usr/local/include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src -c /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c -o build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.o
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c: In function 'makesockaddr':
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:1103: error: 'struct ifreq' has no member named 'ifr_ifindex'
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:1104: error: 'SIOCGIFNAME' undeclared (first use in this function)
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:1104: error: (Each undeclared identifier is reported only once
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:1104: error: for each function it appears in.)
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c: In function 'getsockaddrarg':
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:1411: error: 'SIOCGIFINDEX' undeclared (first use in this function)
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:1423: error: 'struct ifreq' has no member named 'ifr_ifindex'
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c: In function 'init_socket':
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:4589: error: 'PACKET_LOOPBACK' undeclared (first use in this function)
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:4590: error: 'PACKET_FASTROUTE' undeclared (first use in this function)
building '_ssl' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/./Include -I. -IInclude -I./Include -I/usr/local/include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src -c /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_ssl.c -o build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_ssl.o
gcc -shared build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_ssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.solaris-2.11-i86pc-2.6/_ssl.so
*** WARNING: renaming "_ssl" since importing it failed: No module named _socket
building '_curses' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/./Include -I. -IInclude -I./Include -I/usr/local/include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src -c /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_cursesmodule.c -o build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_cursesmodule.o
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_cursesmodule.c: In function 'PyCursesWindow_ChgAt':
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_cursesmodule.c:708: warning: implicit declaration of function 'mvwchgat'
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_cursesmodule.c:712: warning: implicit declaration of function 'wchgat'
gcc -shared build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_cursesmodule.o -L/usr/local/lib -lcurses -ltermcap -o build/lib.solaris-2.11-i86pc-2.6/_curses.so
*** WARNING: renaming "_curses" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.11-i86pc-2.6/_curses.so: symbol mvwchgat: referenced symbol not found
building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/./Include -I. -IInclude -I./Include -I/usr/local/include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src -c /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_curses_panel.c -o build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_curses_panel.o
gcc -shared build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_curses_panel.o -L/usr/local/lib -lpanel -lcurses -ltermcap -o build/lib.solaris-2.11-i86pc-2.6/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing it failed: No module named _curses
building 'sunaudiodev' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/./Include -I. -IInclude -I./Include -I/usr/local/include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src -c /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c -o build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.o
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:20:25: error: sun/audioio.h: No such file or directory
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:36: error: expected specifier-qualifier-list before 'audio_info_t'
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c: In function 'sad_getinfo':
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:198: error: 'AUDIO_GETINFO' undeclared (first use in this function)
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:198: error: (Each undeclared identifier is reported only once
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:198: error: for each function it appears in.)
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:198: error: 'sadstatusobject' has no member named 'ai'
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c: In function 'sad_setinfo':
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:214: error: 'AUDIO_SETINFO' undeclared (first use in this function)
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:214: error: 'sadstatusobject' has no member named 'ai'
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c: In function 'sad_ibufcount':
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:225: error: 'audio_info_t' undeclared (first use in this function)
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:225: error: expected ';' before 'ai'
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:227: error: 'AUDIO_GETINFO' undeclared (first use in this function)
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:227: error: 'ai' undeclared (first use in this function)
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c: In function 'sad_obufcount':
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:237: error: 'audio_info_t' undeclared (first use in this function)
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:237: error: expected ';' before 'ai'
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:239: error: 'AUDIO_GETINFO' undeclared (first use in this function)
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:239: error: 'ai' undeclared (first use in this function)
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c: In function 'sad_drain':
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:253: error: 'AUDIO_DRAIN' undeclared (first use in this function)
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c: At top level:
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:348: error: expected specifier-qualifier-list before 'audio_info_t'
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:348: error: expected '}' before ')' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:348: error: expected ',' or ';' before ')' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:348: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:349: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:350: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:351: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:352: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:353: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:354: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:355: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:356: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:357: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:358: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:359: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:360: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:367: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:368: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:369: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:370: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:371: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:372: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:373: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:374: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:375: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:376: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:377: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:378: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:379: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:386: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:387: error: expected identifier or '(' before ',' token
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c: In function 'sads_getattr':
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:393: error: 'sadstatusobject' has no member named 'ai'
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c: In function 'sads_setattr':
/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/sunaudiodev.c:405: error: 'sadstatusobject' has no member named 'ai'
building '_tkinter' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DWITH_APPINIT=1 -I/usr/openwin/include -I. -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/./Include -I. -IInclude -I./Include -I/usr/local/include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src -c /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_tkinter.c -o build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_tkinter.o
In file included from /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_tkinter.c:67:
/usr/include/tk.h:81:23: error: X11/Xlib.h: No such file or directory
In file included from /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_tkinter.c:67:
/usr/include/tk.h:557: error: expected declaration specifiers or '...' before 'Window'
/usr/include/tk.h:557: error: 'Window' declared as function returning a function
/usr/include/tk.h:560: error: expected declaration specifiers or '...' before 'XEvent'
/usr/include/tk.h:569: error: expected specifier-qualifier-list before 'Tk_ClassCreateProc'
/usr/include/tk.h:661: error: expected specifier-qualifier-list before 'Bool'
/usr/include/tk.h:677: error: expected specifier-qualifier-list before 'Bool'
/usr/include/tk.h:754: error: expected specifier-qualifier-list before 'Display'
/usr/include/tk.h:904: error: expected declaration specifiers or '...' before 'XPoint'
/usr/include/tk.h:1005: error: expected declaration specifiers or '...' before 'Display'
/usr/include/tk.h:1007: error: expected declaration specifiers or '...' before 'Display'
/usr/include/tk.h:1007: error: expected declaration specifiers or '...' before 'Drawable'
/usr/include/tk.h:1104: error: expected specifier-qualifier-list before 'XColor'
/usr/include/tk.h:1168: error: expected specifier-qualifier-list before 'GC'
/usr/include/tk.h:1209: error: expected declaration specifiers or '...' before 'Display'
/usr/include/tk.h:1209: error: expected declaration specifiers or '...' before 'Drawable'
/usr/include/tk.h:1212: error: expected declaration specifiers or '...' before 'Display'
/usr/include/tk.h:1417: error: expected declaration specifiers or '...' before 'Drawable'
/usr/include/tk.h:1534: error: expected declaration specifiers or '...' before 'XErrorEvent'
/usr/include/tk.h:1536: error: expected declaration specifiers or '...' before 'XEvent'
/usr/include/tk.h:1538: error: expected declaration specifiers or '...' before 'XEvent'
/usr/include/tk.h:1540: error: expected declaration specifiers or '...' before 'XEvent'
/usr/include/tk.h:1545: error: expected declaration specifiers or '...' before 'XEvent'
In file included from /usr/include/tk.h:1559,
                 from /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_tkinter.c:67:
/usr/include/tkDecls.h:37: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
/usr/include/tkDecls.h:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Tk_3DBorderGC'
/usr/include/tkDecls.h:42: error: expected declaration specifiers or '...' before 'Drawable'
/usr/include/tkDecls.h:47: error: expected declaration specifiers or '...' before 'Drawable'
/usr/include/tkDecls.h:56: error: expected declaration specifiers or '...' before 'XEvent'
/usr/include/tkDecls.h:76: error: expected declaration specifiers or '...' before 'Pixmap'
/usr/include/tkDecls.h:80: error: expected declaration specifiers or '...' before 'XColor'
/usr/include/tkDecls.h:90: error: expected declaration specifiers or '...' before 'Pixmap'
/usr/include/tkDecls.h:95: error: expected declaration specifiers or '...' before 'GC'
/usr/include/tkDecls.h:114: error: expected declaration specifiers or '...' before 'XSetWindowAttributes'
/usr/include/tkDecls.h:122: error: expected declaration specifiers or '...' before 'Atom'
/usr/include/tkDecls.h:125: error: expected declaration specifiers or '...' before 'Atom'
/usr/include/tkDecls.h:125: error: expected declaration specifiers or '...' before 'Atom'
/usr/include/tkDecls.h:147: error: expected declaration specifiers or '...' before 'XWindowChanges'
/usr/include/tkDecls.h:167: error: expected ')' before '*' token
/usr/include/tkDecls.h:187: error: expected declaration specifiers or '...' before 'Atom'
/usr/include/tkDecls.h:187: error: expected declaration specifiers or '...' before 'Atom'
/usr/include/tkDecls.h:187: error: expected declaration specifiers or '...' before 'Atom'
/usr/include/tkDecls.h:232: error: expected declaration specifiers or '...' before 'Atom'
/usr/include/tkDecls.h:232: error: expected declaration specifiers or '...' before 'Atom'
/usr/include/tkDecls.h:242: error: expected declaration specifiers or '...' before 'Drawable'
/usr/include/tkDecls.h:242: error: expected declaration specifiers or '...' before 'XPoint'
/usr/include/tkDecls.h:247: error: expected declaration specifiers or '...' before 'Drawable'
/usr/include/tkDecls.h:252: error: expected ')' before '*' token
/usr/include/tkDecls.h:257: error: expected declaration specifiers or '...' before 'GC'
/usr/include/tkDecls.h:257: error: expected declaration specifiers or '...' before 'Drawable'
/usr/include/tkDecls.h:260: error: expected ')' before '*' token
/usr/include/tkDecls.h:265: error: expected declaration specifiers or '...' before 'Drawable'
/usr/include/tkDecls.h:265: error: expected declaration specifiers or '...' before 'XPoint'
/usr/include/tkDecls.h:270: error: expected declaration specifiers or '...' before 'Drawable'
/usr/include/tkDecls.h:278: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Tk_FontId'
/usr/include/tkDecls.h:282: error: expected ')' before '*' token
/usr/include/tkDecls.h:285: error: expected ')' before '*' token
/usr/include/tkDecls.h:287: error: expected ')' before '*' token
/usr/include/tkDecls.h:290: error: expected ')' before '*' token
/usr/include/tkDecls.h:295: error: expected ')' before '*' token
/usr/include/tkDecls.h:299: error: expected declaration specifiers or '...' before 'Display'
/usr/include/tkDecls.h:303: error: expected ')' before '*' token
/usr/include/tkDecls.h:309: error: expected ')' before '*' token
/usr/include/tkDecls.h:311: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Tk_GCForColor'
/usr/include/tkDecls.h:327: error: expected declaration specifiers or '...' before 'Atom'
/usr/include/tkDecls.h:334: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Tk_GetBitmap'
/usr/include/tkDecls.h:337: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Tk_GetBitmapFromData'
/usr/include/tkDecls.h:344: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
/usr/include/tkDecls.h:347: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
/usr/include/tkDecls.h:350: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Tk_GetColormap'
/usr/include/tkDecls.h:371: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Tk_GetGC'
/usr/include/tkDecls.h:401: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Tk_GetPixmap'
/usr/include/tkDecls.h:418: error: expected declaration specifiers or '...' before 'Atom'
/usr/include/tkDecls.h:418: error: expected declaration specifiers or '...' before 'Atom'
/usr/include/tkDecls.h:424: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
/usr/include/tkDecls.h:435: error: expected ')' before '*' token
/usr/include/tkDecls.h:437: error: expected ')' before '*' token
/usr/include/tkDecls.h:446: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Tk_InternAtom'
/usr/include/tkDecls.h:484: error: expected ')' before '*' token
/usr/include/tkDecls.h:489: error: expected ')' before '*' token
/usr/include/tkDecls.h:491: error: expected ')' before '*' token
/usr/include/tkDecls.h:509: error: expected declaration specifiers or '...' before 'Atom'
/usr/include/tkDecls.h:549: error: expected ')' before '*' token
/usr/include/tkDecls.h:552: error: expected ')' before '*' token
/usr/include/tkDecls.h:555: error: expected declaration specifiers or '...' before 'Drawable'
/usr/include/tkDecls.h:591: error: expected declaration specifiers or '...' before 'Pixmap'
/usr/include/tkDecls.h:600: error: expected declaration specifiers or '...' before 'Pixmap'
/usr/include/tkDecls.h:603: error: expected declaration specifiers or '...' before 'Colormap'
/usr/include/tkDecls.h:606: error: expected declaration specifiers or '...' before 'Visual'
/usr/include/tkDecls.h:606: error: expected declaration specifiers or '...' before 'Colormap'
/usr/include/tkDecls.h:610: error: expected ')' before '*' token
/usr/include/tkDecls.h:627: error: expected ')' before '*' token
/usr/include/tkDecls.h:632: error: expected ')' before '*' token
/usr/include/tkDecls.h:649: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Tk_AllocBitmapFromObj'
/usr/include/tkDecls.h:657: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
/usr/include/tkDecls.h:702: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Tk_GetBitmapFromObj'
/usr/include/tkDecls.h:705: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
/usr/include/tkDecls.h:772: error: expected ')' before '*' token
/usr/include/tkDecls.h:775: error: expected ')' before '*' token
/usr/include/tkDecls.h:788: error: expected declaration specifiers or '...' before 'GC'
/usr/include/tkDecls.h:795: error: expected declaration specifiers or '...' before 'GC'
/usr/include/tkDecls.h:801: error: expected declaration specifiers or '...' before 'Pixmap'
/usr/include/tkDecls.h:806: error: expected declaration specifiers or '...' before 'XColor'
/usr/include/tkDecls.h:821: error: expected declaration specifiers or '...' before 'Pixmap'
/usr/include/tkDecls.h:866: error: expected ')' before '*' token
/usr/include/tkDecls.h:915: error: expected declaration specifiers or '...' before 'Drawable'
/usr/include/tkDecls.h:932: error: expected specifier-qualifier-list before 'XColor'

Failed to find the necessary bits to build these modules:
_bsddb             bsddb185           gdbm            
linuxaudiodev      ossaudiodev                        
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
_curses            _curses_panel      _socket         
_ssl               _tkinter           sunaudiodev     

running build_scripts
./python -E -c 'import sys ; from distutils.util import get_platform ; print get_platform()+"-"+sys.version[0:3]' >platform
find ./Lib -name '*.py[co]' -print | xargs rm -f
./python -E -tt ./Lib/test/regrtest.py -l 
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 168, in <module>
    from test import test_support
  File "/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Lib/test/test_support.py", line 8, in <module>
    import socket
  File "/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Lib/socket.py", line 46, in <module>
    import _socket
ImportError: No module named _socket
make: [test] Error 1 (ignored)
./python -E -tt ./Lib/test/regrtest.py -l 
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 168, in <module>
    from test import test_support
  File "/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Lib/test/test_support.py", line 8, in <module>
    import socket
  File "/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Lib/socket.py", line 46, in <module>
    import _socket
ImportError: No module named _socket
make: *** [test] Error 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Fri Jun 25 03:33:07 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Jun 2010 01:33:07 +0000
Subject: [issue9077] argparse does not handle arguments correctly after --
In-Reply-To: <1277422498.3.0.635108415577.issue9077@psf.upfronthosting.co.za>
Message-ID: <1277429587.21.0.831855387059.issue9077@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> bethard
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9077>
_______________________________________

From report at bugs.python.org  Fri Jun 25 03:40:14 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 25 Jun 2010 01:40:14 +0000
Subject: [issue9077] argparse does not handle arguments correctly after --
In-Reply-To: <1277422498.3.0.635108415577.issue9077@psf.upfronthosting.co.za>
Message-ID: <1277430014.26.0.683036387443.issue9077@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/issue9077>
_______________________________________

From report at bugs.python.org  Fri Jun 25 04:35:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 02:35:08 +0000
Subject: [issue9079] Make gettimeofday available in datetime module
In-Reply-To: <1277427154.32.0.0996770896527.issue9079@psf.upfronthosting.co.za>
Message-ID: <1277433308.35.0.525804198843.issue9079@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The new patch, issue9079.diff exposes gettimeofday as time.gettimeofday() returning (sec, usec) pair.

----------
Added file: http://bugs.python.org/file17767/issue9079.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9079>
_______________________________________

From report at bugs.python.org  Fri Jun 25 04:36:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 02:36:11 +0000
Subject: [issue9079] Make gettimeofday available in datetime module
In-Reply-To: <1277427154.32.0.0996770896527.issue9079@psf.upfronthosting.co.za>
Message-ID: <1277433371.83.0.39532321218.issue9079@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17766/gettimeofday.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9079>
_______________________________________

From report at bugs.python.org  Fri Jun 25 08:31:09 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 25 Jun 2010 06:31:09 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1277429343.69.0.0573996843714.issue8852@psf.upfronthosting.co.za>
Message-ID: <4C244D29.9060004@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I appreciate your point. But do you know if anyone has it on their
> TODO list?

It's on my todo list, but that still might mean I can only get to
it next year.

> If not, is there anything I could do about it?

You could invoke the 5-for-one deal. Review 5 issues, and I'll deal with
this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Fri Jun 25 09:11:54 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Jun 2010 07:11:54 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277449914.33.0.0468219677556.issue9069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Did you have a chance to try a debug build of Python and see if the problem persists there?

I'm failing to reproduce this in OpenSolaris 2009.06, running in Parallels on a MacBook Pro (non-debug 32-bit build of Python):

dickinsm at eratosthenes:~/release26-maint$ uname -a
SunOS eratosthenes 5.11 snv_111b i86pc i386 i86pc Solaris
dickinsm at eratosthenes:~/release26-maint$ cat /etc/release
                         OpenSolaris 2009.06 snv_111b X86
           Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                              Assembled 07 May 2009
dickinsm at eratosthenes:~/release26-maint$ ./python
Python 2.6.5+ (release26-maint:82213, Jun 25 2010, 00:52:22) 
[GCC 3.4.3 (csl-sol210-3_4-20050802)] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> float.hex(-0.0)
'-0x0.0p+0'
>>> import sys; sys.maxsize
2147483647

The most noticeable difference from the machines you describe here is the compiler.  (Did you build gcc 4.4.4 by hand on these machines, or is there a package I can download and install somewhere?)

I'd still like to understand *how* the -c99 compiler option affects copysign;  it might help inform a workaround.  The library function itself can't know how you compiled Python, surely?  Can you work out what's going on from the relevant header files?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Fri Jun 25 09:20:17 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 25 Jun 2010 07:20:17 +0000
Subject: [issue9071] TarFile doesn't support member files with a leading "./"
In-Reply-To: <1277403062.33.0.252734901258.issue9071@psf.upfronthosting.co.za>
Message-ID: <1277450417.98.0.5960988808.issue9071@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

This is a duplicate of issue6054 which has been fixed in Python 2.7 (r74571).

(Hi, Gustavo!)

----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9071>
_______________________________________

From report at bugs.python.org  Fri Jun 25 10:51:57 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 25 Jun 2010 08:51:57 +0000
Subject: [issue9076] Remove PyUnicode_AsDecodedObject/Unicode
	and	PyUnicode_AsEncodedObject/Unicode?
In-Reply-To: <1277422131.02.0.354002642954.issue9076@psf.upfronthosting.co.za>
Message-ID: <4C246E28.6020008@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>:
> 
> The following 4 functions are public but not documented and not used in Python3:
>  - PyUnicode_AsDecodedObject(), PyUnicode_AsEncodedObject()
>  - PyUnicode_AsDecodedUnicode(), PyUnicode_AsEncodedUnicode()
> 
> In Python2, PyUnicode_AsDecodedObject() was used by unicode.decode() method, but Python3 has no more str.decode() method (see the recent discussion on python-dev mailing list about .transform() / .untransform()).
> 
> In Python2, unicode.encode() uses PyUnicode_AsEncodedObject(), but in Python3 str.encode() uses PyUnicode_AsEncodedString() which ensures that the result type is bytes.
> 
> PyUnicode_AsDecodedUnicode() and PyUnicode_AsEncodedUnicode() were added by Marc-Andre Lemburg in r63986. These functions may be used for .transform() / .untranform() proposition, but this proposition is not yet accepted and the functions are now unused.
> 
> If you decide to keep one of these functions, the function have to be documented.

Victor, instead of always proposing to remove APIs that don't show
up in the C-API documentation, I'd much rather like to see documentation
patches from you, instead of patches that remove the APIs themselves.

Please also remember that we are still in a transition phase from
Python2 to Python3. The fact that Python3 (currently) doesn't use
an API does not mean that there's no Python2 3rd party code out
there using them, waiting to be ported to Python3.
It also doesn't mean that the APIs are useless.

The cases you are finding are documentation bugs. I don't want to
have to go through discussions about the usefulness of the APIs
each and every time you find one of those documentation bugs.

Furthermore, the above APIs are part of the codec system and
that doesn't have anything to do with some helper methods we have
or don't have on str and bytes objects.

Please also note that all these function *are* documented in the
unicodeobject.h header file.

----------
title: Remove PyUnicode_AsDecodedObject/Unicode and PyUnicode_AsEncodedObject/Unicode? -> Remove PyUnicode_AsDecodedObject/Unicode and	PyUnicode_AsEncodedObject/Unicode?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9076>
_______________________________________

From report at bugs.python.org  Fri Jun 25 10:52:38 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 25 Jun 2010 08:52:38 +0000
Subject: [issue9076] Remove PyUnicode_AsDecodedObject/Unicode
	and	PyUnicode_AsEncodedObject/Unicode?
In-Reply-To: <1277422131.02.0.354002642954.issue9076@psf.upfronthosting.co.za>
Message-ID: <1277455958.84.0.796941495447.issue9076@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
assignee:  -> docs at python
components: +Documentation -Unicode
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9076>
_______________________________________

From report at bugs.python.org  Fri Jun 25 10:53:09 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 25 Jun 2010 08:53:09 +0000
Subject: [issue9076] Add C-API documentation for
	PyUnicode_AsDecodedObject/Unicode and
	PyUnicode_AsEncodedObject/Unicode
In-Reply-To: <1277422131.02.0.354002642954.issue9076@psf.upfronthosting.co.za>
Message-ID: <1277455989.54.0.186360068017.issue9076@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
title: Remove PyUnicode_AsDecodedObject/Unicode and	PyUnicode_AsEncodedObject/Unicode? -> Add C-API documentation for PyUnicode_AsDecodedObject/Unicode and PyUnicode_AsEncodedObject/Unicode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9076>
_______________________________________

From report at bugs.python.org  Fri Jun 25 12:01:03 2010
From: report at bugs.python.org (Free Ekanayaka)
Date: Fri, 25 Jun 2010 10:01:03 +0000
Subject: [issue9071] TarFile doesn't support member files with a leading "./"
In-Reply-To: <1277403062.33.0.252734901258.issue9071@psf.upfronthosting.co.za>
Message-ID: <1277460063.82.0.0021777195209.issue9071@psf.upfronthosting.co.za>


Free Ekanayaka <free at 64studio.com> added the comment:

Thanks for the prompt reply! Cool to know this is already fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9071>
_______________________________________

From report at bugs.python.org  Fri Jun 25 12:59:54 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Jun 2010 10:59:54 +0000
Subject: [issue9018] os.path.normcase(None) does not raise an error on linux
	and should
In-Reply-To: <1276782016.7.0.192519527211.issue9018@psf.upfronthosting.co.za>
Message-ID: <1277463594.26.0.894715667096.issue9018@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r82214. Now os.path.normcase() raises a TypeError if the arg is not str or bytes.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9018>
_______________________________________

From report at bugs.python.org  Fri Jun 25 13:18:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Jun 2010 11:18:37 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277464717.12.0.247948397307.issue9069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

So perhaps the cause is simply that copysign isn't being declared for David's Python builds?  If that were the case, I'd expect to see some gcc warnings in the Python build output, something like:

    warning: implicit declaration of function `copysign'

David, are there any such warnings?

Looking at /usr/include/math.h in my OpenSolaris VM, I see (with irrelevant bits omitted):

#if defined(__EXTENSIONS__) || defined(_XOPEN_SOURCE) || \
        !defined(_STRICT_STDC) && !defined(_POSIX_C_SOURCE)

#if defined(__EXTENSIONS__) || !defined(_XOPEN_SOURCE)

extern double copysign __P((double, double));

#endif

#endif

Assuming that this is the cause, it would be interesting to know which of these defines differs between my OpenSolaris VM and David's machines.
(e.g., the 'hawk' machine, since this seems closest in spec to what I'm working with).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Fri Jun 25 13:31:26 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Jun 2010 11:31:26 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277465486.86.0.566262872993.issue9069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

David, my pyconfig.h file contains:

/* Defined on Solaris to see additional function prototypes. */
#define __EXTENSIONS__ 1

Does yours?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Fri Jun 25 14:00:49 2010
From: report at bugs.python.org (Andy Buckley)
Date: Fri, 25 Jun 2010 12:00:49 +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: <1277467249.03.0.329544397504.issue9080@psf.upfronthosting.co.za>


New submission from Andy Buckley <andy at insectnation.org>:

I know that Python lists aren't designed for efficient prepending, but sometimes when working with small lists it's exactly what needs to be done (search path lists being a common example). For a programmer aware of the performance issue and having convinced themself that it's not a problem for their use-case, it's a niggle that there is no prepend()  function for lists by direct analogy to the commonly-used append(). 

Writing l = ["foo"] + l, or something mucky based on l.insert(0, ...) or reverse/append/reverse is annoyingly asymmetric and no more performant. So I suggest that l.append(x) be added to the list interface, with a prominent warning in the documentation that it's not an efficient operation on that type (possibly mention the complexity scaling with list length). I think the role of the interface is to make simple things simple, not to make it difficult to do simple-but-inefficient things that people will do anyway ;)

----------
components: Library (Lib)
messages: 108587
nosy: andybuckley
priority: normal
severity: normal
status: open
title: Provide list prepend method (even though it's not efficient)
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9080>
_______________________________________

From report at bugs.python.org  Fri Jun 25 14:10:36 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 25 Jun 2010 12:10:36 +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: <1277467836.9.0.707052807313.issue9080@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

Thanks for bringing this up.

I think you have more work to do to successfully make the case that L.insert(0, x) is "difficult" enough to merit the addition of a new list method.  There are already at least two in-place insert-at-front list APIs (the second being L[:0] = [x]).  There should be a very compelling reason for adding a third, and I don't think that being able to skip the extra 0 in the L.insert version is going to suffice.

----------
nosy: +exarkun
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9080>
_______________________________________

From report at bugs.python.org  Fri Jun 25 14:18:51 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Jun 2010 12:18:51 +0000
Subject: [issue4198] os.path.normcase gets fooled on windows with mapped linux
	network drive
In-Reply-To: <1224885833.7.0.0397055051655.issue4198@psf.upfronthosting.co.za>
Message-ID: <1277468331.23.0.821402044921.issue4198@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/issue4198>
_______________________________________

From report at bugs.python.org  Fri Jun 25 14:21:28 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Jun 2010 12:21:28 +0000
Subject: [issue9078] Fix C API documentation of unicode
In-Reply-To: <1277422554.75.0.295241572037.issue9078@psf.upfronthosting.co.za>
Message-ID: <1277468488.74.0.217382973472.issue9078@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks good to me.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9078>
_______________________________________

From report at bugs.python.org  Fri Jun 25 14:23:53 2010
From: report at bugs.python.org (Andy Buckley)
Date: Fri, 25 Jun 2010 12:23:53 +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: <1277468633.48.0.931938884245.issue9080@psf.upfronthosting.co.za>


Andy Buckley <andy at insectnation.org> added the comment:

Maybe I just value method symmetry/equivalence higher than the designers when it comes to interface expectations. I've seen several "I expected there to be a prepend() method like append() on lists, but there isn't -- what do I do?" emails on list archives when searching for info on this, which I think is in itself a hint that the current situation is counter-intuitive.

The argument that "there are already two ways to do it, so why add a third?", is not bad, but if applied to appending, it would ban the append() method... except that it's already there. Personally, the behaviour of append() is very familiar, while insert(0, ...) is less-used and I always have to explicitly confirm to myself that it isn't going to overwrite the zeroth existing element. Adding a prepend(x) method which just calls insert(0, x) (or calls the same underlying C function) would change nothing in terms of code efficiency -- bad programmers will always write inefficient code, one way or another -- but would make the list API more intuitive and improve code readability: seems to me like the sort of thing that Python is philosophically into ;)

Sorry to bring up this issue that I guess has been raised (many times?) before, but I thought I'd have a stab at a convincing case!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9080>
_______________________________________

From report at bugs.python.org  Fri Jun 25 14:25:18 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Jun 2010 12:25:18 +0000
Subject: [issue9077] argparse does not handle arguments correctly after --
In-Reply-To: <1277422498.3.0.635108415577.issue9077@psf.upfronthosting.co.za>
Message-ID: <1277468718.38.0.497176481306.issue9077@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Not a bug -- you have to tell argparse that you expect a positional argument.  Try without the '--' and an argument that doesn't start with '-', and it will still give you that error.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9077>
_______________________________________

From report at bugs.python.org  Fri Jun 25 14:35:32 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Jun 2010 12:35:32 +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: <1277469332.38.0.951675801556.issue9080@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If we add a .prepend() method, people will see it and start using it. Since now there's no 'prepend' method people ask why, and the answer they usually get is "because it not a good idea to add elements on lists (but if you really have to use the 'insert' method)".

The symmetry should be in the use case, not (only) in the names, otherwise we should also have a method to pop from the beginning to complete the symmetry with append/pop.

If you are not convinced yet you could write to the python-ideas mailing list.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9080>
_______________________________________

From report at bugs.python.org  Fri Jun 25 14:36:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Jun 2010 12:36:16 +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: <1277469376.67.0.211724277684.issue9080@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Andy, the bug-tracker isn't really the best place for this sort of discussion;  if you want to take this further I'd suggest mailing the python-ideas mailing list (bigger audience).

FWIW, the bar for adding new methods to builtins should be pretty high; I agree with Jean-Paul that 'list.prepend' seems unnecessary.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9080>
_______________________________________

From report at bugs.python.org  Fri Jun 25 14:36:43 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 25 Jun 2010 12:36:43 +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: <1277469403.44.0.633191328605.issue9080@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

> The argument that "there are already two ways to do it, so why add a third?", is not bad, but if applied to appending, it would ban the append() method... except that it's already there.

Not quite.  First let's consider the insert approach.  Unlike with prepending, you first have to find the length of the list: L.insert(len(L), x).  So it's no longer just a matter of an extra constant (although it /is/ still pretty simple).  Next, the slice assignment solution: L[-1:] = [x] doesn't work, because it actually includes the last element of L in the slice, so it replaces the last value instead of appending the new element.

So there's really just two ways, L.insert(len(L), x) and L.append(x).  To me, it seems like the extra cognitive load of figuring out whether the parameter to L.insert should be len(L) or len(L) - 1 or len(L) + 1 makes L.append worthwhile.  Maybe the same argument could be applied to L.insert(0, x), but it seems like a simpler case ("of _course_ inserting at 0 prepends") to me.

The other cost of adding a new list method is updating all of the list-like interfaces out there to also provide this, although that would probably be a cost worth accepting for a really compelling new method.

> Sorry to bring up this issue that I guess has been raised (many times?) before, but I thought I'd have a stab at a convincing case!

No need to apologize!  Thanks for the reasoned argument.  At least this can serve as a reference when the issue comes up again in the future, and perhaps someone else will be more convinced than overrule me. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9080>
_______________________________________

From report at bugs.python.org  Fri Jun 25 14:50:42 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Jun 2010 12:50:42 +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: <1277470242.29.0.884159693957.issue9080@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

[insert the usual reference to collections.deque here]

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9080>
_______________________________________

From report at bugs.python.org  Fri Jun 25 14:52:29 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Jun 2010 12:52: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: <1277470349.1.0.444450109273.issue9080@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here: http://docs.python.org/py3k/tutorial/datastructures.html#using-lists-as-queues

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9080>
_______________________________________

From report at bugs.python.org  Fri Jun 25 15:22:51 2010
From: report at bugs.python.org (Andy Buckley)
Date: Fri, 25 Jun 2010 13:22:51 +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: <1277472171.28.0.978454929571.issue9080@psf.upfronthosting.co.za>


Andy Buckley <andy at insectnation.org> added the comment:

Still not convinced with the reasoning, I'm afraid, but I certainly agree that modifications to built-ins are not to be made lightly. Using deques, which are far less familiar, is not a particularly natural thing to do for a search path, and of course can't be used with a built-in list to which you might well wish to prepend: sys.path.

Personally, I would have no problem with a list pop_front method ;) I understand the connection of API availability and misuse of algorithmically inefficient methods -- for large lists -- but I don't find "be inconveniently absent so that users search for an answer and find out about complexity issues" a very compelling or Pythonic design aim. But I admit that l.insert(0, x) is not such a hard idiom to learn -- just a bit less syntactically elegant and self-explanatory than I would prefer for a simple task, especially where I've already conciously made the efficiency decision in my choice of container type.

But thanks for listening... as mentioned, this can stay here as a reference for further enquiries (I searched for a pre-existing prepend() request before submitting this ticket, of course!) and I'll go visit python-ideas. Cheers!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9080>
_______________________________________

From report at bugs.python.org  Fri Jun 25 15:57:12 2010
From: report at bugs.python.org (=?utf-8?q?Domen_Ko=C5=BEar?=)
Date: Fri, 25 Jun 2010 13:57:12 +0000
Subject: [issue9077] argparse does not handle arguments correctly after --
In-Reply-To: <1277422498.3.0.635108415577.issue9077@psf.upfronthosting.co.za>
Message-ID: <1277474232.97.0.350491229915.issue9077@psf.upfronthosting.co.za>


Domen Ko?ar <ielectric at gmail.com> added the comment:

I agree ? not the best example, here is a better one explaining what behavior should not exist:

>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('foobar', action='store')
>>> parser.add_argument('foobar2', nargs='?')
>>> parser.add_argument('foobar3', nargs='*')
>>> print parser.parse_args(['foo', '--', 'foo3', 'foo3'])
Namespace(foobar='foo', foobar2='foo3', foobar3=['foo3'])


I would expect both foo3 to be part of foobar3. This does not happen because of foobar2 argument eating zero or one argument. Arguments after -- should be left unparsed as such behavior was in optparse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9077>
_______________________________________

From report at bugs.python.org  Fri Jun 25 16:09:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 14:09:39 +0000
Subject: [issue9079] Make gettimeofday available in time module
In-Reply-To: <1277427154.32.0.0996770896527.issue9079@psf.upfronthosting.co.za>
Message-ID: <1277474979.52.0.376983008668.issue9079@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Mark,

I am reassigning this to you for commit review.  I am changing the title to reflect the visible part of the change.  The datetime module gains direct access to system gettimeofday at the C level while time module grows time.gettimeofday() Python method.

I am not sure I made the best choice defining struct timeval on systems without gettimeofday.  Maybe it is better to do

typedef struct timeval _PyTime_timeval;

on systems with  gettimeofday and equivalent explicit definition on systems without.

The cast selection logic for time_t is a bit of a hack as well, but this is the best I could come up with without resorting to configure tests.  Unless this breaks on a known platform, I would rather commit this as is and have a separate project to clean up cross-platform time handling later.

This patch builds on refactoring started in issue9012.

----------
assignee: belopolsky -> mark.dickinson
stage: patch review -> commit review
title: Make gettimeofday available in datetime module -> Make gettimeofday available in time module
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9079>
_______________________________________

From report at bugs.python.org  Fri Jun 25 16:35:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Jun 2010 14:35:41 +0000
Subject: [issue8947] Provide  as_integer_ratio() method to Decimal
In-Reply-To: <1276030268.17.0.98739433208.issue8947@psf.upfronthosting.co.za>
Message-ID: <1277476541.08.0.377650001847.issue8947@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Raymond, do you have any thoughts on this proposal?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8947>
_______________________________________

From report at bugs.python.org  Fri Jun 25 16:41:28 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 14:41:28 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1277476888.53.0.239622209471.issue8860@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

>> The timedelta(seconds=0.6112295) example is handled correctly

> No, it's not!  It's being rounded *up* where it should be
> being rounded *down*.

Let me try to reformulate the issue.  When use is entering 0.6112295, she means 0.6112295, not 0x1.38f312b1b36bdp-1 or 0.61122949999999998116351207499974407255649566650390625 which are exact values of the underlying binary representation of 0.6112295.  Modern Python is able to round 0.6112295 to 6 decimal places correctly:

>>> round(0.6112295, 6)
0.611229

and timedelta should do the same, but it does not:

>>> timedelta(seconds=0.6112295)
datetime.timedelta(0, 0, 611230)

With respect to accumulation, I believe the invariant that we want to have should be

timedelta(x=a, y=b, ...) == timedelta(x=a) + timedelta(y=b)

while the alternative (using higher precision addition with rounding at the end) may be more accurate in some cases, the above looks least surprising.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8860>
_______________________________________

From report at bugs.python.org  Fri Jun 25 16:43:57 2010
From: report at bugs.python.org (Roland Johnson)
Date: Fri, 25 Jun 2010 14:43:57 +0000
Subject: [issue9045] 2.7rc1: 64-bit OSX installer is not built with 64-bit
	tkinter
In-Reply-To: <1277143341.0.0.74848452771.issue9045@psf.upfronthosting.co.za>
Message-ID: <1277477037.06.0.443575590689.issue9045@psf.upfronthosting.co.za>


Roland Johnson <rolandjohnson at acm.org> added the comment:

Does this also relate to 3.1? Tkinter in not installing for that version under 10.6.4

----------
nosy: +RolandJ

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9045>
_______________________________________

From report at bugs.python.org  Fri Jun 25 17:10:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 15:10:30 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1277478630.13.0.0980790212582.issue5516@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> Deprecating the feature for 3.x is certainly an option.
> May be a little drastic though.

How drastic would be to stop subclassing datetime from date in 3.2?  After all, we don't subclass float form int.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5516>
_______________________________________

From report at bugs.python.org  Fri Jun 25 17:12:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 15:12:41 +0000
Subject: [issue1578643] various datetime methods fail in restricted mode
Message-ID: <1277478761.19.0.3456304085.issue1578643@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

See issue9079.

----------
dependencies: +Make gettimeofday available in time module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578643>
_______________________________________

From report at bugs.python.org  Fri Jun 25 17:13:15 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 25 Jun 2010 15:13:15 +0000
Subject: [issue9045] 2.7rc1: 64-bit OSX installer is not built with 64-bit
	tkinter
In-Reply-To: <1277143341.0.0.74848452771.issue9045@psf.upfronthosting.co.za>
Message-ID: <1277478795.23.0.48215368324.issue9045@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

AFAIK there is no 64-bit installer for 3.1. There will be one for 3.2.


Sridhar: building using the 10.5 SDK should also work by using --enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk. I've recently patched setup.py and distutils to honor the SDK setting when looking for files.

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9045>
_______________________________________

From report at bugs.python.org  Fri Jun 25 17:24:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 15:24:08 +0000
Subject: [issue5288] tzinfo objects with sub-minute offsets are not supported
	(e.g. UTC+05:53:28)
In-Reply-To: <1234845206.93.0.372909555036.issue5288@psf.upfronthosting.co.za>
Message-ID: <1277479448.38.0.141617218468.issue5288@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This proved to require a lot of changes to C implementation because most of timezone arithmetics is done using integer operations with offset in minutes. It is easy, however to do this in pure python implementation which can be found at http://svn.python.org/view/*checkout*/sandbox/branches/py3k-datetime/datetime.py .

Marking this "easy" to attract volunteers who may want to do Python prototype.

----------
keywords: +easy
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5288>
_______________________________________

From report at bugs.python.org  Fri Jun 25 17:42:59 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Jun 2010 15:42:59 +0000
Subject: [issue3485] os.path.normcase documentation/behaviour unclear on Mac
	OS X
In-Reply-To: <1217610966.27.0.918507533161.issue3485@psf.upfronthosting.co.za>
Message-ID: <1277480579.53.0.298338975612.issue3485@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'm reopening this because now the normcase implementation of posixpath has a todo that says "on Mac OS X, this should really return s.lower()." (see r66743).
There is some discussion about this in #9018.

----------
nosy: +ezio.melotti
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3485>
_______________________________________

From report at bugs.python.org  Fri Jun 25 17:55:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 15:55:09 +0000
Subject: [issue9051] Improve pickle format for aware datetime instances
In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za>
Message-ID: <1277481309.58.0.885477139585.issue9051@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The datetime module provides compact pickled representation for date, datetime, time and timedelta instances:

type: size
date: 34
datetime: 44
time: 36
timedelta: 37


On the other hand, current pickle size for timezone is 64 and the size of an aware datetime instance is 105 bytes.

Since stability is important for pickle format, the best format should be developed before the first release to include timezone class.

----------
nosy: +fdrake
priority: low -> normal
stage: patch review -> needs patch
title: Cannot pickle timezone instances -> Improve pickle format for aware datetime instances

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9051>
_______________________________________

From report at bugs.python.org  Fri Jun 25 18:23:04 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 25 Jun 2010 16:23:04 +0000
Subject: [issue9081] test_sysconfig failure
In-Reply-To: <1277482983.46.0.622536161926.issue9081@psf.upfronthosting.co.za>
Message-ID: <1277482983.46.0.622536161926.issue9081@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

When I do a *full test run* of py3k I get a distutils test failure. It doesn't happen if I run test_distutils on its own:

bigmac:py3k michael$ ./python.exe -m test.regrtest -j12
== CPython 3.2a0 (py3k:82215, Jun 25 2010, 13:59:00) [GCC 4.2.1 (Apple Inc. build 5659)]
==   Darwin-10.4.0-i386-64bit
==   /compile/py3k/build/test_python_53586

... lots of results skipped

test test_distutils failed -- Traceback (most recent call last):
  File "/compile/py3k/Lib/distutils/tests/support.py", line 16, in _capture_warnings
    return func(*args, **kw)
  File "/compile/py3k/Lib/distutils/tests/test_sysconfig.py", line 47, in test_get_python_inc
    self.assertTrue(os.path.isdir(inc_dir), inc_dir)
AssertionError: /compile/py3k/build/test_python_53586/Include

----------
assignee: tarek
components: Distutils
messages: 108609
nosy: michael.foord, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_sysconfig failure
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9081>
_______________________________________

From report at bugs.python.org  Fri Jun 25 18:28:54 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 25 Jun 2010 16:28:54 +0000
Subject: [issue9045] 2.7rc1: 64-bit OSX installer is not built with 64-bit
	tkinter
In-Reply-To: <1277478795.23.0.48215368324.issue9045@psf.upfronthosting.co.za>
Message-ID: <5D7032C9-54EA-4F8D-8836-51142A2C4477@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On 2010-06-25, at 8:13 AM, Ronald Oussoren wrote:

> Sridhar: building using the 10.5 SDK should also work by using --enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk. I've recently patched setup.py and distutils to honor the SDK setting when looking for files.

Yes, but that will end up linking with Tcl/Tk 8.4 /inside/ the 10.5sdk; whereas the walkthrough above links to Apple's Tcl/Tk 8.5 built with 64-bit. I do hope - and I am not sure about this (though I have personally verified this by running regrtest) - using MACOSX_DEPLOYMENT_TARGET=10.5 will make the resultant binaries work on a 10.5 machine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9045>
_______________________________________

From report at bugs.python.org  Fri Jun 25 18:56:50 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 25 Jun 2010 16:56:50 +0000
Subject: [issue9051] Improve pickle format for aware datetime instances
In-Reply-To: <1277481309.58.0.885477139585.issue9051@psf.upfronthosting.co.za>
Message-ID: <AANLkTimPbfhpnBqFPapNj1OPJZeYQTekGcCX-_9HK2JH@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

As part of this, we should ensure references to common timezones, like
UTC, only create references to a single instance rather than filling
memory with multiple instances.

One consequence of this is that shared instances should probably be immutable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9051>
_______________________________________

From report at bugs.python.org  Fri Jun 25 19:56:50 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Jun 2010 17:56:50 +0000
Subject: [issue9079] Make gettimeofday available in time module
In-Reply-To: <1277427154.32.0.0996770896527.issue9079@psf.upfronthosting.co.za>
Message-ID: <1277488610.53.0.383587037973.issue9079@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

It would be great if Tim Peters could be consulted about some of these ideas.  He put a great deal of thought into the API, what should be included and what should be excluded.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9079>
_______________________________________

From report at bugs.python.org  Fri Jun 25 20:07:52 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Jun 2010 18:07:52 +0000
Subject: [issue8947] Provide  as_integer_ratio() method to Decimal
In-Reply-To: <1276030268.17.0.98739433208.issue8947@psf.upfronthosting.co.za>
Message-ID: <1277489272.49.0.19768767252.issue8947@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

-0  I don't think we really need this (we've already got a reasonable conversion to Fraction).

In general, we should have a aversion to adding any methods to the decimal API because it is already very fat.  Adding more methods makes it harder to figure out which one is the right one to use.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8947>
_______________________________________

From report at bugs.python.org  Fri Jun 25 20:13:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 18:13:25 +0000
Subject: [issue9079] Make gettimeofday available in time module
In-Reply-To: <1277427154.32.0.0996770896527.issue9079@psf.upfronthosting.co.za>
Message-ID: <1277489605.87.0.990674783459.issue9079@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I would very much appreciate Tim's input on datetime issues.  This particular issue is fairly minor, but Tim's expertise will be invaluable for anything timezone related.  I do appreciate the incredible amount of brainpower that went into the design of datetime module and I think the result is very good.  There is only one thing that I would like to improve - eliminate the need to reach out to the time module when working with the datetime instances.  This patch is a small step to removing the dependency at the implementation level.

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9079>
_______________________________________

From report at bugs.python.org  Fri Jun 25 20:27:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 18:27:20 +0000
Subject: [issue8947] Provide  as_integer_ratio() method to Decimal
In-Reply-To: <1276030268.17.0.98739433208.issue8947@psf.upfronthosting.co.za>
Message-ID: <1277490440.31.0.184926173518.issue8947@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Raymond,

conversion to Fraction does not really help in my use case of supporting timedelta * Decimal by duck typing.  I can think of many other use cases where it will be helpful to accept either float or decimal without loss of precision.  Is there an alternative way to achieve that which does not require importing the decimal module first?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8947>
_______________________________________

From report at bugs.python.org  Fri Jun 25 20:34:50 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 18:34:50 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1277490890.75.0.150457229878.issue2516@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Here is a similar issue which may be easier to fix:


>>> def f(a, b=None, *, c=None, d=None):
...    pass


>>> f(1,2,3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() takes at most 4 arguments (3 given)


Should be "f() takes at most 2 positional arguments (3 given)"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________

From report at bugs.python.org  Fri Jun 25 20:35:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 18:35:59 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1277490959.07.0.288717269443.issue2516@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee: belopolsky -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________

From report at bugs.python.org  Fri Jun 25 20:37:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 18:37:42 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1277491062.05.0.56706175354.issue2516@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________

From report at bugs.python.org  Fri Jun 25 20:37:50 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 18:37:50 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1277491070.45.0.588237573835.issue2516@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________

From report at bugs.python.org  Fri Jun 25 20:38:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 18:38:03 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1277491083.49.0.536153900968.issue2516@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________

From report at bugs.python.org  Fri Jun 25 20:39:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 18:39:49 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1277491189.55.0.325748500763.issue2516@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________

From report at bugs.python.org  Fri Jun 25 20:48:24 2010
From: report at bugs.python.org (=?utf-8?q?Germ=C3=A1n_L=2E_Osella_Massa?=)
Date: Fri, 25 Jun 2010 18:48:24 +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: <1277491704.02.0.89987869926.issue7951@psf.upfronthosting.co.za>


Germ?n L. Osella Massa <gosella at gmail.com> added the comment:

Well, using negative indexes for fields can be thought as a new feature with all the consequences mentioned before BUT negative indexes for accessing elements from a sequence, IMHO, is something that anyone would expected to work. That's why at first I thought it was a bug and I fill an issue about it.

The code that parses the fields and the indexes is the same, so when I change it to accept negative indexes, it worked for both cases. I'm attaching a patch that checks if a negative index is used in a field and reverts to the old behavior in that case, allowing only negative indexes for accessing sequences ( "{-1}" will raise KeyError because it will be threated as '-1').

Perhaps in this way this issue could be partially fixed.

----------
keywords: +patch
Added file: http://bugs.python.org/file17768/format_no_fields_with_negative_indexes-2.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Fri Jun 25 21:29:02 2010
From: report at bugs.python.org (Joseph Turian)
Date: Fri, 25 Jun 2010 19:29:02 +0000
Subject: [issue1789] assumption about unsigned long byte size in struct module
	usage
In-Reply-To: <1200051073.62.0.595441392864.issue1789@psf.upfronthosting.co.za>
Message-ID: <1277494142.21.0.981667645299.issue1789@psf.upfronthosting.co.za>


Joseph Turian <turian at gmail.com> added the comment:

I just got bit by this bug. This documentation (http://docs.python.org/library/struct.html) claims that an unsigned long is 4 bytes. On my machine, it's 8.

----------
nosy: +Joseph Turian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1789>
_______________________________________

From report at bugs.python.org  Fri Jun 25 21:29:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 19:29:19 +0000
Subject: [issue9051] Improve pickle format for aware datetime instances
In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za>
Message-ID: <1277494159.76.0.528089411244.issue9051@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a python prototype implementing interned UTC instance pickling.  The patch is against sandbox revision r82218 of datetime.py.

Note that the pickling protocol requires that an instance or factory function is defined at the module level.

The pickle size saving is substantial:


>>> len(dumps(datetime.now(timezone.utc)))
61
>>> len(dumps(datetime.now(timezone.min)))
163

but there is still room for improvement:

>>> len(dumps(datetime.now()))
44

I do feel, however, that further improvements will see diminishing returns.

----------
keywords: +patch
Added file: http://bugs.python.org/file17769/issue9051-utc-pickle-proto.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9051>
_______________________________________

From report at bugs.python.org  Fri Jun 25 21:31:30 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Jun 2010 19:31:30 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1277494290.51.0.288552923016.issue2516@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r82220.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________

From report at bugs.python.org  Fri Jun 25 21:34:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Jun 2010 19:34:34 +0000
Subject: [issue1789] assumption about unsigned long byte size in struct module
	usage
In-Reply-To: <1200051073.62.0.595441392864.issue1789@psf.upfronthosting.co.za>
Message-ID: <1277494474.15.0.514687934408.issue1789@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> This documentation (http://docs.python.org/library/struct.html)
> claims that an unsigned long is 4 bytes.

I don't think it does, if you read it closely.  Of course, patches to improve the docs are always welcome. :)

If you're looking at the table of format codes, note that it refers to the *standard* size, which is the size used when standard size and alignment are in effect (i.e., when the struct format string starts with '<', '>', etc.).  That standard size is indeed 4 bytes for the 'l' and 'L' codes.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1789>
_______________________________________

From report at bugs.python.org  Fri Jun 25 21:41:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Jun 2010 19:41:37 +0000
Subject: [issue1789] assumption about unsigned long byte size in struct module
	usage
In-Reply-To: <1200051073.62.0.595441392864.issue1789@psf.upfronthosting.co.za>
Message-ID: <1277494897.39.0.165339698148.issue1789@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a proposed doc clarification.

----------
keywords: +patch
Added file: http://bugs.python.org/file17770/issue1789_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1789>
_______________________________________

From report at bugs.python.org  Fri Jun 25 21:42:51 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Jun 2010 19:42:51 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1277494971.99.0.776544428364.issue2516@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Maybe I'm misunderstanding what issue we're talking about here, but wasn't this supposed to be fixed?


giampaolo at ubuntu:~/svn/python-3.2$ python3.2
Python 3.2a0 (py3k:82220M, Jun 25 2010, 21:38:56) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
...     def foo(self, x):
...             pass
... 
>>> A().foo()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: foo() takes exactly 2 arguments (1 given)
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________

From report at bugs.python.org  Fri Jun 25 21:44:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 25 Jun 2010 19:44:36 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1277495076.64.0.668655732392.issue7989@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Victor: that was exactly the point of my post that you partially quoted :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Fri Jun 25 22:15:38 2010
From: report at bugs.python.org (Joseph Turian)
Date: Fri, 25 Jun 2010 20:15:38 +0000
Subject: [issue1789] assumption about unsigned long byte size in struct module
	usage
In-Reply-To: <1200051073.62.0.595441392864.issue1789@psf.upfronthosting.co.za>
Message-ID: <1277496938.02.0.884255611819.issue1789@psf.upfronthosting.co.za>


Joseph Turian <turian at gmail.com> added the comment:

That patch gives good clarification.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1789>
_______________________________________

From report at bugs.python.org  Fri Jun 25 22:25:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Jun 2010 20:25:05 +0000
Subject: [issue1789] assumption about unsigned long byte size in struct module
	usage
In-Reply-To: <1200051073.62.0.595441392864.issue1789@psf.upfronthosting.co.za>
Message-ID: <1277497505.39.0.860025885878.issue1789@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee: gregory.p.smith -> mark.dickinson
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1789>
_______________________________________

From report at bugs.python.org  Fri Jun 25 22:26:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 25 Jun 2010 20:26:22 +0000
Subject: [issue9077] argparse does not handle arguments correctly after --
In-Reply-To: <1277422498.3.0.635108415577.issue9077@psf.upfronthosting.co.za>
Message-ID: <1277497582.42.0.10690627611.issue9077@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Still looks like it is working as designed to me.  Argpase is *parsing* the arguments, that's part of the whole point.  What you are observing is what I would expect from a well behaved unix command (*arguments* before the -- are just arguments, only the interpretation of options is stopped by --).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9077>
_______________________________________

From report at bugs.python.org  Fri Jun 25 22:30:01 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 25 Jun 2010 20:30:01 +0000
Subject: [issue1776674] glob.glob inconsistent
Message-ID: <1277497801.72.0.76391761272.issue1776674@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Hardly a show stopper. It's actually a problem(?) with ntpath.py.  It could be patched but is it worth it, as this would be yet more work for you guys doing the build/release process?  I'd close this on the grounds that it's not worth the effort.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1776674>
_______________________________________

From report at bugs.python.org  Fri Jun 25 23:00:12 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 25 Jun 2010 21:00:12 +0000
Subject: [issue9082] warnings.filterwarnings doesn't work with -O
In-Reply-To: <1277499612.9.0.672509574553.issue9082@psf.upfronthosting.co.za>
Message-ID: <1277499612.9.0.672509574553.issue9082@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

warnings.filterwarnings is mostly a bunch of asserts, so it doesn't work when Python is run with -O or -OO. This also means that a bunch of tests fail when run with -O or -OO.

Two options are skip the tests or fix filterwarnings.

----------
components: Library (Lib)
messages: 108628
nosy: michael.foord
priority: normal
severity: normal
status: open
title: warnings.filterwarnings doesn't work with -O
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9082>
_______________________________________

From report at bugs.python.org  Fri Jun 25 23:01:32 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 25 Jun 2010 21:01:32 +0000
Subject: [issue9082] warnings.filterwarnings doesn't work with -O
In-Reply-To: <1277499612.9.0.672509574553.issue9082@psf.upfronthosting.co.za>
Message-ID: <1277499692.11.0.47361734136.issue9082@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

A third (and better) option, but a deeper change, would be to allow the enabling of asserts on a per-module basis even when Python is run with -O/-OO. This would be great for testing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9082>
_______________________________________

From report at bugs.python.org  Fri Jun 25 23:03:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Jun 2010 21:03:37 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277499817.95.0.198690097807.issue9069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Now that I've finally managed to get gcc 4.4.4 installed on OpenSolaris...

.. I'm still failing to reproduce this bug. :(


dickinsm at eratosthenes:~/release26-maint$ uname -a
SunOS eratosthenes 5.11 snv_134 i86pc i386 i86pc Solaris
dickinsm at eratosthenes:~/release26-maint$ cat /etc/release 
                       OpenSolaris Development snv_134 X86
           Copyright 2010 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                             Assembled 01 March 2010
dickinsm at eratosthenes:~/release26-maint$ ./python
Python 2.6.4 (release26-maint:75706, Jun 25 2010, 21:44:19) 
[GCC 4.4.4] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> float.hex(-0.0)
'-0x0.0p+0'
>>> import sys; sys.maxint
2147483647

As far as I can tell, this setup is almost identical to David's 'hawk' machine (same gcc version, same OpenSolaris build, same Python source revision).

I'm not really sure where I can go from here.

Stefan, you're not able to reproduce this by any chance, are you?

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Fri Jun 25 23:05:38 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jun 2010 21:05:38 +0000
Subject: [issue9039] IDLE and module Doc
In-Reply-To: <1277073853.62.0.33861554581.issue9039@psf.upfronthosting.co.za>
Message-ID: <1277499938.92.0.727911201291.issue9039@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Try making an idle.bat file on your desktop.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9039>
_______________________________________

From report at bugs.python.org  Fri Jun 25 23:06:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 25 Jun 2010 21:06:55 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1277500015.91.0.96078045435.issue2516@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I presume Benjamin meant he fixed the special case Alexander reported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________

From report at bugs.python.org  Fri Jun 25 23:06:58 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 25 Jun 2010 21:06:58 +0000
Subject: [issue9082] warnings.filterwarnings doesn't work with -O
In-Reply-To: <1277499612.9.0.672509574553.issue9082@psf.upfronthosting.co.za>
Message-ID: <1277500018.62.0.517532033591.issue9082@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9082>
_______________________________________

From report at bugs.python.org  Fri Jun 25 23:19:58 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jun 2010 21:19:58 +0000
Subject: [issue9043] 2to3 doesn't handle byte comparison well
In-Reply-To: <1277131575.09.0.876680898489.issue9043@psf.upfronthosting.co.za>
Message-ID: <1277500798.57.0.444901519174.issue9043@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Replacing string indexes with length-1 slices in the 2.x codebase, whether or not one one is running 2to3, seems to be a 'known' technique for Python3 portability and unicode-bytes inter-operability. (It was discussed this week on py-dev list .) But I do not see it mentioned in PyWiki, such as on
http://wiki.python.org/moin/PortingPythonToPy3k

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9043>
_______________________________________

From report at bugs.python.org  Fri Jun 25 23:55:08 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jun 2010 21:55:08 +0000
Subject: [issue1528074] difflib.SequenceMatcher.find_longest_match() wrong
	result
Message-ID: <1277502908.92.0.419619264363.issue1528074@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This appears to be one of at least three duplicate issues: #1528074, #2986, and #4622. I am closing two, leaving 2986 open, and merging the nearly disjoint nosy lists. (If no longer interested, you can delete yourself from 2986.) #1711800 appears to be slightly different (if not, it could be closed also.)

Whether or not a new feature is ever added (earliest, now, 3.2), it appears that the docs need improvement to at least explain the current behavior. If someone who understands the issue could open a separate doc issue (for 2.6/7/3.1/2) with a suggested addition, that would be great.

----------
nosy: +tjreedy
resolution:  -> duplicate
status: open -> closed
superseder:  -> difflib.SequenceMatcher not matching long sequences

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1528074>
_______________________________________

From report at bugs.python.org  Fri Jun 25 23:55:56 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jun 2010 21:55:56 +0000
Subject: [issue4622] SequenceMatcher bug with long sequences
In-Reply-To: <1228929654.94.0.843066747309.issue4622@psf.upfronthosting.co.za>
Message-ID: <1277502956.18.0.935850271088.issue4622@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This appears to be one of at least three duplicate issues: #1528074, #2986, and #4622. I am closing two, leaving 2986 open, and merging the nearly disjoint nosy lists. (If no longer interested, you can delete yourself from 2986.) #1711800 appears to be slightly different (if not, it could be closed also.)

Whether or not a new feature is ever added (earliest, now, 3.2), it appears that the docs need improvement to at least explain the current behavior. If someone who understands the issue could open a separate doc issue (for 2.6/7/3.1/2) with a suggested addition, that would be great.

----------
nosy: +tjreedy
resolution:  -> duplicate
status: open -> closed
superseder:  -> difflib.SequenceMatcher not matching long sequences

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4622>
_______________________________________

From report at bugs.python.org  Fri Jun 25 23:56:20 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jun 2010 21:56:20 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1277502980.56.0.073524991445.issue2986@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This appears to be one of at least three duplicate issues: #1528074, #2986, and #4622. I am closing two, leaving 2986 open, and merging the nearly disjoint nosy lists. (If no longer interested, you can delete yourself from 2986.) #1711800 appears to be slightly different (if not, it could be closed also.)

Whether or not a new feature is ever added (earliest, now, 3.2), it appears that the docs need improvement to at least explain the current behavior. If someone who understands the issue could open a separate doc issue (for 2.6/7/3.1/2) with a suggested addition, that would be great.

----------
nosy: +LambertDW, eliben, gagenellina, janpf, jimjjewett, rtvd, sjmachin, tjreedy
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Fri Jun 25 23:59:48 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jun 2010 21:59:48 +0000
Subject: [issue1524639] Fix Tkinter Tcl-commands memory-leaks
Message-ID: <1277503188.05.0.381599184643.issue1524639@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> patch review
versions: +Python 3.2 -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1524639>
_______________________________________

From report at bugs.python.org  Sat Jun 26 00:04:00 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jun 2010 22:04:00 +0000
Subject: [issue4726] doctest gets line numbers wrong due to quotes in comments
In-Reply-To: <1229970384.34.0.779810047928.issue4726@psf.upfronthosting.co.za>
Message-ID: <1277503440.23.0.159734706285.issue4726@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> works for me
status: open -> pending
versions:  -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4726>
_______________________________________

From report at bugs.python.org  Sat Jun 26 00:06:45 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 25 Jun 2010 22:06:45 +0000
Subject: [issue7673] audioop: check that length is a multiple of the size
In-Reply-To: <1263171957.43.0.71285781195.issue7673@psf.upfronthosting.co.za>
Message-ID: <1277503605.39.0.657336913346.issue7673@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/issue7673>
_______________________________________

From report at bugs.python.org  Sat Jun 26 00:07:57 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jun 2010 22:07:57 +0000
Subject: [issue4640] optparse - dosn't distinguish between '--option' and
	'-option'
In-Reply-To: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za>
Message-ID: <1277503677.54.0.715133293481.issue4640@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Victor, I am interpreting your comment as saying that this is not a bug. If I am wrong, someone can re-open.

In any case, the bug would have to be in 2.6 or more realistically, 2.7, since 2.6.final will be out soon.

----------
nosy: +tjreedy
resolution:  -> works for me
status: open -> closed
versions: +Python 2.6, Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4640>
_______________________________________

From report at bugs.python.org  Sat Jun 26 00:09:46 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jun 2010 22:09:46 +0000
Subject: [issue4775] Incorrect documentation - UTC time
In-Reply-To: <1230603442.34.0.985593856271.issue4775@psf.upfronthosting.co.za>
Message-ID: <1277503786.99.0.0805532860182.issue4775@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4775>
_______________________________________

From report at bugs.python.org  Sat Jun 26 00:11:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Jun 2010 22:11:13 +0000
Subject: [issue4640] optparse - dosn't distinguish between '--option' and
	'-option'
In-Reply-To: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za>
Message-ID: <1277503873.12.0.717870570058.issue4640@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

optparse specifically supports only GNU-style two-dashes long argument. Victor is right, optparse will always understand -thing as -t -h -i -n -g.

----------
nosy: +merwok
resolution: works for me -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4640>
_______________________________________

From report at bugs.python.org  Sat Jun 26 00:21:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Jun 2010 22:21:49 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1277504509.42.0.788442570706.issue1322@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file8609/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Sat Jun 26 00:23:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Jun 2010 22:23:56 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1277504636.69.0.614602451209.issue1322@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Sat Jun 26 00:27:32 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 25 Jun 2010 22:27:32 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277504852.44.0.541936449531.issue9069@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Mark Dickinson <report at bugs.python.org> wrote:
> Now that I've finally managed to get gcc 4.4.4 installed on OpenSolaris...
>
> .. I'm still failing to reproduce this bug. :(
>
>
> dickinsm at eratosthenes:~/release26-maint$ uname -a
> SunOS eratosthenes 5.11 snv_134 i86pc i386 i86pc Solaris
> dickinsm at eratosthenes:~/release26-maint$ cat /etc/release
>                        OpenSolaris Development snv_134 X86
>            Copyright 2010 Sun Microsystems, Inc.  All Rights Reserved.
>                         Use is subject to license terms.
>                              Assembled 01 March 2010
> dickinsm at eratosthenes:~/release26-maint$ ./python
> Python 2.6.4 (release26-maint:75706, Jun 25 2010, 21:44:19)
> [GCC 4.4.4] on sunos5
> Type "help", "copyright", "credits" or "license" for more information.
> >>> float.hex(-0.0)
> '-0x0.0p+0'
> >>> import sys; sys.maxint
> 2147483647
>
> As far as I can tell, this setup is almost identical to David's 'hawk' machine (same gcc version, same OpenSolaris build, same Python source
+revision).
>
> I'm not really sure where I can go from here.
>
> Stefan, you're not able to reproduce this by any chance, are you?

No, I'm getting the same results as you (OpenSolaris/qemu/32-bit/gcc). I wonder
if it's somehow related to issue 7281, which was resolved by changing float_repr_style.

But as I said, I cannot reproduce it with either gcc or suncc. On the other hand,
who knows how the FPU is emulated in qemu.


The C standard is diplomatic as usual:

"On implementations that represent a signed zero but do not treat negative zero
 consistently in arithmetic operations, the copysign functions regard the sign
 of zero as positive."


David, one of your comments implied for me that you have managed to compile
Python with -std=c99. For me, this fails instantly. What options did you use?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 00:33:21 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jun 2010 22:33:21 +0000
Subject: [issue1222721] tk + setlocale problems...
Message-ID: <1277505201.19.0.91310360936.issue1222721@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The backspace issue seems to have been fixed.

I modified bug.py for 3.1 by removing the coding cookie, changing unicode("?????", "KOI8-R") to just "?????", and fixing print. Running from IDLE, it ran and displayed a tk window with text entry and labelled button that printed "Friday" in the shell window.

On the other hand, "I also found that the problem only appears when the LC_NUMERIC setting is different to en_US. (for example if it is de_AT)" suggests that other might have a problem (I am in the US).

Sidenote: Since the obscure koi8-R encoding (no longer valid in 3.x, the interpreter said) is not described as part of the bug, it should not be part of a minimal example.

----------
nosy: +tjreedy
versions: +Python 2.7 -Python 2.5
Added file: http://bugs.python.org/file17771/nobug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222721>
_______________________________________

From report at bugs.python.org  Sat Jun 26 00:34:25 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jun 2010 22:34:25 +0000
Subject: [issue4872] Python will not co-exist with MFC (memory leak)
In-Reply-To: <1231365332.46.0.804752973069.issue4872@psf.upfronthosting.co.za>
Message-ID: <1277505265.11.0.246634153267.issue4872@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> invalid
status: open -> pending
versions:  -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4872>
_______________________________________

From report at bugs.python.org  Sat Jun 26 00:38:44 2010
From: report at bugs.python.org (Steve Holden)
Date: Fri, 25 Jun 2010 22:38:44 +0000
Subject: [issue9083] At least some Tools utilities are still Python 2
In-Reply-To: <1277505524.04.0.87838503944.issue9083@psf.upfronthosting.co.za>
Message-ID: <1277505524.04.0.87838503944.issue9083@psf.upfronthosting.co.za>


New submission from Steve Holden <steve at holdenweb.com>:

C:\Users\sholden>\python31\python \python31\Tools\webchecker\wcgui.py
Traceback (most recent call last):
  File "\python31\Tools\webchecker\wcgui.py", line 63, in <module>
    from Tkinter import *
ImportError: No module named Tkinter

This makes is seem pretty clear that not even minimal effort has been expended to ensure that this Tools is functional. It's not a priority, so that's understandable. Maybe I am the only person who ever tried to use this under Python 3.

Perhaps we need a test that will fail if these things don't at least run to completion (and no, I don't know how I would test wcgui, but I'd be interested in discussing test strategies)?

----------
assignee: holdenweb
components: 2to3 (2.x to 3.0 conversion tool), Demos and Tools
messages: 108641
nosy: holdenweb
priority: high
severity: normal
stage: unit test needed
status: open
title: At least some Tools utilities are still Python 2
type: feature request
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9083>
_______________________________________

From report at bugs.python.org  Sat Jun 26 00:47:53 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jun 2010 22:47:53 +0000
Subject: [issue3383] ctypes.util fails to find libc in some environments
In-Reply-To: <1216233113.79.0.266532127913.issue3383@psf.upfronthosting.co.za>
Message-ID: <1277506073.99.0.876459259906.issue3383@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Given the patch applied for #4861, I think this should be closed until someone finds that there is still a bug in a current version of Python and determines that there is something to be done.

----------
nosy: +tjreedy
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3383>
_______________________________________

From report at bugs.python.org  Sat Jun 26 01:02:24 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 23:02:24 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1277506944.64.0.411572843332.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Adding tim_one to the nosy list.

Tim,

It would be great if you could shed some light on the history behind pure python implementation.  Why was it developed in the first place?  What was the reason not to ship it with python?

Thanks.

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Sat Jun 26 01:08:20 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jun 2010 23:08:20 +0000
Subject: [issue4925] Improve error message of subprocess when cannot open
In-Reply-To: <1231777617.86.0.584511455662.issue4925@psf.upfronthosting.co.za>
Message-ID: <1277507300.57.0.688817496677.issue4925@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Improved error messages are feature requests because 1) there is no particular guarantee in the doc and 2) changes can break existing code, so should only happen in an new x.y version.

When reporting behavior, it is helpful to give *minimal* code that will reproduce, either in the message if small, or attached. For example, with 3.1.2 on WixXP

>>> import subprocess
>>> subprocess.Popen("xyz")
gives
WindowsError: [Error 2] The system cannot find the file specified

Although in this case the literal name is in the traceback, it is not always. So I am leaving this open. Given that

>>> open('xyx')
gives the more helpful
IOError: [Errno 2] No such file or directory: 'xyx'

it seems it might be possible by using the io code.

----------
nosy: +tjreedy
title: Improve error message of subprocess -> Improve error message of subprocess when cannot open
type: behavior -> feature request
versions: +Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4925>
_______________________________________

From report at bugs.python.org  Sat Jun 26 01:11:30 2010
From: report at bugs.python.org (Tim Peters)
Date: Fri, 25 Jun 2010 23:11:30 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1277507490.09.0.413520823138.issue7989@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

> It would be great if you could shed
> some light on the history behind pure
> python implementation.  Why was it
> developed in the first place?

It was rapid prototyping - design decisions were changing daily, and it goes a lot faster to change Python code than C code.

> What was the reason not to ship it
> with python?

Didn't want to create new ongoing maintenance burdens.  Multiple implementations eventually drift out of synch, and at the time we had had enough of that already wrt, e.g., pickle vs cPickle.

Sorry, nothing deep here ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Sat Jun 26 01:14:37 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jun 2010 23:14:37 +0000
Subject: [issue1565525] gc allowing tracebacks to eat up memory
Message-ID: <1277507677.83.0.31446021361.issue1565525@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Given comments like "I'm still having problems figuring out what the bug is that you are reporting. (Martin)" and "I must repeat that there is no simple-minded way to 'repair' this. (Tim)", and subsequent changes to Python, should this still be open? If so, for which version(s)?

----------
nosy: +tjreedy
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Sat Jun 26 01:21:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jun 2010 23:21:10 +0000
Subject: [issue9083] At least some Tools utilities are still Python 2
In-Reply-To: <1277505524.04.0.87838503944.issue9083@psf.upfronthosting.co.za>
Message-ID: <1277508070.85.0.456196125249.issue9083@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gpolo
stage: unit test needed -> needs patch
type: feature request -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9083>
_______________________________________

From report at bugs.python.org  Sat Jun 26 01:22:57 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 25 Jun 2010 23:22:57 +0000
Subject: [issue1565525] gc allowing tracebacks to eat up memory
Message-ID: <1277508177.01.0.915283742396.issue1565525@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> wont fix
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Sat Jun 26 01:24:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jun 2010 23:24:28 +0000
Subject: [issue9082] warnings.filterwarnings doesn't work with -O
In-Reply-To: <1277499612.9.0.672509574553.issue9082@psf.upfronthosting.co.za>
Message-ID: <1277508268.6.0.864457811471.issue9082@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> brett.cannon
nosy: +brett.cannon
priority: normal -> high
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9082>
_______________________________________

From report at bugs.python.org  Sat Jun 26 01:26:01 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jun 2010 23:26:01 +0000
Subject: [issue4943] trace.CoverageResults.write_results can't write results
	file for modules loaded by __path__ manipulation
In-Reply-To: <1231906566.94.0.987113502153.issue4943@psf.upfronthosting.co.za>
Message-ID: <1277508361.45.0.679673009255.issue4943@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +easy
stage:  -> patch review
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4943>
_______________________________________

From report at bugs.python.org  Sat Jun 26 01:26:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jun 2010 23:26:32 +0000
Subject: [issue9081] test_sysconfig failure
In-Reply-To: <1277482983.46.0.622536161926.issue9081@psf.upfronthosting.co.za>
Message-ID: <1277508392.76.0.719834316304.issue9081@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hurray, I'm not the only one!

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed
superseder:  -> test_distutils failure

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9081>
_______________________________________

From report at bugs.python.org  Sat Jun 26 01:27:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jun 2010 23:27:11 +0000
Subject: [issue9038] test_distutils failure
In-Reply-To: <1277066901.58.0.116708897563.issue9038@psf.upfronthosting.co.za>
Message-ID: <1277508431.18.0.398717877156.issue9038@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9038>
_______________________________________

From report at bugs.python.org  Sat Jun 26 01:29:30 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jun 2010 23:29:30 +0000
Subject: [issue4963] mimetypes.guess_extension result changes after
	mimetypes.init()
In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>
Message-ID: <1277508570.75.0.510641300184.issue4963@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7 -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4963>
_______________________________________

From report at bugs.python.org  Sat Jun 26 01:29:36 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 23:29:36 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1277508576.27.0.7628772915.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Tim, thanks for your prompt reply.

What would be your opinion on adding datetime.py to the main python tree today?

There is momentum behind several features to be added to datetime module and having easily accessible prototype would give similar benefits to those you had during original design.

It is hard for me to judge the significance of maintenance burden, but others reported that having parallel versions of the io module was helpful.  I believe that with proper support in the regression test suit, it should be quite manageable.  If contributors are encouraged to do python version of new features first, get full test coverage and then do C implementation, it may lead to higher quality contributions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Sat Jun 26 01:32:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jun 2010 23:32:55 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1277508576.27.0.7628772915.issue7989@psf.upfronthosting.co.za>
Message-ID: <1277508771.3175.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It is hard for me to judge the significance of maintenance burden, but
> others reported that having parallel versions of the io module was
> helpful.  I believe that with proper support in the regression test
> suit, it should be quite manageable.

For io, we find this quite manageable indeed, although it is quite more
complex and quirkier than datetime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Sat Jun 26 01:35:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jun 2010 23:35:32 +0000
Subject: [issue4963] mimetypes.guess_extension result changes after
	mimetypes.init()
In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>
Message-ID: <1277508932.15.0.547493685107.issue4963@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can't reproduce under Mandriva Linux:

>>> import mimetypes
>>> print(mimetypes.guess_extension('image/jpeg'))
.jpe
>>> mimetypes.init()
>>> print(mimetypes.guess_extension('image/jpeg'))
.jpe

The fact that it returns ".jpe" rather than ".jpg", however, could be a bug in itself (since the latter will really be expected by everyone, not the former).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4963>
_______________________________________

From report at bugs.python.org  Sat Jun 26 01:36:27 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 25 Jun 2010 23:36:27 +0000
Subject: [issue9083] At least some Tools utilities are still Python 2
In-Reply-To: <1277505524.04.0.87838503944.issue9083@psf.upfronthosting.co.za>
Message-ID: <1277508987.9.0.815845261227.issue9083@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Webchecker is so old, it should be deleted.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9083>
_______________________________________

From report at bugs.python.org  Sat Jun 26 01:47:44 2010
From: report at bugs.python.org (=?utf-8?q?Domen_Ko=C5=BEar?=)
Date: Fri, 25 Jun 2010 23:47:44 +0000
Subject: [issue9077] argparse does not handle arguments correctly after --
In-Reply-To: <1277422498.3.0.635108415577.issue9077@psf.upfronthosting.co.za>
Message-ID: <1277509664.1.0.523031395576.issue9077@psf.upfronthosting.co.za>


Domen Ko?ar <ielectric at gmail.com> added the comment:

Optparse behaved like that, how would one get the same results with argparse? That is by having variable positional parameters to command. And at the same time stop at --.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9077>
_______________________________________

From report at bugs.python.org  Sat Jun 26 01:58:01 2010
From: report at bugs.python.org (Greg Hazel)
Date: Fri, 25 Jun 2010 23:58:01 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
	locals and globals when they are not wanted
Message-ID: <1277510281.98.0.28764358767.issue1565525@psf.upfronthosting.co.za>


Greg Hazel <ghazel at users.sourceforge.net> added the comment:

This is still an issue.

The bug I'm reporting had been explained well, I thought, but I'll repeat it in summary:
There is no way to pass around traceback objects without holding references to an excessive number of objects.

Traceback raising typically does not use these references at all, so having some way to discard them would be very valuable. This allows storing and passing tracebacks between threads (or coroutines or async tasks) without dying quickly due to memory bloat. The simple-minded way to fix this is to allow the user to break the reference themselves.

Fixing this bug would invalidate the need for hacks like the one Twisted has come up with in their twisted.python.Failure object which stringifies the traceback object, making it impossible to re-raise the exception. Failure has a lot of re-implementations of Exceptions and traceback objects as a result.

----------
status: closed -> open
title: gc allowing tracebacks to eat up memory -> tracebacks eat up memory by holding references to locals and globals when they are not wanted
versions: +Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Sat Jun 26 01:59:43 2010
From: report at bugs.python.org (David Kirkby)
Date: Fri, 25 Jun 2010 23:59:43 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277510383.41.0.950773699088.issue9069@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Hi,
I had hoped to devote more time to this, but have been able to. I will do at the weekend. 

I would add I was building 64-bit, so adding the compiler flag -m64 on 'hawk' at least some of the time. Depending on your hardware, assuming you have installed !OpenSolaris as a Virtual machine in VirtualBox, it may be a 32 or 64-bit version of OpenSolaris. You need specific instructions from the processor for a 64-bit version and Sony in their infinite wisdom have disabled it on my Vaio laptop, so whilst I can install OpenSolaris as a 64-bit host operating system, any attempt to install a 64-bit guest will fail. 

If I don't chose to compile C99, then I need to add the compiler flag -DHAVE_DECL_ISFINITE=0. 

Otherwise I see:

Objects/object.c:1036: warning: implicit declaration of function 'isinf'

Undefined			first referenced
 symbol  			    in file
isfinite                            ./libpython2.6.so
ld: fatal: symbol referencing errors. No output written to python

Again, the Solaris man page says:

Mathematical Library Functions                       isfinite(3M)

NAME
     isfinite - test for finite value

SYNOPSIS
     c99 [ flag... ] file... -lm [ library... ]
     #include <math.h>

     int isfinite(real-floating x);

implying this is a C99 function. 

This conflicting behavior could be the result of what linker or assembler is being used. On SPARC, I use Sun linker and assembler. On OpenSolaris I use  the Sun linker, but the GNU assembler. 

I would have thought it was better to test this out with small bits of test code like I posted, rather than the complete Python source code. 

It might be better if I just create you an account on 'hawk'. Drop me an email at david <dot> kirkby {at} onetel |dot| net if you want. 

I can also get you an account at the University of Washington if you want on a Sun T5240 SPARC. I've not verified the problem on that machine, but I can do so. Just drop me an email with a preferred user name and I'll sort it out. 

The SPARC is very slow - despite it being a current model of a high end server. It is designed for a different sort of task to developing software. The CPUs are pretty slow (1167 MHz) and pretty dumb, but there are 128 hardware threads. In order to get any useful performance from the T5240, the code needs to be highly parallel or have lots of processes like on busy web servers. That is what 't2' is designed for - a high end web server. 

But 'hawk' is a pretty high spec PC which I run 24/7. 

Dave

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:00:06 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 26 Jun 2010 00:00:06 +0000
Subject: [issue9040] using MIMEApplication to attach a PDF raises a TypeError
	exception
In-Reply-To: <1277108429.25.0.109783634019.issue9040@psf.upfronthosting.co.za>
Message-ID: <1277510406.06.0.574318632466.issue9040@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9040>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:01:37 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jun 2010 00:01:37 +0000
Subject: [issue5045] imaplib should remove length of literal strings
In-Reply-To: <1232831861.1.0.505003833235.issue5045@psf.upfronthosting.co.za>
Message-ID: <1277510497.51.0.384891896112.issue5045@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

While IMAP is very much a live protocol, I do not know that any of the currently active core developers know much about it. Imaplib is based on the obsolete RFC2060 of Dev 1996, superseded by 3501 in March 2003, with 6 later updates. (I just found all this out to respond here.)

It is written in Python. If you take a look at the code, you will see that 7 people have contributed additions after the initial writing (and others may have contributed unlisted patches). Feel free to submit another by yourself.

----------
nosy: +tjreedy
type: behavior -> feature request
versions: +Python 3.2 -Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5045>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:02:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Jun 2010 00:02:57 +0000
Subject: [issue4640] optparse - dosn't distinguish between '--option' and
	'-option'
In-Reply-To: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za>
Message-ID: <1277510577.1.0.193607876163.issue4640@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I thought the OP might be saying that -debug didn't throw an error in 2.6.  test_optparse doesn't seem to have a test for this, so I wrote one.  But as far as I can see the correct error (invalid option -e, given that 'd' is defined) is thrown.  In 2.5, as well.

Rereading the initial post I understand the problem: his 'd' option takes an argument.  So 'ebug' becomes the option value, and thus no error is thrown.  Which is working as designed (that's how single letter options that take arguments usually work in Unix)

So, it is correct that this is not a bug.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4640>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:03:04 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jun 2010 00:03:04 +0000
Subject: [issue5026] [reopening] native build of python win32 using msys under
	both wine and native win32
In-Reply-To: <1232564904.43.0.416803942759.issue5026@psf.upfronthosting.co.za>
Message-ID: <1277510584.59.0.668547950282.issue5026@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5026>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:09:57 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jun 2010 00:09:57 +0000
Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za>
Message-ID: <1277510997.75.0.445537481631.issue5053@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5053>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:10:38 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jun 2010 00:10:38 +0000
Subject: [issue5054] CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly
	parsed
In-Reply-To: <1232897403.01.0.0399148938595.issue5054@psf.upfronthosting.co.za>
Message-ID: <1277511038.8.0.0847234386251.issue5054@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I hope that someone who knows more than me on this subject takes a look at this.

----------
nosy: +tjreedy
versions: +Python 3.2 -Python 2.4, Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5054>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:14:50 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 26 Jun 2010 00:14:50 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
	locals and globals when they are not wanted
Message-ID: <1277511290.59.0.328533245062.issue1565525@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I still don't understand the issue. You say that you want a traceback, but then you say you don't want the objects in the traceback. So what *precisely* is it that you want, and what is it that you don't want?

In any case, whatever the solution, it is likely a new feature, which aren't acceptable anymore for 2.x release. So please don't target this report for any 2.x version.

----------
versions: +Python 3.2 -Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:15:32 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jun 2010 00:15:32 +0000
Subject: [issue5147] MozillaCookieJar should not store leading whitespace in
	Magic header
In-Reply-To: <1233696240.85.0.475858035079.issue5147@psf.upfronthosting.co.za>
Message-ID: <1277511332.86.0.836328854469.issue5147@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

To apply this patch, it needs to be uploaded as a file xxx.dif.

Removing the idents looks correct even if trivial.

----------
keywords: +easy
nosy: +tjreedy
versions: +Python 3.2 -Python 2.4, Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5147>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:21:39 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jun 2010 00:21:39 +0000
Subject: [issue5146] threading via uid method doesn't work in imaplib
In-Reply-To: <1233691056.73.0.419384658246.issue5146@psf.upfronthosting.co.za>
Message-ID: <1277511699.96.0.473582635711.issue5146@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I confirmed that 3.1.2 has same 'old' text that the OP proposes to change. I cannot comment on the substance. Stage 'needs patch' means it needs a diff file. I do not know whether or how the imaplib is unit tested.

----------
keywords: +easy
nosy: +tjreedy
stage:  -> needs patch
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5146>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:25:13 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jun 2010 00:25:13 +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: <1277511913.38.0.731478942924.issue2942@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Roumen, does your patch in #3871 supercede this issue? Or is it impossible to tell without more info from the OP?

----------
nosy: +tjreedy
status: open -> pending
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2942>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:26:08 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jun 2010 00:26:08 +0000
Subject: [issue1718574] build_clib --build-clib/--build-temp option bugs
Message-ID: <1277511968.5.0.635385790906.issue1718574@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1718574>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:30:55 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jun 2010 00:30:55 +0000
Subject: [issue1519638] Unmatched Group issue - workaround
Message-ID: <1277512255.31.0.60052536687.issue1519638@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If I understand "This has been addressed in issue #2636.", this issue should be closed as, perhaps, out-of-date or duplicate, with 2636 as superceder. Correct?

----------
nosy: +tjreedy
versions:  -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1519638>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:31:32 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jun 2010 00:31:32 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1277512292.71.0.5358094943.issue4804@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2 -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:45:04 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jun 2010 00:45:04 +0000
Subject: [issue755286] Generate rpm filelist including directories
Message-ID: <1277513104.6.0.865405519804.issue755286@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This appears to be a feature request. That would normally now mean this issue is applicable to 3.2 only. Or is the rule different for disutils?

Should #755286 and #1035576 both remain open?

Tarek, does distutils2 work supercede these?

Nijel, could at least some of the earlier versions of the patch be removed (people normally do this when submitting better versions)?

----------
nosy: +tjreedy
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue755286>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:45:11 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jun 2010 00:45:11 +0000
Subject: [issue1035576] Add New RPM-friendly record option to setup.py
Message-ID: <1277513111.12.0.416882488199.issue1035576@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This appears to be a feature request. That would normally now mean applicable to 3.2 only. Or are the rule different for disutils?

Should #755286 and #1035576 both remain open?

Tarek, does distutils2 work supercede these?

----------
nosy: +tjreedy
versions: +Python 2.7 -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1035576>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:45:46 2010
From: report at bugs.python.org (Greg Hazel)
Date: Sat, 26 Jun 2010 00:45:46 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
	locals and globals when they are not wanted
Message-ID: <1277513146.97.0.871831127478.issue1565525@psf.upfronthosting.co.za>


Greg Hazel <ghazel at users.sourceforge.net> added the comment:

The objects I do want in the traceback are the objects necessary to print a traceback, but not the locals and globals of each frame.

For example:

def bar():
  x = "stuff"
  raise Exception("example!")
bar()

prints: 
Traceback (most recent call last):
  Line 4, in <module>
    bar()
  Line 3, in bar
    raise Exception("example!")
Exception: example!

There is no reason in that example to have a reference to "x" in the traceback, since it's not used in the output. This becomes important when I try to save a reference to the traceback object and raise it later:

import sys
def bar():
  x = "stuff"
  raise Exception("example!")
try:
  bar()
except:
  exc_info = sys.exc_info()
def foo(e):
  raise e[0], e[1], e[2]
# sometime possibly much later...
foo(exc_info)

Traceback (most recent call last):
  Line 12, in <module>
    foo(exc_info)
  Line 6, in <module>
    bar()
  Line 4, in bar
    raise Exception("example!")
Exception: example!


During that "sometime possibly much later..." comment, a reference to "x" is held, when it will not be used in printing the traceback later. So, I would not like to keep a reference to "x", and currently there is no way to do that without also dropping a reference to the data needed to print the traceback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:47:20 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jun 2010 00:47:20 +0000
Subject: [issue5212] Incorrect note about md5 in hmac module documentation
In-Reply-To: <1234312792.25.0.547667950303.issue5212@psf.upfronthosting.co.za>
Message-ID: <1277513240.15.0.90703958191.issue5212@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5212>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:50:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Jun 2010 00:50:47 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1277513447.32.0.295455083198.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> For io, we find this quite manageable indeed, although it is quite more
> complex and quirkier than datetime.

I don't understand how something being "more complex and quirkier," can make it more "manageable."

While admittedly simple, datetime has it's share of quirks.  (See issue 5516, for example.)  Most algorithms are simple, but ord2ymd, for one is quite instructional.  Another example is datetime.fromutc.  If there is a person other than Tim who understands how it works, I have not met him or her yet!

Note that we are not talking about writing something from scratch or bringing a 3rd party module to python library.  Tim's prototype needed almost no changes to pass 2.7 test suit and very few to get ported to 3.x.  The sandbox version is currently at r82218, a dozen small changesets from Tim's version of 6 years ago.

The only remaining task is to make the test suit run tests on both modules.  This is not entirely trivial, but it appears that test_datetime was originally designed to make tested classes replaceable.  Some housecleaning is needed to make it work, but I think it is doable.

I have not checked the C code coverage yet, but python code has 100% coverage as reported by trace module.  (Well, almost - there is exactly one line not covered and it actually contains a bug introduced by pypy!)

In any case, I do intend to maintain datetime.py while I am maintaining datetimemodule.c.  I will use it to prototype new features before implementing them in C.  I think having it in the main tree will increase its visibility and lower the barriers for future contributors.

Let's get back to this discussion after 2.7 is out and more developers can focus on 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:50:50 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jun 2010 00:50:50 +0000
Subject: [issue5212] Incorrect note about md5 in hmac module documentation
In-Reply-To: <1234312792.25.0.547667950303.issue5212@psf.upfronthosting.co.za>
Message-ID: <1277513450.92.0.238833844204.issue5212@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Are you proposing that the note be removed entirely (and ignore the results it is based on) or just reworded? If it were removed, I could imagine complaints. If reword, specifically how?

----------
assignee: georg.brandl -> docs at python
nosy: +docs at python, tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5212>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:58:05 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jun 2010 00:58:05 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
	locals and globals when they are not wanted
Message-ID: <1277513885.83.0.633781486242.issue1565525@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

To call this a bug for tracker purposes, there would have to be a specific discrepancy between doc promise and observed behavior. Every feature request fixes a 'design bug' ;-).

----------
resolution: wont fix -> 
stage:  -> needs patch
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Sat Jun 26 02:58:26 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 26 Jun 2010 00:58:26 +0000
Subject: [issue1519638] Unmatched Group issue - workaround
Message-ID: <1277513906.46.0.990416001836.issue1519638@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Issue #2636 resulted in the new regex module (also available on PyPI), so this issue is addressed by that, but there's no patch for the re module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1519638>
_______________________________________

From report at bugs.python.org  Sat Jun 26 03:09:59 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 26 Jun 2010 01:09:59 +0000
Subject: [issue1519638] Unmatched Group issue - workaround
Message-ID: <1277514599.01.0.795380975343.issue1519638@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It would be nice if you could port 'pieces' of #2636 to Python, in order to fix this and other bugs (and possibly add more features too).

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1519638>
_______________________________________

From report at bugs.python.org  Sat Jun 26 03:10:27 2010
From: report at bugs.python.org (Ajith Antony)
Date: Sat, 26 Jun 2010 01:10:27 +0000
Subject: [issue5147] MozillaCookieJar should not store leading whitespace in
	Magic header
In-Reply-To: <1233696240.85.0.475858035079.issue5147@psf.upfronthosting.co.za>
Message-ID: <1277514627.57.0.0137355163167.issue5147@psf.upfronthosting.co.za>


Ajith Antony <ajith.antony at gmail.com> added the comment:

ok. Patch attached.  I think.

----------
Added file: http://bugs.python.org/file17772/5147.dif

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5147>
_______________________________________

From report at bugs.python.org  Sat Jun 26 03:11:30 2010
From: report at bugs.python.org (Greg Hazel)
Date: Sat, 26 Jun 2010 01:11:30 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
	locals and globals when they are not wanted
Message-ID: <1277514690.25.0.39114662539.issue1565525@psf.upfronthosting.co.za>


Greg Hazel <ghazel at users.sourceforge.net> added the comment:

It seems this is partially addressed in a big red "Warning" section of the docs on sys.exc_info: http://docs.python.org/release/3.1/library/sys.html#sys.exc_info
and is captured in the "Open Issue: Garbage Collection" section for PEP-3134: http://www.python.org/dev/peps/pep-3134/

Bug or feature request, this a well understood and real issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Sat Jun 26 03:25:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Jun 2010 01:25:45 +0000
Subject: [issue4775] Incorrect documentation - UTC time
In-Reply-To: <1230603442.34.0.985593856271.issue4775@psf.upfronthosting.co.za>
Message-ID: <1277515545.93.0.783956984459.issue4775@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Python implementation of time functions certainly has nothing to do with UT1, which is the time as measured by (modern) sun dials.  The correct name would be POSIX time.  As explained in POSIX rationale,

"""
Coordinated Universal Time (UTC) includes leap seconds. However, in POSIX time (seconds since the Epoch), leap seconds are ignored (not applied) to provide an easy and compatible method of computing time differences. Broken-down POSIX time is therefore not necessarily UTC, despite its appearance.
""" -- http://www.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html

Nevertheless, UTC time is used throughout the standard.  For example,

"""
The gmtime() function shall convert the time in seconds since the Epoch pointed to by timer into a broken-down time, expressed as Coordinated Universal Time (UTC).
""" -- http://www.opengroup.org/onlinepubs/9699919799/functions/gmtime.html


I don't think there is much that can be improved in the Python documentation other than to stop referring to UTC as if it was a geographical location.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4775>
_______________________________________

From report at bugs.python.org  Sat Jun 26 03:26:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Jun 2010 01:26:02 +0000
Subject: [issue4963] mimetypes.guess_extension result changes after
	mimetypes.init()
In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>
Message-ID: <1277515562.75.0.63936650325.issue4963@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I can't reproduce this either, and without a reproducer we might as well close it.

Antoine it is possible that your fix for #5853 inadvertently fixed this, but I don't feel like untangling the logic of the module enough to figure it out :)  So I'm going to close it 'works for me'.  If S Arrowsmith can reproduce it with 2.7r2, we can reopen.

By the way, it produced 'jpe' for me, too...but, then, my system (Gentoo) /etc/mime.types file has 'jpe' as the first filetype for jpeg, so I don't think that association is Python's bug, per se. Though I may eventually have to address it in email6.  (Also by the way, I tried switching the order and passing in the modified file explicitly on the explicit init, but that didn't change the behavior).

----------
nosy: +r.david.murray
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4963>
_______________________________________

From report at bugs.python.org  Sat Jun 26 03:30:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Jun 2010 01:30:37 +0000
Subject: [issue4775] Incorrect documentation - UTC time
In-Reply-To: <1230603442.34.0.985593856271.issue4775@psf.upfronthosting.co.za>
Message-ID: <1277515837.61.0.850600184746.issue4775@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

"""
The gmtime() function shall convert the time in seconds since the Epoch pointed to by timer into a broken-down time, expressed as Coordinated Universal Time (UTC).
"""

In a technical sense, this is correct.  The result of gmtime() is UTC time, but it fails to mention that gmtime() will never produce tm_sec=60.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4775>
_______________________________________

From report at bugs.python.org  Sat Jun 26 03:35:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Jun 2010 01:35:26 +0000
Subject: [issue9077] argparse does not handle arguments correctly after --
In-Reply-To: <1277422498.3.0.635108415577.issue9077@psf.upfronthosting.co.za>
Message-ID: <1277516126.84.0.307686404039.issue9077@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Optparse left you to parse the arguments:

>>> import optparse
>>> p = optparse.OptionParser()
>>> p.add_option('--test', action="store_true")
<Option at 0x96521bc: --test>
>>> p.parse_args(['--test', 'foo', '--', 'foo2'])
(<Values at 0x97020a4: {'test': True}>, ['foo', 'foo2'])

As you can see, the 'foo' before the '--' is one of the returned arguments.  So argparse is behaving exactly the same way as optparse in this instance, except that, as I said, it is *parsing* the arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9077>
_______________________________________

From report at bugs.python.org  Sat Jun 26 03:51:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Jun 2010 01:51:50 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
	locals and globals when they are not wanted
Message-ID: <1277517110.15.0.461854103538.issue1565525@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Those two references have nothing to do with your request.  They are talking about cycles that get created by grabbing the traceback variable, and the fact that it may take a while before garbage collection reclaims them *after you have let go of the traceback reference*.  You are talking about wanting to release the locals in the stack frame and still hold on to the traceback.  Completely different issue.

Note that while the standard traceback print doesn't reference the locals in the frame, extended tracebacks such as cgitb do.  There is also a proposal to add such locals printing to the standard traceback.

I'm pretty sure this issue isn't going to go anywhere without a patch proposal, but before you work on that you might want to raise the idea on python-ideas and see if a wider audience thinks it is a good idea.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Sat Jun 26 04:10:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Jun 2010 02:10:53 +0000
Subject: [issue9040] using MIMEApplication to attach a PDF raises a TypeError
	exception
In-Reply-To: <1277108429.25.0.109783634019.issue9040@psf.upfronthosting.co.za>
Message-ID: <1277518253.07.0.235857293134.issue9040@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a duplicate of #4768, which has already been fixed.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> email.generator.Generator object bytes/str crash - b64encode() bug?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9040>
_______________________________________

From report at bugs.python.org  Sat Jun 26 04:18:28 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Jun 2010 02:18:28 +0000
Subject: [issue9024] PyDateTime_IMPORT macro incorrectly marked up
In-Reply-To: <4C1B32EB.6020900@timgolden.me.uk>
Message-ID: <1277518708.2.0.658150330819.issue9024@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r82236 - r82239.

----------
nosy: +belopolsky
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9024>
_______________________________________

From report at bugs.python.org  Sat Jun 26 04:21:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Jun 2010 02:21:35 +0000
Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders() always
	returns []
In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za>
Message-ID: <1277518895.4.0.269489992584.issue5053@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5053>
_______________________________________

From report at bugs.python.org  Sat Jun 26 04:21:49 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Jun 2010 02:21:49 +0000
Subject: [issue5054] CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly
	parsed
In-Reply-To: <1232897403.01.0.0399148938595.issue5054@psf.upfronthosting.co.za>
Message-ID: <1277518909.55.0.376946547656.issue5054@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5054>
_______________________________________

From report at bugs.python.org  Sat Jun 26 04:30:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Jun 2010 02:30:40 +0000
Subject: [issue1520662] support all of strftime(3)
Message-ID: <1277519440.18.0.400995469479.issue1520662@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

time.strftime does support all of the platform strftime(3) format codes.

----------
assignee:  -> belopolsky
nosy: +belopolsky
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1520662>
_______________________________________

From report at bugs.python.org  Sat Jun 26 04:31:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Jun 2010 02:31:58 +0000
Subject: [issue5146] threading via uid method doesn't work in imaplib
In-Reply-To: <1233691056.73.0.419384658246.issue5146@psf.upfronthosting.co.za>
Message-ID: <1277519518.83.0.166782237665.issue5146@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

A test suite skeleton was recently contributed; it's in the standard location (Lib/test/test_imaplib).

----------
nosy: +r.david.murray
stage: needs patch -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5146>
_______________________________________

From report at bugs.python.org  Sat Jun 26 04:35:59 2010
From: report at bugs.python.org (Tim Peters)
Date: Sat, 26 Jun 2010 02:35:59 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1277519759.51.0.89133160226.issue7989@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

> What would be your opinion on adding
> datetime.py to the main python tree
> today?

The funny thing is I can't remember why we bothered creating the C version - I would have been happiest leaving it all in Python.

Provided the test suite ensures the versions remain bug-compatible ;-), +0 from me for adding the Python version to the distro.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Sat Jun 26 04:43:13 2010
From: report at bugs.python.org (daniel hahler)
Date: Sat, 26 Jun 2010 02:43:13 +0000
Subject: [issue9084] vimrc: use matchall() instead of ":match" to allow
	multiple matches
In-Reply-To: <1277520193.82.0.447342355027.issue9084@psf.upfronthosting.co.za>
Message-ID: <1277520193.82.0.447342355027.issue9084@psf.upfronthosting.co.za>


New submission from daniel hahler <python-bugs at thequod.de>:

This patch fixes the vimrc example file to use matchadd() instead of ":match", so that the second "match" does not overwrite the first one.

This resulted in leading tabs not highlighted as BadWhitespace.

----------
components: Demos and Tools
messages: 108683
nosy: blueyed
priority: normal
severity: normal
status: open
title: vimrc: use matchall() instead of ":match" to allow multiple matches

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9084>
_______________________________________

From report at bugs.python.org  Sat Jun 26 04:43:45 2010
From: report at bugs.python.org (daniel hahler)
Date: Sat, 26 Jun 2010 02:43:45 +0000
Subject: [issue9084] vimrc: use matchall() instead of ":match" to allow
	multiple matches
In-Reply-To: <1277520193.82.0.447342355027.issue9084@psf.upfronthosting.co.za>
Message-ID: <1277520225.3.0.732391809528.issue9084@psf.upfronthosting.co.za>


Changes by daniel hahler <python-bugs at thequod.de>:


----------
keywords: +patch
Added file: http://bugs.python.org/file17773/python-vimrc-use-matchadd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9084>
_______________________________________

From report at bugs.python.org  Sat Jun 26 05:13:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Jun 2010 03:13:05 +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: <1277521985.7.0.585953596603.issue5109@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy: +belopolsky, mark.dickinson -Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5109>
_______________________________________

From report at bugs.python.org  Sat Jun 26 05:13:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Jun 2010 03:13:21 +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: <1277522001.52.0.0338733554479.issue5109@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5109>
_______________________________________

From report at bugs.python.org  Sat Jun 26 05:20:09 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 26 Jun 2010 03:20:09 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1277522409.56.0.910911594612.issue5516@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If you can articulate the benefits of splitting them apart, it would be worth making the case for doing so on python-dev. I'm having a hard time picturing what anyone could be doing such that it would break their code, but it's still definitely a backwards incompatible change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5516>
_______________________________________

From report at bugs.python.org  Sat Jun 26 05:20:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Jun 2010 03:20:27 +0000
Subject: [issue762963] timemodule.c: Python loses current timezone
Message-ID: <1277522427.18.0.224549082631.issue762963@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue762963>
_______________________________________

From report at bugs.python.org  Sat Jun 26 05:33:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Jun 2010 03:33:03 +0000
Subject: [issue9024] PyDateTime_IMPORT macro incorrectly marked up
In-Reply-To: <4C1B32EB.6020900@timgolden.me.uk>
Message-ID: <1277523183.43.0.948117992851.issue9024@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Should also add :cvar: tag to PyDateTimeAPI.

 http://docs.python.org/documenting/markup.html#information-units

Thanks, Ezio.

----------
assignee: docs at python -> belopolsky
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9024>
_______________________________________

From report at bugs.python.org  Sat Jun 26 07:14:34 2010
From: report at bugs.python.org (Greg Hazel)
Date: Sat, 26 Jun 2010 05:14:34 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
	locals and globals when they are not wanted
Message-ID: <1277529274.67.0.908307357254.issue1565525@psf.upfronthosting.co.za>


Greg Hazel <ghazel at users.sourceforge.net> added the comment:

It depends on how you look at it. Those two issues describe the surprising behavior of the same references I'm talking about here, when the lifetime of the traceback reference is only inside the same frame. This ticket describes the surprising behavior of those references when the lifetime of the traceback is any number of frames. My example eat_memory.py is much closer to the issue described in those links - the lifetime of the traceback object is insignificantly one frame higher, not the lifetime of the application.

Either way, a feature to discard those references would resolve both.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Sat Jun 26 09:23:14 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 26 Jun 2010 07:23:14 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1277536994.95.0.192100535015.issue7989@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

About importance to have a maintainable pure libraries and speedups for them. Believe it or not, but the only reason why Python 2.x did not get RFC 3339 implementation in standard library is that datetime module is in C. I hope everybody understands the importance of RFC 3339 nowadays.

About maintenance of C vs Python modules. Mercurial and Dulwich have notion of optional "speedups" for pure Python modules and it is a way to go for standard reference Python implementation. Such separation serves these projects very well, especially on Windows with no installed compiler to be able to insert debug statements into C code.

To easy maintenance I can see that only critical sections should be delegated to speedups, there should be 100% test coverage for both execution routes and performance benchmarks out of the box (i.e. developers should not think about how to compare code coverage or measure performance).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Sat Jun 26 09:27:55 2010
From: report at bugs.python.org (Tokio Kikuchi)
Date: Sat, 26 Jun 2010 07:27:55 +0000
Subject: [issue9085] Version number inconsistency in email package
In-Reply-To: <1277537275.59.0.8947906135.issue9085@psf.upfronthosting.co.za>
Message-ID: <1277537275.59.0.8947906135.issue9085@psf.upfronthosting.co.za>


New submission from Tokio Kikuchi <tkikuchi at users.sourceforge.net>:

Python 2.6 email version number is 4.0.1 while that of py2.5 is 4.0.2.
Clearly, py2.6 email is newer and should have higher number.

----------
components: Library (Lib)
messages: 108688
nosy: tkikuchi
priority: normal
severity: normal
status: open
title: Version number inconsistency in email package
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9085>
_______________________________________

From report at bugs.python.org  Sat Jun 26 09:59:30 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 26 Jun 2010 07:59:30 +0000
Subject: [issue4804] Python on Windows disables all C runtime library
	assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1277539170.5.0.636588722944.issue4804@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Why is this issue still open?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4804>
_______________________________________

From report at bugs.python.org  Sat Jun 26 10:08:54 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Jun 2010 08:08:54 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277539734.5.0.863461079182.issue9069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I would add I was building 64-bit, so adding the compiler flag -m64 on 'hawk' at least some of the time.

Ah;  that may be relevant.  Can you tell us exactly what command line you're using to build Python, and the values of any relavent environment variables?

> I would have thought it was better to test this out with small bits
> of test code like I posted, rather than the complete Python 
> source code. 

Unfortunately, the small bits of code don't really help: I get the same results as you for those, and I understand why those are failing:  copysign isn't declared (as you'll see if you add -Wall to your compilation line) so the compiler assumes it returns type 'int'.  This shouldn't happen with Python because its configure script defines __EXTENSIONS__, which ensures that copysign *is* declared when math.h is included.  Can you still reproduce the strange copysign results with your small examples when __EXTENSIONS__ is #define'd?

> This conflicting behavior could be the result of what linker or
> assembler is being used. On SPARC, I use Sun linker and assembler.
> On OpenSolaris I use  the Sun linker, but the GNU assembler.

I have the same setup (Sun linker, GNU assembler):

dickinsm at eratosthenes:~/release26-maint$ gcc-4.4 -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc-4.4.4/configure --prefix=/usr/local --program-suffix=-4.4 --with-mpfr-include=/usr/include/mpfr --with-gmp-include=/usr/include/gmp --with-as=/usr/bin/gas --with-gnu-as --with-ld=/usr/bin/ld --without-gnu-ld --enable-shared --enable-multilib --enable-languages=c,c++,objc
Thread model: posix
gcc version 4.4.4 (GCC)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 10:10:35 2010
From: report at bugs.python.org (Pearu Peterson)
Date: Sat, 26 Jun 2010 08:10:35 +0000
Subject: [issue1718574] build_clib --build-clib/--build-temp option bugs
Message-ID: <1277539835.88.0.07390378857.issue1718574@psf.upfronthosting.co.za>


Pearu Peterson <pearu at users.sourceforge.net> added the comment:

I wonder why this issue is not fixed already.
The fix would be trivial (add two `=`)
and the bug is due to a simple typo (the current
behavior is conflicting with the documentation
and options intentions, see `setup.py build_clib --help`).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1718574>
_______________________________________

From report at bugs.python.org  Sat Jun 26 10:13:58 2010
From: report at bugs.python.org (Konstantin Pelepelin)
Date: Sat, 26 Jun 2010 08:13:58 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1277540038.79.0.280383781983.issue3244@psf.upfronthosting.co.za>


Konstantin Pelepelin <konstantin.pelepelin at gmail.com> added the comment:

Did you test it against server-side form-data parser implementation? It will be useless if it won't work with most widespread implementations: PHP's and at least some others (consider some popular python web frameworks). 

MIME-compliance is not enough, because browsers send only subset of MIME format and server-side parsers don't expect bodies full of MIME features.

Particularly, I believe, most implementations don't expect any "Content-Transfer-Encoding", except "binary", because only 8-bit transfers are implemented in browsers, also you should check there will be no line-splitting and header-folding in headers and content, and make sure CR+LF (not plain LF, which is in patch) is always used.

----------
nosy: +checat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Sat Jun 26 10:24:39 2010
From: report at bugs.python.org (gonegown)
Date: Sat, 26 Jun 2010 08:24:39 +0000
Subject: [issue8988] import + coding = failure (3.1.2/win32)
In-Reply-To: <1276426235.15.0.873898512927.issue8988@psf.upfronthosting.co.za>
Message-ID: <1277540679.52.0.0401537977923.issue8988@psf.upfronthosting.co.za>


gonegown <nomedocac at gmail.com> added the comment:

@Amaury:
What you're saying about directory naming is right indeed.
But the case has begun from cyrillic letters in the NTFS path, which I do not use, but the users of my soft do. So putting the program into such directory makes the former unuseable; until the sources are in utf anyway.

I just ran this on another computer and it seemed to work with #coding in a.py. I then added this line to b.py and it failed. I played about 15 minutes inserting the line and removing and changing the directory name.
And I can tell the behaviour for me looks just random!
Though I noticed that addding #coding line to both sources fails more often.

You'll see:
--------
Traceback (most recent call last):
  File "F:\1home\?\u201e\a.py", line 1, in <module>
SyntaxError: None
--------

And what the hell is this u201e? That should have been a letter!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8988>
_______________________________________

From report at bugs.python.org  Sat Jun 26 10:25:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Jun 2010 08:25:19 +0000
Subject: [issue8896] email.encoders.encode_base64 sets payload to bytes,
	should set to str
In-Reply-To: <1275660438.53.0.968124979089.issue8896@psf.upfronthosting.co.za>
Message-ID: <1277540719.1.0.688680339569.issue8896@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8896>
_______________________________________

From report at bugs.python.org  Sat Jun 26 10:27:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Jun 2010 08:27:03 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1277540823.28.0.565063857396.issue3243@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +needs review
nosy: +orsenthil
stage: unit test needed -> patch review
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sat Jun 26 10:52:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Jun 2010 08:52:56 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277542376.82.0.918858075494.issue9069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

David, I'm still missing some easy answers that would really help.  Please could you answer the question about whether __EXTENSIONS__ is defined in your pyconfig.h; it would help determine what we should be investigating.

There shouldn't be any need for the -std=c99 option: the Python configure script defines __EXTENSIONS__ exactly to make these c99 functions available.  So either that isn't happening on your machines, in which case we should be looking for a problem with the configure script, or it *is* happening, in which case copysign is being properly declared on your machine and we have to look elsewhere (library mismatch? compiler optimization bug?) for the cause of failure.

Still no joy with an -m64 build.  I've attached a transcript showing the precise steps I used.

[I'm tempted to close this issue as 'works for me';  I'm not seeing any test_math failure in OpenSolaris, and neither is the Solaris/SPARC buildbot.]

----------
Added file: http://bugs.python.org/file17774/opensolaris_python_buildlog.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 10:56:13 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Jun 2010 08:56:13 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277542573.07.0.777704641367.issue9069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Stefan, thanks for the feedback.

I don't *think* this is related to issue 7281.  I thought we'd determined that that issue had nothing to do with copysign itself, and everything to do with what the signbit of the NaN returned by float("nan") happens to be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 11:13:53 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 26 Jun 2010 09:13:53 +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: <1277543633.82.0.466056040464.issue2942@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Terry, my patch in #3871  don't supersede this issue.
In patch to #3871 for mingw host  I use same work-around as for all other platforms
Lets see the code of setup.py methods configure_ctypes...(..) :
.....
            # Add .S (preprocessed assembly) to C compiler source extensions.
            self.compiler.src_extensions.append('.S')
.....

a) the patch to this issue didn't works for me;
b) issue in not only for GCC compiler for cygwin&mingw targets

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2942>
_______________________________________

From report at bugs.python.org  Sat Jun 26 11:43:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Jun 2010 09:43:03 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1277513447.32.0.295455083198.issue7989@psf.upfronthosting.co.za>
Message-ID: <1277545379.3156.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le samedi 26 juin 2010 ? 00:50 +0000, Alexander Belopolsky a ?crit :
> > For io, we find this quite manageable indeed, although it is quite more
> > complex and quirkier than datetime.
> 
> I don't understand how something being "more complex and quirkier,"
> can make it more "manageable."

I don't understand what you are arguing about. What is supposed to be
"more manageable"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Sat Jun 26 11:44:46 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 26 Jun 2010 09:44:46 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277542573.07.0.777704641367.issue9069@psf.upfronthosting.co.za>
Message-ID: <20100626094428.GA29306@yoda.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Mark Dickinson <report at bugs.python.org> wrote:
> I don't *think* this is related to issue 7281. I thought we'd determined that that issue
> had nothing to do with copysign itself, and everything to do with what the signbit of the
> NaN returned by float("nan") happens to be.

Yes, that's right. Also, to avoid spreading misinformation: The copysign(1.0, float("nan"))
behavior is actually the same after changing float_repr_style.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 12:00:43 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Jun 2010 10:00:43 +0000
Subject: [issue4640] optparse - dosn't distinguish between '--option' and
	'-option'
In-Reply-To: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za>
Message-ID: <1277546443.08.0.55311088473.issue4640@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Victor, I am interpreting your comment as saying 
> that this is not a bug.

No, I tried to explain that it is a bug :-)

add_option("-debug", "--debug", ...) and add_option("-debug", ...)  should raise an error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4640>
_______________________________________

From report at bugs.python.org  Sat Jun 26 12:05:39 2010
From: report at bugs.python.org (John Miller)
Date: Sat, 26 Jun 2010 10:05:39 +0000
Subject: [issue9086] Wrong linking terminology in windows FAQ
In-Reply-To: <1277546739.53.0.554976149521.issue9086@psf.upfronthosting.co.za>
Message-ID: <1277546739.53.0.554976149521.issue9086@psf.upfronthosting.co.za>


New submission from John Miller <gyuval at gmail.com>:

The 'How can I embed Python' section in the 'Python on Windows FAQ' (http://docs.python.org/faq/windows.html) uses wrong terms:
What the FAQ calls static linking and dynamic linking are actally two forms of dynamic linking - load-time dynamic linking and run-time dynamic linking, respectively.
Static linking means something else entirely - linking with a library that itself contains the implementation, i.e. there will be no usage of the DLL at all. Since the FAQ states that pythonNN.lib is just an import lib, static linking isn't really an option with this library.

Also the FAQ states that 'The drawback to dynamic linking is that your app won?t run if pythonNN.dll does not exist on your system'. This is misleading for two reasons:
- If the application uses the DLL, it won't run as expected if the DLL doesn't exist, regardless of how it loads the DLL. 
- Of the two linking options, load-time dynamic linking (what the FAQ refers to as static linking) is actually the one that handles the missing DLL more badly: The app will crash upon loading. If run-time dynamic linking is used, loading of the DLL happens in the application code, and it can handle it however it chooses to - it can inform the user, disable the feature that needs the DLL, etc.

----------
assignee: docs at python
components: Documentation
messages: 108700
nosy: docs at python, john.miller
priority: normal
severity: normal
status: open
title: Wrong linking terminology in windows FAQ
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9086>
_______________________________________

From report at bugs.python.org  Sat Jun 26 12:05:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Jun 2010 10:05:57 +0000
Subject: [issue4640] optparse - dosn't distinguish between '--option' and
	'-option'
In-Reply-To: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za>
Message-ID: <1277546757.46.0.135082433443.issue4640@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Reopen: add_option("-debug", "--debug", ...) and add_option("-debug", ...)  should raise an error and have a test.

----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4640>
_______________________________________

From report at bugs.python.org  Sat Jun 26 12:09:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Jun 2010 10:09:54 +0000
Subject: [issue4640] optparse doesn't distinguish between '--option' and
	'-option'
In-Reply-To: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za>
Message-ID: <1277546994.92.0.408242645814.issue4640@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Oh, we all focused on ?-debug is not recognized as --debug? and forgot that the bug report also said ?optparse does not complain when -debug is specified? (not sure if that meant ?added? or ?given on the command line?). We have to check if the bug still applies on 2.6, 2.7, 3.1 and 3.2.

----------
stage: committed/rejected -> unit test needed
title: optparse - dosn't distinguish between '--option' and '-option' -> optparse doesn't distinguish between '--option' and '-option'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4640>
_______________________________________

From report at bugs.python.org  Sat Jun 26 12:10:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Jun 2010 10:10:44 +0000
Subject: =?utf-8?q?=5Bissue4640=5D_optparse_doesn=E2=80=99t_disallow_adding_one-da?=
	=?utf-8?b?c2ggbG9uZyBvcHRpb25zICjigJwtb3B0aW9u4oCdKQ==?=
In-Reply-To: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za>
Message-ID: <1277547044.06.0.975618826432.issue4640@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: optparse doesn't distinguish between '--option' and '-option' -> optparse doesn?t disallow adding one-dash long options (?-option?)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4640>
_______________________________________

From report at bugs.python.org  Sat Jun 26 12:11:22 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 26 Jun 2010 10:11:22 +0000
Subject: [issue9086] Wrong linking terminology in windows FAQ
In-Reply-To: <1277546739.53.0.554976149521.issue9086@psf.upfronthosting.co.za>
Message-ID: <1277547082.41.0.326167544158.issue9086@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9086>
_______________________________________

From report at bugs.python.org  Sat Jun 26 12:39:26 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 26 Jun 2010 10:39:26 +0000
Subject: [issue4919] 2.6.1 build issues on solaris with SunStudio 12
In-Reply-To: <1231751691.61.0.918589692105.issue4919@psf.upfronthosting.co.za>
Message-ID: <1277548766.34.0.312274203743.issue4919@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I got this in an email from the OP.

"Hi,
I don't even remember this issue any more, but it seems to me that it is completely irrelevant that the error occurred with software that now how has a newer version.

That the essential fact is that the configure process makes mistakes creates a situation in which the includes fail to work properly.  The only relevance of Python x.x is that version DEMONSTRATES the error.

The philosophy that the apparent error need not be considered because right now it happens to a possibly obsolete version of software just means it will happen again.  Presumably, it will be just another hassle for those that test compile against sunstudio.  Using that sort of rationale to close issues is exactly how to make sunstudio into a piece of crap.

sdw
"

Could somebody pick this up?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4919>
_______________________________________

From report at bugs.python.org  Sat Jun 26 12:53:22 2010
From: report at bugs.python.org (S Arrowsmith)
Date: Sat, 26 Jun 2010 10:53:22 +0000
Subject: [issue4963] mimetypes.guess_extension result changes after
	mimetypes.init()
In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>
Message-ID: <1277549602.21.0.963492306403.issue4963@psf.upfronthosting.co.za>


S Arrowsmith <siona at chiark.greenend.org.uk> added the comment:

Sorry, still there:

Python 2.7rc2 (r27rc2:82137, Jun 26 2010, 11:27:59) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import mimetypes
>>> mimetypes.guess_extension('image/jpeg')
'.jpe'
>>> mimetypes.init()
>>> mimetypes.guess_extension('image/jpeg')
'.jpeg'

The fact that it's not reproducible on other Linux systems (I can't reproduce on the RedHat box I have to hand) might suggest there's something odd about Debian's mime.types . But I've just tried it passing init() the mime.types from the (working) RedHat box, and it's still producing the odd behaviour. (And I'm now on Debian 5.0, so it's not a Debian 4.0-specific issue either.) Wish I had a convenient Ubuntu install to try it on.

Bizarre.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4963>
_______________________________________

From report at bugs.python.org  Sat Jun 26 12:57:34 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 26 Jun 2010 10:57:34 +0000
Subject: [issue9085] Version number inconsistency in email package
In-Reply-To: <1277537275.59.0.8947906135.issue9085@psf.upfronthosting.co.za>
Message-ID: <1277549854.15.0.373735155358.issue9085@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

In python2.5 email version is 4.0.2
In python2.6 email version is 4.0.1
In python 2.7rc2 email version is 4.0.2

I think version number is wrong with 2.5, it should have been 4.0.0 rather than 4.0.2.

David: Adding you as nosy so as you can confirm upon this.

----------
nosy: +l0nwlf, r.david.murray
versions: +Python 2.5 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9085>
_______________________________________

From report at bugs.python.org  Sat Jun 26 13:05:00 2010
From: report at bugs.python.org (David Kirkby)
Date: Sat, 26 Jun 2010 11:05:00 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277550300.2.0.243862476971.issue9069@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Hi,

__EXTENSIONS__ is defined to 1. 


Give me an hour, and I'll attach a log.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 13:09:41 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 26 Jun 2010 11:09:41 +0000
Subject: [issue4963] mimetypes.guess_extension result changes after
	mimetypes.init()
In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>
Message-ID: <1277550581.23.0.180378180428.issue4963@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Can't reproduce.

16:36:36 l0nwlf-MBP:~$ python2.7
Python 2.7rc2+ (trunk:82148M, Jun 22 2010, 10:32:46) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import mimetypes
>>> mimetypes.guess_extension('image/jpeg')
'.jpe'
>>> mimetypes.init()
>>> mimetypes.guess_extension('image/jpeg')
'.jpe'
>>> 

Results were same in python2.5, 2.6 too. I wonder whether this is machine specific or distro specific.

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4963>
_______________________________________

From report at bugs.python.org  Sat Jun 26 13:11:02 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 26 Jun 2010 11:11:02 +0000
Subject: [issue9085] Version number inconsistency in email package
In-Reply-To: <1277549854.15.0.373735155358.issue9085@psf.upfronthosting.co.za>
Message-ID: <20100626111050.GE11404@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I doubt we would care about changing the version number in Python 2.5.
Python 2.5 *might be* only in Security Fix mode and this does not
qualify for a change in Python 2.5. So, just leave it as it is and
don't rely on the version number is in the answer.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9085>
_______________________________________

From orsenthil at gmail.com  Sat Jun 26 13:10:50 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Sat, 26 Jun 2010 16:40:50 +0530
Subject: [issue9085] Version number inconsistency in email package
In-Reply-To: <1277549854.15.0.373735155358.issue9085@psf.upfronthosting.co.za>
References: <1277537275.59.0.8947906135.issue9085@psf.upfronthosting.co.za>
	<1277549854.15.0.373735155358.issue9085@psf.upfronthosting.co.za>
Message-ID: <20100626111050.GE11404@remy>

I doubt we would care about changing the version number in Python 2.5.
Python 2.5 *might be* only in Security Fix mode and this does not
qualify for a change in Python 2.5. So, just leave it as it is and
don't rely on the version number is in the answer.

From report at bugs.python.org  Sat Jun 26 13:12:26 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 26 Jun 2010 11:12:26 +0000
Subject: [issue9085] Version number inconsistency in email package
In-Reply-To: <1277537275.59.0.8947906135.issue9085@psf.upfronthosting.co.za>
Message-ID: <1277550746.89.0.355757515508.issue9085@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9085>
_______________________________________

From report at bugs.python.org  Sat Jun 26 13:18:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Jun 2010 11:18:17 +0000
Subject: [issue4919] 2.6.1 build issues on solaris with SunStudio 12
In-Reply-To: <1231751691.61.0.918589692105.issue4919@psf.upfronthosting.co.za>
Message-ID: <1277551097.17.0.785524718027.issue4919@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The original report isn't very useful; without further constructive feedback from the OP I agree this issue should be closed.  For example:

> The HUGE_VAL aka infinity issue is solved if the LIB is -lsunmath -lm
> instead of just -lm

What is this mysterious 'HUGE_VAL aka infinity' issue---it's not made clear anywhere that I can see?  A build failure, I assume (from the title).  But at what stage of the build?  What's the revelant error message (and surrounding context from the build output)?  Exactly how was Python configured and built?

Is there some context I'm missing, like an attachment containing a build log or something?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4919>
_______________________________________

From report at bugs.python.org  Sat Jun 26 13:23:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Jun 2010 11:23:09 +0000
Subject: [issue4919] 2.6.1 build issues on solaris with SunStudio 12
In-Reply-To: <1231751691.61.0.918589692105.issue4919@psf.upfronthosting.co.za>
Message-ID: <1277551389.05.0.252991596303.issue4919@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

BTW, if there *is* still a problem with building Python 2.6 then closing as 'out of date' wouldn't be appropriate (yet).  2.6 is still receiving bugfixes at this point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4919>
_______________________________________

From report at bugs.python.org  Sat Jun 26 13:28:44 2010
From: report at bugs.python.org (David Kirkby)
Date: Sat, 26 Jun 2010 11:28:44 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277551724.3.0.838397905976.issue9069@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Here's a build done the same way as you. This gives the same result as you here. 

But an attempt to run the test suite fails because of _socket. I need to patch that in order that I can run the test suite. 

See http://bugs.python.org/issue8852

----------
Added file: http://bugs.python.org/file17775/build-with_socket-failure.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 13:30:08 2010
From: report at bugs.python.org (David Kirkby)
Date: Sat, 26 Jun 2010 11:30:08 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277551808.31.0.395784548385.issue9069@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Here's the header file that gets created

----------
Added file: http://bugs.python.org/file17776/pyconfig.h

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 13:59:47 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 26 Jun 2010 11:59:47 +0000
Subject: [issue3966] Win32ErrorTests from test_os.py
In-Reply-To: <1222367750.46.0.164641457334.issue3966@psf.upfronthosting.co.za>
Message-ID: <1277553587.04.0.313286718339.issue3966@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Here is the code from test_os.py for Python 2.6.5.

def test_mkdir(self):
    self.assertRaises(WindowsError, os.chdir, test_support.TESTFN)
def test_access(self):
    self.assertRaises(WindowsError, os.utime, test_support.TESTFN, 0)
def test_chmod(self):
    self.assertRaises(WindowsError, os.utime, test_support.TESTFN, 0)

The OP is saying shouldn't there be calls to os.mkdir, os.access and os.chmod respectively?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3966>
_______________________________________

From report at bugs.python.org  Sat Jun 26 14:07:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Jun 2010 12:07:38 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277554058.52.0.336624060699.issue9069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the logs.

So if you apply the issue8852 patch, and run the test suite, does test_float still fail?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 14:14:10 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 26 Jun 2010 12:14:10 +0000
Subject: [issue4299] 3.0rc2.msi Install Fails (Error Code 2755)
In-Reply-To: <1226416797.61.0.972163132872.issue4299@psf.upfronthosting.co.za>
Message-ID: <1277554450.47.0.561853458014.issue4299@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I think this should be closed as it refers to Python 3.0rc2 and the error code given is Windows MSI specific, not Python.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4299>
_______________________________________

From report at bugs.python.org  Sat Jun 26 14:18:15 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Jun 2010 12:18:15 +0000
Subject: [issue4299] 3.0rc2.msi Install Fails (Error Code 2755)
In-Reply-To: <1226416797.61.0.972163132872.issue4299@psf.upfronthosting.co.za>
Message-ID: <1277554695.57.0.115912456561.issue4299@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Agreed;  Closing.  Though if the OP still has this problem with the MSI installs for current versions of Python (2.6, 2.7, 3.1 or 3.2), then we might want to reopen and investigate further.

----------
nosy: +loewis, mark.dickinson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4299>
_______________________________________

From report at bugs.python.org  Sat Jun 26 14:20:22 2010
From: report at bugs.python.org (Steve Holden)
Date: Sat, 26 Jun 2010 12:20:22 +0000
Subject: [issue8943] Bug in InteractiveConsole
In-Reply-To: <1276014263.34.0.524334073977.issue8943@psf.upfronthosting.co.za>
Message-ID: <1277554822.54.0.045464665753.issue8943@psf.upfronthosting.co.za>


Changes by Steve Holden <steve at holdenweb.com>:


----------
nosy: +holdenweb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8943>
_______________________________________

From report at bugs.python.org  Sat Jun 26 14:22:42 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 26 Jun 2010 12:22:42 +0000
Subject: [issue4655] during Python installation,
	setup.py should not use .pydistutils.cfg
In-Reply-To: <1229218265.16.0.0523897864618.issue4655@psf.upfronthosting.co.za>
Message-ID: <1277554962.17.0.327203973874.issue4655@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

Could an installation guru please take a look at this?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4655>
_______________________________________

From report at bugs.python.org  Sat Jun 26 14:25:35 2010
From: report at bugs.python.org (David Kirkby)
Date: Sat, 26 Jun 2010 12:25:35 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277555135.57.0.696564460121.issue9069@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Sorry, I seem to have wasted a lot of your time here. 

Python was built from a script which applied some patches - including that one that allows _socket to build. Without that (which is not commit to python and I'm told it might not be done this year), its impossible to run the test suite. 

It looks like of the patches has messed up with test_float. 

Unfortunately, if I just apply the patch at issue8852, then the test suite hangs at:

test_posix

It's used 48 minutes of CPU time on a 3.33 GHz Xeon as I write, passing most tests up to test_posix, but hanging there. 

Sorry to have wasted your time. 


BTW, are you able to run the full test suite, or does the test suite simply not run at all? 

Dave

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 14:27:50 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 26 Jun 2010 12:27:50 +0000
Subject: [issue4655] during Python installation,
	setup.py should not use .pydistutils.cfg
In-Reply-To: <1229218265.16.0.0523897864618.issue4655@psf.upfronthosting.co.za>
Message-ID: <1277555270.74.0.982004301843.issue4655@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4655>
_______________________________________

From report at bugs.python.org  Sat Jun 26 14:33:32 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 26 Jun 2010 12:33:32 +0000
Subject: [issue4945] json checks True/False by identity, not boolean value
In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za>
Message-ID: <1277555612.76.0.0905642528923.issue4945@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

As a patch has been provided can't this be moved forward?  The Python versions also need updating.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4945>
_______________________________________

From report at bugs.python.org  Sat Jun 26 14:56:23 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 26 Jun 2010 12:56:23 +0000
Subject: [issue8988] import + coding = failure (3.1.2/win32)
In-Reply-To: <1276426235.15.0.873898512927.issue8988@psf.upfronthosting.co.za>
Message-ID: <1277556983.62.0.685644227822.issue8988@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> File "F:\1home\?\u201e\a.py", line 1, in <module>
> And what the hell is this u201e? That should have been a letter!

It's probably this symbol: http://www.eki.ee/letter/chardata.cgi?ucode=201e
but it has no representation in the console windows you are using; try "import sys; print(sys.stderr.encoding)" to print the code page used by your console.
In error messages, Python replaces unpritable characters with their "escaped" form: \uXXXX where XXXX is the character number.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8988>
_______________________________________

From report at bugs.python.org  Sat Jun 26 15:00:19 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 26 Jun 2010 13:00:19 +0000
Subject: [issue8988] import + coding = failure (3.1.2/win32)
In-Reply-To: <1276426235.15.0.873898512927.issue8988@psf.upfronthosting.co.za>
Message-ID: <1277557219.61.0.168238309675.issue8988@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> But the case has begun from cyrillic letters in the NTFS path, 
> which I do not use, but the users of my soft do. 
> So putting the program into such directory makes the former unuseable;
> until the sources are in utf anyway.

I agree that cyrillic letters in the path makes the program unusable. This is the bug to fix, and the zip file you attached is a good test case.

But I still don't see how "the sources are in utf" can influence this. Please show me!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8988>
_______________________________________

From report at bugs.python.org  Sat Jun 26 15:24:53 2010
From: report at bugs.python.org (David Kirkby)
Date: Sat, 26 Jun 2010 13:24:53 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1277558693.68.0.686573289516.issue8852@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

I think I spoke too soon. 

I just downloaded the 2.7.rc2. Using both 32 and 64-bit builds, with the only patch being that I attached to issue8852  some months back, the problem occurs again. 

test_float
test test_float failed -- Traceback (most recent call last):
  File "/export/home/drkirkby/Python-2.7rc2/Lib/test/test_float.py", line 1297, in test_roundtrip
    self.identical(-x, roundtrip(-x))
  File "/export/home/drkirkby/Python-2.7rc2/Lib/test/test_float.py", line 907, in identical
    self.fail('%r not identical to %r' % (x, y))
AssertionError: -0.0 not identical to 0.0

test_fnmatch
test_fork1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Sat Jun 26 15:24:57 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Jun 2010 13:24:57 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277558697.93.0.398639519003.issue9069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I see the same _socket build failure as you do;  but with the issue 8852 patch, I can run the test suite.

It did spend quite a while in test_posix, but the test eventually finished (and failed).  I didn't get to the end of the test run, unfortunately, because I ran out of disk space.  (4 virtual machines on a small laptop is pushing it a bit. :)

It's possible that the test_posix failure was due to running out of space, I guess.  Anyway, that's a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 15:25:45 2010
From: report at bugs.python.org (David Kirkby)
Date: Sat, 26 Jun 2010 13:25:45 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1277558745.71.0.415633628858.issue8852@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Sorry, I put that note on the wrong issue!

ignore it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Sat Jun 26 15:26:37 2010
From: report at bugs.python.org (David Kirkby)
Date: Sat, 26 Jun 2010 13:26:37 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277558797.78.0.261315435777.issue9069@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

test_float
test test_float failed -- Traceback (most recent call last):
  File "/export/home/drkirkby/Python-2.7rc2/Lib/test/test_float.py", line 1297, in test_roundtrip
    self.identical(-x, roundtrip(-x))
  File "/export/home/drkirkby/Python-2.7rc2/Lib/test/test_float.py", line 907, in identical
    self.fail('%r not identical to %r' % (x, y))
AssertionError: -0.0 not identical to 0.0

test_fnmatch
test_fork1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 15:28:03 2010
From: report at bugs.python.org (David Kirkby)
Date: Sat, 26 Jun 2010 13:28:03 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277558883.89.0.227725330962.issue9069@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Sorry, I missed out the comment there. 

This is failing for me, in boht 32 and 64-bit builds with Python-2.7rc2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 16:40:48 2010
From: report at bugs.python.org (scott wedel)
Date: Sat, 26 Jun 2010 14:40:48 +0000
Subject: [issue4919] 2.6.1 build issues on solaris with SunStudio 12
In-Reply-To: <1277548766.34.0.312274203743.issue4919@psf.upfronthosting.co.za>
Message-ID: <AANLkTilywy8LCV8ILcX6o2tAI0kiwV7b_sZmTRtT_IEK@mail.gmail.com>


scott wedel <taverngeek at gmail.com> added the comment:

You all take 7 months to first look at the issue and then decide that you'd
like more information because the initial submission was incomplete?

Oh well,  Suit yourself.  Doesn't matter to me.  I've already stopped using
sunstudio.  That python build was one of the last things I did on Solaris
which I had been actively using for 20 years, but some device driver issues
have made it no longer worth the effort.

sdw

On Sat, Jun 26, 2010 at 4:39 AM, Mark Lawrence <report at bugs.python.org>wrote:

>
> Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:
>
> I got this in an email from the OP.
>
> "Hi,
> I don't even remember this issue any more, but it seems to me that it is
> completely irrelevant that the error occurred with software that now how has
> a newer version.
>
> That the essential fact is that the configure process makes mistakes
> creates a situation in which the includes fail to work properly.  The only
> relevance of Python x.x is that version DEMONSTRATES the error.
>
> The philosophy that the apparent error need not be considered because right
> now it happens to a possibly obsolete version of software just means it will
> happen again.  Presumably, it will be just another hassle for those that
> test compile against sunstudio.  Using that sort of rationale to close
> issues is exactly how to make sunstudio into a piece of crap.
>
> sdw
> "
>
> Could somebody pick this up?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4919>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file17777/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4919>
_______________________________________
-------------- next part --------------
You all take 7 months to first look at the issue and then decide that you&#39;d like more information because the initial submission was incomplete?<br><br>Oh well,?? Suit yourself.?? Doesn&#39;t matter to me.?? I&#39;ve already stopped using sunstudio.?? That python build was one of the last things I did on Solaris which I had been actively using for 20 years, but some device driver issues have made it no longer worth the effort.<br>
<br>sdw<br><br><br><div class="gmail_quote">On Sat, Jun 26, 2010 at 4:39 AM, 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;">
<div class="im"><br>
Mark Lawrence &lt;<a href="mailto:breamoreboy at yahoo.co.uk">breamoreboy at yahoo.co.uk</a>&gt; added the comment:<br>
<br>
</div>I got this in an email from the OP.<br>
<br>
&quot;Hi,<br>
I don&#39;t even remember this issue any more, but it seems to me that it is completely irrelevant that the error occurred with software that now how has a newer version.<br>
<br>
That the essential fact is that the configure process makes mistakes creates a situation in which the includes fail to work properly. ??The only relevance of Python x.x is that version DEMONSTRATES the error.<br>
<br>
The philosophy that the apparent error need not be considered because right now it happens to a possibly obsolete version of software just means it will happen again. ??Presumably, it will be just another hassle for those that test compile against sunstudio. ??Using that sort of rationale to close issues is exactly how to make sunstudio into a piece of crap.<br>

<br>
sdw<br>
&quot;<br>
<br>
Could somebody pick this up?<br>
<br>
----------<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/issue4919" target="_blank">http://bugs.python.org/issue4919</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Sat Jun 26 16:42:20 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 26 Jun 2010 14:42:20 +0000
Subject: [issue4919] 2.6.1 build issues on solaris with SunStudio 12
In-Reply-To: <1231751691.61.0.918589692105.issue4919@psf.upfronthosting.co.za>
Message-ID: <1277563340.43.0.641178566862.issue4919@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4919>
_______________________________________

From report at bugs.python.org  Sat Jun 26 16:57:02 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Jun 2010 14:57:02 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277564222.1.0.33225783909.issue9069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay---this one I *can* reproduce. :)

I'm going to call it a gcc optimization bug.  Specifically, it seems to be a bug involving gcc's builtin version of the copysign function.

When I build a current svn trunk checkout (r82245) with:

  CC='gcc-4.4 -m64' ./configure && make

I get the wrong result:

Python 2.7rc2+ (trunk:82245, Jun 26 2010, 05:35:07) 
[GCC 4.4.4] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> (-0.0).hex()
'0x0.0p+0'

But when building with either:

    CC='gcc-4.4 -m64 -fno-builtin-copysign' ./configure && make

or

    CC='gcc-4.4 -m64' ./configure --with-pydebug && make

I get the expected results.  If I have time I'll investigate further and see if I can generate the bug from smaller code.  At any rate, I don't think this is something that can sensibly be fixed in Python itself, so I think this issue should be closed, and a bug filed upstream if necessary.

I also can't see a good reason why this bug would be specific to OpenSolaris.  Does anyone have gcc-4.4.4 available to test this on OS X, Linux or *BSD?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 17:08:52 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Jun 2010 15:08:52 +0000
Subject: [issue3385] cPickle to pickle conversion in py3k missing methods
In-Reply-To: <1216234897.3.0.336444541402.issue3385@psf.upfronthosting.co.za>
Message-ID: <1277564932.47.0.843259496573.issue3385@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Do I understand correctly that the issue is that python Pickler class has dispatch attribute but C Pickler does not?  The add_dispatch_check-0.patch patch does not seem to add class attribute, it adds an instance attribute instead.

I also noticed that there are many more class attributes that only Python implementation has:

>>> for x in dir(pickle._Pickler):
...    if not (x.startswith('_') or hasattr(pickle.Pickler, x)):
...       print(x)
... 
dispatch
get
memoize
put
save
save_bool
save_bytes
save_dict
save_float
save_global
save_list
save_long
save_none
save_pers
save_reduce
save_str
save_tuple


The save_* methods are clearly internal and should probably be renamed to begin with __ unless they are intended to be overridden by Pickler subclases

----------
nosy: +belopolsky
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/issue3385>
_______________________________________

From report at bugs.python.org  Sat Jun 26 17:36:14 2010
From: report at bugs.python.org (David Kirkby)
Date: Sat, 26 Jun 2010 15:36:14 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277566574.76.0.287617960044.issue9069@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

I'm glad you can reproduce it! 

I can understand you wanting to close it in this case. I've no problem with that. 

To me at least, it does not seem anywhere near as serious as the other problem. 

I will try it on Linux though. I have access to reasonably decent (24 core) Linux box, so I'll try it on that. But it means a lot of messing around, downloading mpir, mpfr, possibly newer versions of the GNU binutils etc. Not a 5 minute job. The weather here in the UK is too nice to site behind a computer screen!

Dave

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 18:12:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Jun 2010 16:12:09 +0000
Subject: [issue762963] timemodule.c: Python loses current timezone
Message-ID: <1277568729.69.0.675946497998.issue762963@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I agree with Martin.  A proper fix would be to use tm_gmtoff explicitly where available and carry it in time.struct_time.

See issue1647654 and issue4086.

Interestingly, the issue does not show up on OSX, which being a BSD derivative does have tm_gmtoff in struct tm.

While I don't have an affected system to test the patch, it does not look right to me.  I would think mktime() should be called after PyArg_Parse, not before because tm_gmtoff may be different for different times.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue762963>
_______________________________________

From report at bugs.python.org  Sat Jun 26 18:15:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Jun 2010 16:15:31 +0000
Subject: [issue762963] timemodule.c: Python loses current timezone
Message-ID: <1277568931.36.0.667819439172.issue762963@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Another related issue is issue1667546.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue762963>
_______________________________________

From report at bugs.python.org  Sat Jun 26 18:32:12 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 26 Jun 2010 16:32:12 +0000
Subject: [issue7673] audioop: check that length is a multiple of the size
In-Reply-To: <1263171957.43.0.71285781195.issue7673@psf.upfronthosting.co.za>
Message-ID: <1277569932.96.0.0786894942469.issue7673@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-2089 claims that this issue is about security vulnerability. This problem seems to also affect at least Python 2.6.

----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7673>
_______________________________________

From report at bugs.python.org  Sat Jun 26 19:11:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Jun 2010 17:11:36 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277572295.99.0.918043204738.issue9069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's some minimal failing code.


// Compile with:
// gcc-4.4 -m64 -fno-inline -g -O3 copysign_bug.c -o copysign_bug

#include <math.h>
#include <stdio.h>

int copysign_bug(double x)
{
  if (x && (x * 0.5 == x))
    return 1;
  if (copysign(1.0, x) < 0.0)
    return 2;
  else
    return 3;
}

int main(void) {
  double x;
  x = -0.0;
  printf("copysign_bug(%.17g) = %d\n", x, copysign_bug(x));

  x = 0.0;
  printf("copysign_bug(%.17g) = %d\n", x, copysign_bug(x));

  return 0;
}


This produces the output:

copysign_bug(-0) = 3
copysign_bug(0) = 3

I would expecting to see:

copysign_bug(-0) = 2
copysign_bug(0) = 3

I've reported this at:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44683

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 19:17:24 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 26 Jun 2010 17:17:24 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277572644.39.0.7349535925.issue9069@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Mark, gcc-4.4 on Fedora 12 is ok:

[stefan at fedora-amd64 trunk]$ ./python 
Python 2.7rc2+ (trunk:82245M, Jun 26 2010, 13:09:14) 
[GCC 4.4.3 20100127 (Red Hat 4.4.3-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (-0.0).hex()
'-0x0.0p+0'



As a general remark, from what I hear on the gmp-bugs list, the
newer gcc versions often seem to have problems on Solaris.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 19:26:06 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 26 Jun 2010 17:26:06 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277573166.29.0.673608311296.issue9069@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Fedora 12: copysign-bug varies wildly ((GCC) 4.4.3 20100127 (Red Hat 4.4.3-4)):

[stefan at fedora-amd64 trunk]$ gcc  -O0 copysign_bug.c -o copysign_bug
[stefan at fedora-amd64 trunk]$ ./copysign_bug 
copysign_bug(-0) = 2
copysign_bug(0) = 3

[stefan at fedora-amd64 trunk]$ gcc  -O2 copysign_bug.c -o copysign_bug
[stefan at fedora-amd64 trunk]$ ./copysign_bug 
copysign_bug(-0) = 3
copysign_bug(0) = 3

[stefan at fedora-amd64 trunk]$ gcc  -O3 copysign_bug.c -o copysign_bug
[stefan at fedora-amd64 trunk]$ ./copysign_bug 
copysign_bug(-0) = 2
copysign_bug(0) = 3

[stefan at fedora-amd64 trunk]$ gcc  -O3 -fno-inline copysign_bug.c -o copysign_bug
[stefan at fedora-amd64 trunk]$ ./copysign_bug 
copysign_bug(-0) = 3
copysign_bug(0) = 3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 19:52:42 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Jun 2010 17:52:42 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277574762.0.0.868009599805.issue9069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks Stefan.

The bug apparently exists in gcc-4.5 on OS X as well.  I'll update the gcc bug report.

newton:~ dickinsm$ gcc-mp-4.5 -fno-inline -O3 copysign_bug.c -o copysign_bug && ./copysign_bug
copysign_bug(-0) = 3
copysign_bug(0) = 3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sat Jun 26 20:04:33 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 26 Jun 2010 18:04:33 +0000
Subject: [issue9087] json docstrings on 3.x still use 'unicode' and 'str'
In-Reply-To: <1277575473.27.0.695567265942.issue9087@psf.upfronthosting.co.za>
Message-ID: <1277575473.27.0.695567265942.issue9087@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

In the json package there are still lot of docstrings that refer to 'unicode' and 'str' instead of 'str' and 'bytes' (AFAIU 'bytes' are not even allowed anymore in several places, so there should probably be only 'str' there).
A few examples:
* in json/__init__.py:
  If ``skipkeys`` is true then ``dict`` keys that are not basic types (``str``, ``unicode``, ``int``, ``float``, ``bool``, ``None``) will be skipped instead of raising a ``TypeError``.
  If ``ensure_ascii`` is false, then the some chunks written to ``fp`` may be ``unicode`` instances, subject to normal Python ``str`` to ``unicode`` coercion rules.

* in json/decoder.py:
  Decode a JSON document from ``s`` (a ``str`` or ``unicode`` beginning with a JSON document) and return a 2-tuple of the Python representation and the index in ``s`` where the document ended.

* in json/encoder.py:
  If ensure_ascii is true, the output is guaranteed to be str objects with all incoming unicode characters escaped.  If ensure_ascii is false, the output will be unicode object.


Note that the documentation (Doc/library/json.rst) seems already updated, so update the docstrings should be enough.

----------
assignee: bob.ippolito
components: Documentation, Library (Lib)
messages: 108738
nosy: bob.ippolito, ezio.melotti
priority: normal
severity: normal
stage: needs patch
status: open
title: json docstrings on 3.x still use 'unicode' and 'str'
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9087>
_______________________________________

From report at bugs.python.org  Sat Jun 26 20:38:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Jun 2010 18:38:16 +0000
Subject: [issue9085] Version number inconsistency in email package
In-Reply-To: <1277537275.59.0.8947906135.issue9085@psf.upfronthosting.co.za>
Message-ID: <1277577496.77.0.75677531502.issue9085@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

What appears to have happened is that the 2.5 maintenance release was branched *before* the release was cut, but Barry bumped the version of the email package after the branch and did not backport that bump to trunk.  Between 2.5 and 2.6, email did not change significantly (just some bug fixes).

So, what we can do is bump the version to 4.0.2 in 2.6maint, and
further bump it to 4.0.3 for 2.7 (where there is a behavior change from 4.0.2).  Not perfect, but the best we can do.

----------
assignee:  -> r.david.murray
resolution: wont fix -> accepted
stage: committed/rejected -> needs patch
status: closed -> open
type:  -> behavior
versions: +Python 2.6, Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9085>
_______________________________________

From report at bugs.python.org  Sat Jun 26 20:59:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Jun 2010 18:59:55 +0000
Subject: [issue9024] PyDateTime_IMPORT macro incorrectly marked up
In-Reply-To: <4C1B32EB.6020900@timgolden.me.uk>
Message-ID: <1277578795.84.0.60788678296.issue9024@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r82251.  Thanks for the patch, Tim.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9024>
_______________________________________

From report at bugs.python.org  Sat Jun 26 20:59:58 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 26 Jun 2010 18:59:58 +0000
Subject: [issue9084] vimrc: use matchall() instead of ":match" to allow
	multiple matches
In-Reply-To: <1277520193.82.0.447342355027.issue9084@psf.upfronthosting.co.za>
Message-ID: <1277578798.15.0.0176809176988.issue9084@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon
keywords: +needs review
nosy: +brett.cannon
priority: normal -> low
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9084>
_______________________________________

From report at bugs.python.org  Sat Jun 26 21:09:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Jun 2010 19:09:54 +0000
Subject: [issue9085] Version number inconsistency in email package
In-Reply-To: <1277537275.59.0.8947906135.issue9085@psf.upfronthosting.co.za>
Message-ID: <1277579394.45.0.0360818613807.issue9085@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Bumps committed in r82246 and r82257.

----------
resolution: accepted -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9085>
_______________________________________

From report at bugs.python.org  Sat Jun 26 21:23:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Jun 2010 19:23:33 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
	locals and globals when they are not wanted
Message-ID: <1277580213.82.0.305876811982.issue1565525@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It is true that your proposed feature would provide a way for a programmer to manually resolve the cycle issue; however, the open issue in the pep is how to do this automatically.

But if you hold on to the traceback reference, you should *expect* all those values to persist, so that shouldn't be "surprising".

I repeat my recommendation that you take this to python-ideas for feedback, and then work on a patch if the feedback is positive.

(By the way, I checked with a twisted developer, and what he wanted was a convenient way to manually create traceback objects.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Sat Jun 26 21:35:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Jun 2010 19:35:02 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1277580902.6.0.720619970262.issue7989@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Alexander and Antoine, you are talking past each other.

Alexander: Antoine was trying to point out that the fact that io is quirky has not impacted their ability to maintain parallel versions significantly.  So if datetime is less quirky (and it probably is despite the quirks you pointed out), then it should be even easier to maintain parallel versions of it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Sat Jun 26 21:43:31 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 26 Jun 2010 19:43:31 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1277581411.22.0.00350834071647.issue3754@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

- consistent platform detection in all methods from setup.py;
- readline libraries detected by configure script are used for setup.py : this could help to detect is more platform independent way if readline is linked with ncurses{w} library;
- ignore "friendly" search library paths : this is useless in case of cross-compilation . Also it is reported that those paths are not so "friendly" even in native builds. Note that with "friendly search library paths" python library search based on file suffix will find libraries system on build system if host system lack them.

----------
Added file: http://bugs.python.org/file17778/python-trunk-20100626-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Sat Jun 26 21:53:16 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 26 Jun 2010 19:53:16 +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: <1277581996.99.0.37472794929.issue3871@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

- require patch "...20100626-CROSS..." from issue3871;
- setup.py don't ignore readline and ncurses for host platform  : python tests with readline pass, ncurses (current development)  is not usable yet;
- follow restored build with python specific windows version of libffi.

----------
Added file: http://bugs.python.org/file17779/python-trunk-20100626-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sat Jun 26 22:06:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Jun 2010 20:06:10 +0000
Subject: [issue4963] mimetypes.guess_extension result changes after
	mimetypes.init()
In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>
Message-ID: <1277582770.9.0.721165791148.issue4963@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

S Arrowsmith: can put a print statement into mimetypes.init, find out what files are loading, and paste the image/jpeg lines from each of those files here?  That might provide a clue.

----------
priority: normal -> low
stage:  -> unit test needed
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4963>
_______________________________________

From report at bugs.python.org  Sat Jun 26 22:10:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Jun 2010 20:10:17 +0000
Subject: [issue7989] Add pure Python implementation of datetime module
	to	CPython
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1277583017.17.0.0852421447098.issue7989@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I see.  I misunderstood AP's "although" as "however", but he probably meant "even though" or "in spite the fact that."

Antoine, can I count you as "+1"?

In any case, my threshold for moving this forward is for someone to review the code in sandbox.

Here is a convenient link to the code:

http://svn.python.org/view/*checkout*/sandbox/branches/py3k-datetime/datetime.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Sat Jun 26 22:18:57 2010
From: report at bugs.python.org (Greg Hazel)
Date: Sat, 26 Jun 2010 20:18:57 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
	locals and globals when they are not wanted
Message-ID: <1277583537.35.0.926317108284.issue1565525@psf.upfronthosting.co.za>


Greg Hazel <ghazel at users.sourceforge.net> added the comment:

> you should *expect* all those values to persist, so that shouldn't be "surprising".

It's not something I expected, and the warnings around traceback objects are a good indication that other developers have not expected it either. One poster on python-ideas said "Working with traceback objects can easily introduce hidden circular references, so it usually better not access them at all".  Since these 'hidden' references are not used in many cases, it is surprising that they would be required.

> I repeat my recommendation that you take this to python-ideas for feedback, and then work on a patch if the feedback is positive.

I have, and it has been so far.

> (By the way, I checked with a twisted developer, and what he wanted was a convenient way to manually create traceback objects.)

When does Twisted want to manually create traceback objects? Failure has specific functions to stringify the traceback to remove the references mentioned here. Creating a fake traceback would be one way to achieve that, but if the references did not exist I'm not sure what the goal would be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Sat Jun 26 22:19:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Jun 2010 20:19:28 +0000
Subject: [issue4945] json checks True/False by identity, not boolean value
In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za>
Message-ID: <1277583568.84.0.0165369637062.issue4945@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Most likely we are waiting for Bob's review.  Have you tested the patch?

----------
nosy: +r.david.murray
stage:  -> patch review
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4945>
_______________________________________

From report at bugs.python.org  Sat Jun 26 22:52:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Jun 2010 20:52:41 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1277585561.87.0.812597265122.issue8852@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm also seeing the failure of the _socket module to build on OpenSolaris build snv_134 (the most recent development build).  The socketmodule.c.patch patch fixes that failure for me, allowing the test-suite to run.

I'm afraid I don't feel competent to comment on the correctness of the patch, though, other than to say it works for me.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Sat Jun 26 23:11:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Jun 2010 21:11:54 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
	locals and globals when they are not wanted
Message-ID: <1277586714.8.0.826199466026.issue1565525@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Excellent.

As for twisted, I'm just repeating what I understood of what he said when I asked.  It could well be that this feature would help them, I don't know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Sat Jun 26 23:36:04 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 26 Jun 2010 21:36:04 +0000
Subject: [issue1035576] Add New RPM-friendly record option to setup.py
Message-ID: <1277588164.63.0.189064733093.issue1035576@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

distutils is now frozen in all branches, so not accepting new features but just bug fixes.

although distutils2 will not provide bdist_rpm, and I'd suggest the command to live on its own, in a new project (like bdist_deb did in stdeb). The benefit is to have a different release cycle which can follow the rpm world.

So yes, all pending feature requests to build_rpm, should be closed.

----------
resolution:  -> wont fix
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1035576>
_______________________________________

From report at bugs.python.org  Sun Jun 27 00:01:13 2010
From: report at bugs.python.org (Bill Janssen)
Date: Sat, 26 Jun 2010 22:01:13 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1277589673.65.0.118316942724.issue8621@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Stefan, I tried your suggestion of starting threading.  Test still succeeds on my 10.5.8 system when test_uuid is run separately.

Ronald, your fix works on my 10.5.8 system.  Why not check it in, and let's see if the buildbots turn green again?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8621>
_______________________________________

From report at bugs.python.org  Sun Jun 27 00:40:38 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 26 Jun 2010 22:40:38 +0000
Subject: [issue763708] Failures in test_macostools for --enable-unicode=ucs4
Message-ID: <1277592038.54.0.126111751103.issue763708@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Is this still a problem? None of the buildbot are reporting failures in test_macostools.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue763708>
_______________________________________

From report at bugs.python.org  Sun Jun 27 00:42:32 2010
From: report at bugs.python.org (S Arrowsmith)
Date: Sat, 26 Jun 2010 22:42:32 +0000
Subject: [issue4963] mimetypes.guess_extension result changes after
	mimetypes.init()
In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>
Message-ID: <1277592152.46.0.84226079582.issue4963@psf.upfronthosting.co.za>


S Arrowsmith <siona at chiark.greenend.org.uk> added the comment:

>>> import mimetypes 
>>> mimetypes.guess_extension('image/jpeg')
/etc/mime.types
'.jpe'
>>> mimetypes.init()
/etc/mime.types
>>> mimetypes.guess_extension('image/jpeg')
'.jpeg'
>>> 

$ grep jpeg /etc/mime.types
image/jpeg					jpeg jpg jpe
$

That big chunk of whitespace is 5 tabs. Not very helpful, I fear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4963>
_______________________________________

From report at bugs.python.org  Sun Jun 27 00:42:44 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 26 Jun 2010 22:42:44 +0000
Subject: [issue763708] Failures in test_macostools for --enable-unicode=ucs4
Message-ID: <1277592164.63.0.950740442403.issue763708@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
status: open -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue763708>
_______________________________________

From report at bugs.python.org  Sun Jun 27 00:52:38 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 26 Jun 2010 22:52:38 +0000
Subject: [issue2380] Raise a Py3K warning for catching nested tuples with
	non-BaseException exceptions
In-Reply-To: <1205812263.49.0.840453912449.issue2380@psf.upfronthosting.co.za>
Message-ID: <1277592758.77.0.905635222951.issue2380@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/issue2380>
_______________________________________

From report at bugs.python.org  Sun Jun 27 00:56:45 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 26 Jun 2010 22:56:45 +0000
Subject: [issue1909] Backport: Mixing default keyword arguments with *args
In-Reply-To: <1201032273.11.0.991902181918.issue1909@psf.upfronthosting.co.za>
Message-ID: <1277593005.39.0.2498953037.issue1909@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Now it's too late for this. Closing as out of date.

----------
keywords:  -26backport
nosy: +ezio.melotti
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1909>
_______________________________________

From report at bugs.python.org  Sun Jun 27 01:03:11 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 26 Jun 2010 23:03:11 +0000
Subject: [issue763708] Failures in test_macostools for --enable-unicode=ucs4
Message-ID: <1277593391.2.0.526540869808.issue763708@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue763708>
_______________________________________

From report at bugs.python.org  Sun Jun 27 01:08:02 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 26 Jun 2010 23:08:02 +0000
Subject: [issue9088] revert distutils so it's like in 3.1
In-Reply-To: <1277593682.01.0.850281070845.issue9088@psf.upfronthosting.co.za>
Message-ID: <1277593682.01.0.850281070845.issue9088@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

distutils is going back to its 3.1 state, as planned at the summit (done in 2.7/trunk already). Should be done over the week end

----------
assignee: tarek
messages: 108757
nosy: tarek
priority: release blocker
severity: normal
status: open
title: revert distutils so it's like in 3.1
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9088>
_______________________________________

From report at bugs.python.org  Sun Jun 27 01:08:50 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 26 Jun 2010 23:08:50 +0000
Subject: [issue9088] revert distutils so it's like in 3.1
In-Reply-To: <1277593682.01.0.850281070845.issue9088@psf.upfronthosting.co.za>
Message-ID: <1277593730.35.0.383771559113.issue9088@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9088>
_______________________________________

From report at bugs.python.org  Sun Jun 27 01:21:01 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 26 Jun 2010 23:21:01 +0000
Subject: [issue5705] os.getpwent returns unsigned 32bit value,
	os.setuid refuses it
In-Reply-To: <1238971076.18.0.458968995084.issue5705@psf.upfronthosting.co.za>
Message-ID: <1277594461.32.0.646245641928.issue5705@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think this can be closed, now that there is another issue for posix_lchown.

----------
nosy: +ezio.melotti
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5705>
_______________________________________

From report at bugs.python.org  Sun Jun 27 01:31:35 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 26 Jun 2010 23:31:35 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1277595095.33.0.381918505347.issue2292@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/issue2292>
_______________________________________

From report at bugs.python.org  Sun Jun 27 02:07:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Jun 2010 00:07:03 +0000
Subject: [issue655802] cPickle not always same as pickle
Message-ID: <1277597223.45.0.380646391032.issue655802@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

What is the status of this?  issue1536 is an open documentation issue.  Is this similarly a documentation enhancement request or there is a case when pickle and CPickle produce different and incompatible serializations?

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue655802>
_______________________________________

From report at bugs.python.org  Sun Jun 27 02:07:54 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 27 Jun 2010 00:07:54 +0000
Subject: [issue755286] Generate rpm filelist including directories
Message-ID: <1277597274.24.0.232230884435.issue755286@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

See Tarek's message on #1035576.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue755286>
_______________________________________

From report at bugs.python.org  Sun Jun 27 02:18:00 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 27 Jun 2010 00:18:00 +0000
Subject: [issue828743] bdist_rpm failure when no setup.py
Message-ID: <1277597880.76.0.679538445809.issue828743@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

see msg108752

----------
nosy: +tjreedy
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue828743>
_______________________________________

From report at bugs.python.org  Sun Jun 27 02:18:45 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 27 Jun 2010 00:18:45 +0000
Subject: [issue5482] RFC: improve distutils bdist_rpm so it builds pure python
	modules as single packages that works across architectures
In-Reply-To: <1236943653.87.0.451270681282.issue5482@psf.upfronthosting.co.za>
Message-ID: <1277597925.08.0.823722806249.issue5482@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

see msg108752

----------
nosy: +tjreedy
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5482>
_______________________________________

From report at bugs.python.org  Sun Jun 27 02:21:36 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 27 Jun 2010 00:21:36 +0000
Subject: [issue6546] [Distutils][PATCH] Add bdist_rpm option to select the
	name of the resulting package
In-Reply-To: <1248271616.22.0.938348287661.issue6546@psf.upfronthosting.co.za>
Message-ID: <1277598096.11.0.614608799481.issue6546@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

see msg108752

----------
nosy: +tjreedy
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6546>
_______________________________________

From report at bugs.python.org  Sun Jun 27 02:22:27 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 27 Jun 2010 00:22:27 +0000
Subject: [issue1028432] Specify a source baseurl for bdist_rpm.
Message-ID: <1277598147.19.0.219291689804.issue1028432@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

see msg108752

----------
nosy: +tjreedy
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028432>
_______________________________________

From report at bugs.python.org  Sun Jun 27 02:33:30 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 27 Jun 2010 00:33:30 +0000
Subject: [issue1035576] Add New RPM-friendly record option to setup.py
In-Reply-To: <1277588164.63.0.189064733093.issue1035576@psf.upfronthosting.co.za>
Message-ID: <4C269C4A.3020305@udel.edu>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On 6/26/2010 5:36 PM, Tarek Ziad? wrote:
>
> Tarek Ziad?<ziade.tarek at gmail.com>  added the comment:
>
> distutils is now frozen in all branches, so not accepting new
> features but just bug fixes.
>
> although distutils2 will not provide bdist_rpm, and I'd suggest the
> command to live on its own, in a new project (like bdist_deb did in
> stdeb). The benefit is to have a different release cycle which can
> follow the rpm world.

Seems like a good idea.

> So yes, all pending feature requests to build_rpm, should be closed.

Done for the duplicate, and 4 others for bdist_rpm (you should see
messages and counter if not correct.)

There are also bug reports for bdist_rpm. Close these too?
2945 4495 5474 644744 5875 (test failure)

How about any of the other feature requests (there are about 36 others
open for distutils). Should they be retargeted to disutils2?

> ---------- resolution:  ->  wont fix status: open ->  closed type:
> ->  feature request
>
> _______________________________________ Python
> tracker<report at bugs.python.org>
> <http://bugs.python.org/issue1035576>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1035576>
_______________________________________

From report at bugs.python.org  Sun Jun 27 02:53:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Jun 2010 00:53:48 +0000
Subject: [issue9089] PyNumber_Int is still mentioned in number protocol docs
In-Reply-To: <1277600028.16.0.686508987886.issue9089@psf.upfronthosting.co.za>
Message-ID: <1277600028.16.0.686508987886.issue9089@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

See http://docs.python.org/dev/py3k/c-api/number.html#PyNumber_Int

I also noticed some left-over references to intobject in the comments in the py3k tree:

Include/longobject.h:61:/* For use by intobject.c only */
Modules/xxmodule.c:13:   intobject.h for an example. */
Objects/floatobject.c:24:/* Special free list -- see comments for same code in intobject.c. */
Objects/frameobject.c:394:   integers are allocated in a special way -- see intobject.c).  When
PCbuild/pythoncore.vcproj:758:				RelativePath="..\Include\intobject.h"

----------
assignee: docs at python
components: Documentation
messages: 108766
nosy: belopolsky, docs at python, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: PyNumber_Int is still mentioned in number protocol docs
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9089>
_______________________________________

From report at bugs.python.org  Sun Jun 27 03:18:24 2010
From: report at bugs.python.org (Bill Janssen)
Date: Sun, 27 Jun 2010 01:18:24 +0000
Subject: [issue8447] buildbot: test_httpservers failure (No module named
	operator)
In-Reply-To: <1271629389.65.0.354940045225.issue8447@psf.upfronthosting.co.za>
Message-ID: <1277601504.03.0.367098758057.issue8447@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Failing on my PPC Tiger OS X buildbot, with 2.6, too.

----------
nosy: +janssen
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8447>
_______________________________________

From report at bugs.python.org  Sun Jun 27 03:25:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Jun 2010 01:25:23 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277601923.26.0.0380713330393.issue5180@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

If I disable _pickle, I get a more meaningful trace:


  File "Tools/pybench/pybench.py", line 954, in <module>
    PyBenchCmdline()
  File "/Users/sasha/Work/python-svn/py3k-commit/Tools/pybench/CommandLine.py", line 349, in __init__
    rc = self.main()
  File "Tools/pybench/pybench.py", line 888, in main
    bench = pickle.load(f)
  File "/Users/sasha/Work/python-svn/py3k-commit/Lib/pickle.py", line 1321, in load
    encoding=encoding, errors=errors).load()
  File "/Users/sasha/Work/python-svn/py3k-commit/Lib/pickle.py", line 830, in load
    dispatch[key[0]](self)
  File "/Users/sasha/Work/python-svn/py3k-commit/Lib/pickle.py", line 1055, in load_inst
    klass = self.find_class(module, name)
  File "/Users/sasha/Work/python-svn/py3k-commit/Lib/pickle.py", line 1115, in find_class
    __import__(module, level=0)
  File "/Users/sasha/Work/python-svn/py3k-commit/Tools/pybench/Unicode.py", line 17
    s = unicode(u''.join(map(str,range(100))))
                  ^
SyntaxError: invalid syntax


Apparently, pybench/Unicode.py has never been converted to py3k. This is likely not the only problem:

>>> from pybench import *
>>> import pickle
>>> pickle.load(open('27.bench'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/sasha/Work/python-svn/py3k-commit/Lib/pickle.py", line 1321, in load
    encoding=encoding, errors=errors).load()
  File "/Users/sasha/Work/python-svn/py3k-commit/Lib/pickle.py", line 829, in load
    assert isinstance(key, bytes_types)
AssertionError

This looks like the infamous bytes vs string problem ...

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Sun Jun 27 03:31:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Jun 2010 01:31:29 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277602289.41.0.933413768888.issue5180@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The bytes/string issu was a red herring: with pickle.load(open('27.bench', 'b')), I get the same stack trace as from command line pybench invocation.


>>> pickle.load(open('27.bench', 'rb'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/sasha/Work/python-svn/py3k-commit/Lib/pickle.py", line 1321, in load
    encoding=encoding, errors=errors).load()
  File "/Users/sasha/Work/python-svn/py3k-commit/Lib/pickle.py", line 830, in load
    dispatch[key[0]](self)
  File "/Users/sasha/Work/python-svn/py3k-commit/Lib/pickle.py", line 1055, in load_inst
    klass = self.find_class(module, name)
  File "/Users/sasha/Work/python-svn/py3k-commit/Lib/pickle.py", line 1115, in find_class
    __import__(module, level=0)
  File "/Users/sasha/Work/python-svn/py3k-commit/Tools/pybench/Unicode.py", line 17
    s = unicode(u''.join(map(str,range(100))))
                  ^
SyntaxError: invalid syntax

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Sun Jun 27 03:38:47 2010
From: report at bugs.python.org (Eric Hohenstein)
Date: Sun, 27 Jun 2010 01:38:47 +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: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>


New submission from Eric Hohenstein <ehohenstein at imvu.com>:

This error is unfortunately difficult to reproduce. I've only seen it happen on Windows XP running on a dual core VMWare VM. I haven't been able to reproduce it on a non-VM system running Windows 7. The only way I've been able to reproduce it is to run the following unit test repeatedly on the XP VM repeatedly until it fails:

import unittest
import urllib2

class DownloadUrlTest(unittest.TestCase):
    def testDownloadUrl(self):
        opener = urllib2.build_opener()
        handle = opener.open('http://localhost/', timeout=60)
        handle.info()
        data = handle.read()
        self.assertNotEqual(data, '')

if __name__ == "__main__":
    unittest.main()

This unit test obviously depends on a web server running on localhost. In the test environment where I was able to reproduce this problem the web server is Win32 Apache 2.0.54 with mod_php. When the test fails, it fails with Windows error code 10035 (WSAEWOULDBLOCK) being generated by the call to the recv() method rougly once every 50-100 times the test is run. The following is a the final entry in the stack when the error occurs:

  File "c:\slave\h05b15\build\Ext\Python26\lib\socket.py", line 353, in read (self=<socket._fileobject ...03B78170>, size=1027091)
    data = self._sock.recv(left)

The thing to note is that the socket is being created with a timeout of 60. The implementation of the socket.recv() method in socketmodule.c in the _socket import module is to use select() to wait for a socket to become readable for socket objects with a timeout and then to call recv() on the socket only if select() did not return indicating that the timeout period elapsed without the socket becoming readable. The fact that Windows error code 10035 (WSAEWOULDBLOCK) is being generated in the sock_recv_guts() method in socketmodule.c indicates that select() returned without timing out which means that Windows must have indicated that the socket is readable when in fact it wasn't. 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). The code for socketmodule.c doesn't seem to handle this type of situation correctly. The patch I've included with this issue report retries the select() if the recv() call fails with WSAWOULDBLOCK (only if MS_WINDOWS is defined). With the patch in place the test ran approximately 23000 times without failure on the system where it was failing without the patch.

----------
components: IO, Windows
files: sock_recv.patch
keywords: patch
messages: 108770
nosy: ehohenstein
priority: normal
severity: normal
status: open
title: Error code 10035 calling socket.recv() on a socket with a timeout (WSAEWOULDBLOCK - A non-blocking socket operation could not be completed immediately)
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17780/sock_recv.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Sun Jun 27 03:48:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Jun 2010 01:48:03 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277603283.31.0.260285745518.issue5180@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Hmm.  It looks like another pickle vs. _pickle issue.  Attached patch is a result of 2to3 applied to Tools/pybench (and a minor manual fix for pickle import) with _pickle import disabled.

With the patch applied,

$ ./python Tools/pybench/pybench.py --debug -s 27.bench

runs fine and produces results identical to those for a similar run from the trunk.

Looks like it is time to fire up gdb.

----------
keywords: +patch
Added file: http://bugs.python.org/file17781/issue5180.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Sun Jun 27 05:34:04 2010
From: report at bugs.python.org (Esteban Feldman)
Date: Sun, 27 Jun 2010 03:34:04 +0000
Subject: [issue9091] str.capitalize() should not lower the rest of the string
In-Reply-To: <1277609644.85.0.417350742268.issue9091@psf.upfronthosting.co.za>
Message-ID: <1277609644.85.0.417350742268.issue9091@psf.upfronthosting.co.za>


New submission from Esteban Feldman <esteban.feldman at gmail.com>:

As per documentation:
I doesn't say anything on lower the rest of the string.
Is this the expected behavior?

**
str.capitalize()?
Return a copy of the string with only its first character capitalized.

For 8-bit strings, this method is locale-dependent.
**

Example:

Python 2.6.5 (r265:79063, May 24 2010, 14:03:08) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 'this is a TEST'
>>> a.capitalize()
'This is a test'

----------
components: Library (Lib)
messages: 108772
nosy: eka
priority: normal
severity: normal
status: open
title: str.capitalize() should not lower the rest of the string
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9091>
_______________________________________

From report at bugs.python.org  Sun Jun 27 07:00:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 27 Jun 2010 05:00:57 +0000
Subject: [issue9091] str.capitalize() should not lower the rest of the string
In-Reply-To: <1277609644.85.0.417350742268.issue9091@psf.upfronthosting.co.za>
Message-ID: <1277614857.18.0.595972113942.issue9091@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The doc looks pretty clear to me: "return a copy of the string with *only* its first character capitalized."  I don't offhand see how we could make that clearer.  Maybe we should actually put the emphasis on the 'only' into the doc markup?  That doesn't feel quite right to me, though.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9091>
_______________________________________

From report at bugs.python.org  Sun Jun 27 07:32:38 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 27 Jun 2010 05:32:38 +0000
Subject: [issue9091] str.capitalize() should not lower the rest of the string
In-Reply-To: <1277609644.85.0.417350742268.issue9091@psf.upfronthosting.co.za>
Message-ID: <1277616758.39.0.380193048831.issue9091@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Capitalization is a language property, it is not Python specific. By Definition, except for first letter every thing else is lower cased.

http://en.wikipedia.org/wiki/Capitalization

So, Python documentation assumes that it is understood (or can referred to in case of doubt).

I too don't see any change is required in Python docs.

----------
nosy: +orsenthil
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9091>
_______________________________________

From report at bugs.python.org  Sun Jun 27 11:50:29 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Jun 2010 09:50:29 +0000
Subject: [issue9089] PyNumber_Int is still mentioned in number protocol docs
In-Reply-To: <1277600028.16.0.686508987886.issue9089@psf.upfronthosting.co.za>
Message-ID: <1277632229.69.0.753947672149.issue9089@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks; I'll fix these.

----------
assignee: docs at python -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9089>
_______________________________________

From report at bugs.python.org  Sun Jun 27 12:04:26 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 27 Jun 2010 10:04:26 +0000
Subject: [issue8954] wininst regression: errors when building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1277633066.13.0.556158975206.issue8954@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It certainly should be possible to build these installers, and if I understand your output correctly, an installer *was* built.  The warning is, after all, just a warning, and probably just the warning got added compared to 2.5, but the behavior is the same.

The platform name is a regression though.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8954>
_______________________________________

From report at bugs.python.org  Sun Jun 27 12:08:16 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 27 Jun 2010 10:08:16 +0000
Subject: [issue9027] add test_support.run_unittest command line options and
	arguments
In-Reply-To: <1276863615.44.0.266652400766.issue9027@psf.upfronthosting.co.za>
Message-ID: <1277633296.02.0.891782577476.issue9027@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9027>
_______________________________________

From report at bugs.python.org  Sun Jun 27 12:17:18 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 27 Jun 2010 10:17:18 +0000
Subject: [issue9078] Fix C API documentation of unicode
In-Reply-To: <1277422554.75.0.295241572037.issue9078@psf.upfronthosting.co.za>
Message-ID: <1277633838.2.0.234215479252.issue9078@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed as r82262.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9078>
_______________________________________

From report at bugs.python.org  Sun Jun 27 12:34:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 27 Jun 2010 10:34:24 +0000
Subject: [issue9059] Backwards compatibility
In-Reply-To: <1277286673.12.0.243169003813.issue9059@psf.upfronthosting.co.za>
Message-ID: <1277634864.59.0.678765714158.issue9059@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Please, do not feed the trolls.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9059>
_______________________________________

From report at bugs.python.org  Sun Jun 27 12:38:08 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 27 Jun 2010 10:38:08 +0000
Subject: [issue9064] pdb enhancement up/down traversals
In-Reply-To: <1277320886.89.0.906554449905.issue9064@psf.upfronthosting.co.za>
Message-ID: <1277635088.27.0.701910413499.issue9064@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed a slightly different patch in r82263.  Thanks for the idea!

----------
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9064>
_______________________________________

From report at bugs.python.org  Sun Jun 27 12:40:58 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 27 Jun 2010 10:40:58 +0000
Subject: [issue9044] [optparse] confusion over an option and its value without
	any space in between
In-Reply-To: <1277136331.24.0.0452022727538.issue9044@psf.upfronthosting.co.za>
Message-ID: <1277635258.09.0.734063526714.issue9044@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, this is common behavior and should not change.

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9044>
_______________________________________

From report at bugs.python.org  Sun Jun 27 14:01:23 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 27 Jun 2010 12:01:23 +0000
Subject: [issue763708] Failures in test_macostools for --enable-unicode=ucs4
Message-ID: <1277640083.22.0.537351744318.issue763708@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This still is a problem, the Carbon wrappers assume that Py_UNICODE has the same representation as the Unicode type in Carbon and that is a 16-bit type.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue763708>
_______________________________________

From report at bugs.python.org  Sun Jun 27 14:40:59 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 27 Jun 2010 12:40:59 +0000
Subject: [issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4
In-Reply-To: <1277145356.65.0.792770780459.issue9046@psf.upfronthosting.co.za>
Message-ID: <1277642459.2.0.343314809307.issue9046@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've committed a fix in r82272 (2.7), r82273 (3.2), r82274 (2.6), r82273 (3.1)

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9046>
_______________________________________

From report at bugs.python.org  Sun Jun 27 14:46:56 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 27 Jun 2010 12:46:56 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1277642816.72.0.285523572199.issue8621@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Committed a fix in r82276 (2.7), r82277 (2.6), r82278 (3.2) and r82279 (3.1).

Please reopen the issue if you notice that the problem does not go away on the buildbots.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8621>
_______________________________________

From report at bugs.python.org  Sun Jun 27 14:48:31 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 27 Jun 2010 12:48:31 +0000
Subject: [issue9045] 2.7rc1: 64-bit OSX installer is not built with 64-bit
	tkinter
In-Reply-To: <1277143341.0.0.74848452771.issue9045@psf.upfronthosting.co.za>
Message-ID: <1277642911.08.0.532507309123.issue9045@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Even when building using an SDK you can use frameworks in /Library/Frameworks because $SDKROOT/Library/Frameworks is a symlink to the real /Library/Frameworks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9045>
_______________________________________

From report at bugs.python.org  Sun Jun 27 14:52:29 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 27 Jun 2010 12:52:29 +0000
Subject: [issue8455] buildbot: test_urllib2_localnet failures (Connection
	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1277643149.03.0.390036283374.issue8455@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Applied to 2.6 (r82280), r82281 (3.2), r82282 (3.1).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8455>
_______________________________________

From report at bugs.python.org  Sun Jun 27 14:54:26 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 27 Jun 2010 12:54:26 +0000
Subject: [issue9047] Python 2.7rc2 includes -isysroot twice on each gcc
	command line
In-Reply-To: <1277145493.52.0.0439952052215.issue9047@psf.upfronthosting.co.za>
Message-ID: <1277643266.18.0.380133907953.issue9047@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Marc-Andre: is this still relevant or did the fix for SDK support enough to fix the build.

BTW. Is this for OSX 10.4 instead of 10.3? AFAIK the compiler on 10.3 doesn't support SDKs at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9047>
_______________________________________

From report at bugs.python.org  Sun Jun 27 14:55:23 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 27 Jun 2010 12:55:23 +0000
Subject: [issue8446] buildbot: DeprecationWarning not raised for icglue
	(test_py3kwarn.TestStdlibRemovals)
In-Reply-To: <1271628757.81.0.455065561336.issue8446@psf.upfronthosting.co.za>
Message-ID: <1277643323.12.0.600447910343.issue8446@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8446>
_______________________________________

From report at bugs.python.org  Sun Jun 27 14:56:23 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 27 Jun 2010 12:56:23 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1277643383.59.0.801414023946.issue7724@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This was committed a while back, I guess I forgot to close this issue.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7724>
_______________________________________

From report at bugs.python.org  Sun Jun 27 14:58:34 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 27 Jun 2010 12:58:34 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1277643514.23.0.542381533221.issue8577@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

As r82005 fixed the problem this issue can be closed.

----------
assignee: ronaldoussoren -> nobody
nosy: +nobody
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Sun Jun 27 16:27:52 2010
From: report at bugs.python.org (Konstantin)
Date: Sun, 27 Jun 2010 14:27:52 +0000
Subject: [issue9092] static behavior of local variables
In-Reply-To: <1277648872.55.0.144754321131.issue9092@psf.upfronthosting.co.za>
Message-ID: <1277648872.55.0.144754321131.issue9092@psf.upfronthosting.co.za>


New submission from Konstantin <kaslanidi at yahoo.com>:

In [12]: def func(x=[]) :
   ....:     L=x
   ....:     L.append('a')
   ....:     return L
   ....:

In [13]: func()
Out[13]: ['a']

In [14]: func()
Out[14]: ['a', 'a']

In [15]: func()
Out[15]: ['a', 'a', 'a']

In [16]: func()
Out[16]: ['a', 'a', 'a', 'a']

In [17]: x
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)

C:\Users\konstantin\<ipython console> in <module>()

NameError: name 'x' is not defined

In [18]:

In [19]: L
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)

C:\Users\konstantin\<ipython console> in <module>()

NameError: name 'L' is not defined

----------
components: None
messages: 108789
nosy: Aslanidi
priority: normal
severity: normal
status: open
title: static behavior of local variables
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9092>
_______________________________________

From report at bugs.python.org  Sun Jun 27 16:28:51 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 27 Jun 2010 14:28:51 +0000
Subject: [issue8883] Proxy exception lookup fails on MacOS in urllib.
In-Reply-To: <1275550309.78.0.672707816894.issue8883@psf.upfronthosting.co.za>
Message-ID: <1277648931.26.0.912620426402.issue8883@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Committed the patch with some minor modifications in r82284 (2.7), r82285 (2.6), r82286 (3.2), r82287 (3.1)

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8883>
_______________________________________

From report at bugs.python.org  Sun Jun 27 16:31:00 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 27 Jun 2010 14:31:00 +0000
Subject: [issue8447] buildbot: test_httpservers failure (No module named
	operator)
In-Reply-To: <1271629389.65.0.354940045225.issue8447@psf.upfronthosting.co.za>
Message-ID: <1277649060.33.0.267443257826.issue8447@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Bill: can you do some debugging on the buildbot itself? I cannot reproduce the problem locally.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8447>
_______________________________________

From report at bugs.python.org  Sun Jun 27 16:33:36 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 27 Jun 2010 14:33:36 +0000
Subject: [issue9033] cmd module tab misbehavior
In-Reply-To: <1276960216.2.0.17858038653.issue9033@psf.upfronthosting.co.za>
Message-ID: <1277649216.11.0.352376069066.issue9033@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached patch is a workaround for the issue, but isn't someone I'd want to commit without some serious cleanup.

As I noted when support for linking with libedit was merged it would be better to add a translation layer that translates GNU readline configuration lines to BSD libedit ones.

----------
keywords: +patch
Added file: http://bugs.python.org/file17782/cmd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9033>
_______________________________________

From report at bugs.python.org  Sun Jun 27 16:35:52 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Jun 2010 14:35:52 +0000
Subject: [issue9092] static behavior of local variables
In-Reply-To: <1277648872.55.0.144754321131.issue9092@psf.upfronthosting.co.za>
Message-ID: <1277649352.28.0.0112478207224.issue9092@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Please see the warning in this section of the tutorial:

http://docs.python.org/tutorial/controlflow.html#default-argument-values

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9092>
_______________________________________

From report at bugs.python.org  Sun Jun 27 16:40:53 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 27 Jun 2010 14:40:53 +0000
Subject: [issue3485] os.path.normcase documentation/behaviour unclear on Mac
	OS X
In-Reply-To: <1217610966.27.0.918507533161.issue3485@psf.upfronthosting.co.za>
Message-ID: <1277649653.56.0.26969412544.issue3485@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The comment is wrong, os.path.normcase should not return s.lower(), as the other issue notes the case sensitivity is filesystem dependent.  

Returning s.lower() will break code when dealing with paths that refer to an NFS share on a Linux server, or to a path on a local case sensitive file system.

IMHO The comment in posixpath should be changed to something like this:

# On MacOS X most but not all filesystems are case sensitive, which
# means that using normcase(p1) != normcase(p2) doesn't necessarily mean
# that the paths refer to different files.

The current comment gives the impression that a trivial should be applied, which isn't true.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3485>
_______________________________________

From report at bugs.python.org  Sun Jun 27 16:44:10 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 27 Jun 2010 14:44:10 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1277649850.01.0.771753777229.issue8084@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The tests no longer fail.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Sun Jun 27 17:04:19 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 27 Jun 2010 15:04:19 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277651059.62.0.3499107208.issue5180@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> lemburg
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Sun Jun 27 17:15:19 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 27 Jun 2010 15:15:19 +0000
Subject: [issue9083] At least some Tools utilities are still Python 2
In-Reply-To: <1277505524.04.0.87838503944.issue9083@psf.upfronthosting.co.za>
Message-ID: <1277651719.27.0.6408429197.issue9083@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/issue9083>
_______________________________________

From report at bugs.python.org  Sun Jun 27 18:34:23 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 27 Jun 2010 16:34:23 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277656463.89.0.909745450376.issue5180@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Please keep the Python3 version of pybench compatible to Python 2.6 and 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Sun Jun 27 19:08:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Jun 2010 17:08:15 +0000
Subject: [issue9093] Tools/README is out of date
In-Reply-To: <1277658495.23.0.15994230675.issue9093@psf.upfronthosting.co.za>
Message-ID: <1277658495.23.0.15994230675.issue9093@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Here is the list of subdirectories in Tools.  Here is the diff between directory listing and readme ('-' means no readme entry, '+' - no tool):

-buildbot
-ccbench
+audiopy
+compiler
 faqwiz
-framer
 freeze
 gdb
 i18n
-iobench
-msi
-pybench
 pynche
 scripts
-ssl
 unicode
 versioncheck
+webchecker
 world

----------
assignee: docs at python
components: Documentation
messages: 108797
nosy: belopolsky, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Tools/README is out of date
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9093>
_______________________________________

From report at bugs.python.org  Sun Jun 27 19:12:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 27 Jun 2010 17:12:38 +0000
Subject: [issue9088] revert distutils to its 3.1 state
In-Reply-To: <1277593682.01.0.850281070845.issue9088@psf.upfronthosting.co.za>
Message-ID: <1277658758.3.0.791167842809.issue9088@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you explain this a bit, for those who weren?t at that summit you mention (I guess at EuroPython)?

(I took the liberty of rephrasing the title to make it IMO clearer)

----------
components: +Distutils
nosy: +merwok
resolution:  -> accepted
title: revert distutils so it's like in 3.1 -> revert distutils to its 3.1 state

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9088>
_______________________________________

From report at bugs.python.org  Sun Jun 27 19:22:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Jun 2010 17:22:56 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277659376.72.0.0564544401419.issue5180@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I have found issue1634499 which deals with running pybench.  I suggest that we reopen that issue and move discussion of issue5180.diff there.

I really like the idea to keep single source for 2.x and 3.x pybench, but we need to add some machinery to run 2.x pybench under python3.x transparently.

Marc-Andre,

are you taking over the pybench or the _pickle issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Sun Jun 27 19:37:39 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Jun 2010 17:37:39 +0000
Subject: [issue9089] PyNumber_Int is still mentioned in number protocol docs
In-Reply-To: <1277600028.16.0.686508987886.issue9089@psf.upfronthosting.co.za>
Message-ID: <1277660259.53.0.485985864456.issue9089@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Removed PyNumber_Int from docs (and Data/refcounts.dat;  though I suspect that file is far from up-to-date) in r82288.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9089>
_______________________________________

From report at bugs.python.org  Sun Jun 27 20:07:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 27 Jun 2010 18:07:17 +0000
Subject: [issue8988] import + coding = failure (3.1.2/win32)
In-Reply-To: <1276426235.15.0.873898512927.issue8988@psf.upfronthosting.co.za>
Message-ID: <1277662037.57.0.818460949081.issue8988@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Did you read my first comment? "This bug is maybe related to #8611"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8988>
_______________________________________

From report at bugs.python.org  Sun Jun 27 20:19:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Jun 2010 18:19:48 +0000
Subject: [issue9089] PyNumber_Int is still mentioned in number protocol docs
In-Reply-To: <1277600028.16.0.686508987886.issue9089@psf.upfronthosting.co.za>
Message-ID: <1277662788.63.0.137650377988.issue9089@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

References to intobject.h and intobject.c removed in r88289 and r88290.

Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9089>
_______________________________________

From report at bugs.python.org  Sun Jun 27 20:19:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Jun 2010 18:19:59 +0000
Subject: [issue9089] PyNumber_Int is still mentioned in number protocol docs
In-Reply-To: <1277600028.16.0.686508987886.issue9089@psf.upfronthosting.co.za>
Message-ID: <1277662799.77.0.679921228573.issue9089@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
stage: needs patch -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9089>
_______________________________________

From report at bugs.python.org  Sun Jun 27 20:28:49 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Jun 2010 18:28:49 +0000
Subject: [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277663329.19.0.534315669176.issue9069@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The gcc optimization bug was fixed (with impressive speed!) upstream.

I'm going to close this as 'won't fix'.  It's probably possible to find a workaround, but the issue is minor, apparently only affects one platform, and relates to a little-used method.  For people who want this fixed in their own Python builds, a fairly unintrusive workaround is to add '-fno-builtin-copysign' to the compiler flags, or to compile with version <4.4 of gcc until the next bugfix release of gcc 4.4 or 4.5.

David: thanks for reporting this, and for all the followup.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9069>
_______________________________________

From report at bugs.python.org  Sun Jun 27 21:47:25 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 27 Jun 2010 19:47:25 +0000
Subject: [issue3485] os.path.normcase documentation/behaviour unclear on Mac
	OS X
In-Reply-To: <1217610966.27.0.918507533161.issue3485@psf.upfronthosting.co.za>
Message-ID: <1277668045.7.0.00436572240952.issue3485@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Changing the function is better than changing the comment.
Although changing just the comment is better than leaving it unchanged.

----------
versions: +Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3485>
_______________________________________

From report at bugs.python.org  Sun Jun 27 23:49:47 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 27 Jun 2010 21:49:47 +0000
Subject: [issue8667] Link to PEP 3147 from importlib docs
In-Reply-To: <1273362693.55.0.571697250376.issue8667@psf.upfronthosting.co.za>
Message-ID: <1277675387.8.0.191375711182.issue8667@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Sorry this took so long, Ashley. I applied your patch in r82300.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8667>
_______________________________________

From report at bugs.python.org  Mon Jun 28 01:06:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 27 Jun 2010 23:06:21 +0000
Subject: [issue1634499] Py3k: Fix pybench so it runs
Message-ID: <1277679981.69.0.148922228478.issue1634499@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is this bug closed? (Bonus cookies points for mention of the revision)

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1634499>
_______________________________________

From report at bugs.python.org  Mon Jun 28 01:12:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Jun 2010 23:12:15 +0000
Subject: [issue9094] Make python-m pickletools do something useful
In-Reply-To: <1277680335.26.0.237686854485.issue9094@psf.upfronthosting.co.za>
Message-ID: <1277680335.26.0.237686854485.issue9094@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Attached patch makes python -m pickletools <picklefile> print symbolic disassembly of a pickle to stdout.  If the idea is well received, I will add help option, usage string and possibly -o option to redirect output to a file.

I am not sure that current "run doctest" behavior is worth preserving given that one can always do python -m doctest Lib/pickletools.py instead.

----------
assignee: belopolsky
components: Library (Lib)
files: pickletools.diff
keywords: easy, patch
messages: 108807
nosy: alexandre.vassalotti, belopolsky
priority: normal
severity: normal
stage: patch review
status: open
title: Make python-m pickletools do something useful
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17783/pickletools.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9094>
_______________________________________

From report at bugs.python.org  Mon Jun 28 01:59:48 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 27 Jun 2010 23:59:48 +0000
Subject: [issue9095] patchcheck should handle extraneous whitespace in .rst
	files
In-Reply-To: <1277683188.13.0.698937807833.issue9095@psf.upfronthosting.co.za>
Message-ID: <1277683188.13.0.698937807833.issue9095@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Tools/scripts/reindent-rst.py already exists, so this should be simple to add.

----------
components: Demos and Tools
keywords: easy
messages: 108808
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: patchcheck should handle extraneous whitespace in .rst files
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9095>
_______________________________________

From report at bugs.python.org  Mon Jun 28 02:05:03 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Jun 2010 00:05:03 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1277683503.77.0.38585552288.issue7319@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Merged the lot in r82314.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7319>
_______________________________________

From report at bugs.python.org  Mon Jun 28 02:14:06 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 28 Jun 2010 00:14:06 +0000
Subject: [issue7566] Add ntpath.sameopenfile support for Windows
In-Reply-To: <1261529807.86.0.672662668527.issue7566@psf.upfronthosting.co.za>
Message-ID: <1277684046.52.0.558455057711.issue7566@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
assignee:  -> brian.curtin
nosy: +brian.curtin
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7566>
_______________________________________

From report at bugs.python.org  Mon Jun 28 02:28:20 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Jun 2010 00:28:20 +0000
Subject: [issue9096] importlib doesn't handle valid marshalled data with
	invalid semantics
In-Reply-To: <1277684900.43.0.0388442576736.issue9096@psf.upfronthosting.co.za>
Message-ID: <1277684900.43.0.0388442576736.issue9096@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

get_code() returns marshal.loads(self.get_data()). If get_data() returns valid marhsal data that is not a code object, get_code() will explode when it tries to exec it with a TypeError not the expected ValueError.

----------
assignee: brett.cannon
messages: 108810
nosy: benjamin.peterson, brett.cannon
priority: normal
severity: normal
status: open
title: importlib doesn't handle valid marshalled data with invalid semantics

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9096>
_______________________________________

From report at bugs.python.org  Mon Jun 28 02:28:57 2010
From: report at bugs.python.org (Tokio Kikuchi)
Date: Mon, 28 Jun 2010 00:28:57 +0000
Subject: [issue9085] Version number inconsistency in email package
In-Reply-To: <1277537275.59.0.8947906135.issue9085@psf.upfronthosting.co.za>
Message-ID: <1277684937.79.0.66874412064.issue9085@psf.upfronthosting.co.za>


Tokio Kikuchi <tkikuchi at users.sourceforge.net> added the comment:

I filed this bug because I found email 4.0.2 in Python 2.5 was not suitable for the latest mailman 2.1.13 especially for Japanese environment.  It would be best if you can further bump the Python 2.6 email to 4.0.3 and that of 2.7 to 4.0.4. (Or, 5.0.1 if there is significant change in the behaviour.)
Than you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9085>
_______________________________________

From report at bugs.python.org  Mon Jun 28 02:43:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 00:43:10 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277685790.99.0.096615985495.issue5180@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It looks like I was able to get to the root of the problem.  I am attaching two files that demonstrate the issue:


==> pickle-bug.py <==
import pickle
import sys
class Bug:
    pass
bug = Bug()
f = open(sys.argv[1], 'w')
pickle.Pickler(f, protocol=0).dump(bug)
f.close()

==> unpickle-bug.py <==
import pickle
import sys
class Bug:
    pass
bug = pickle._Unpickler(open(sys.argv[1], 'rb')).load() # works
print(bug)
bug = pickle.Unpickler(open(sys.argv[1], 'rb')).load() # doesn't
print(bug)

$ python2 pickle-bug.py /tmp/bug.pkl
$ python3 unpickle-bug.py /tmp/bug.pkl
<__main__.Bug object at 0x1006b6f40>
Traceback (most recent call last):
  File "unpickle-bug.py", line 7, in <module>
    bug = pickle.Unpickler(open(sys.argv[1], 'rb')).load() # doesn't
_pickle.UnpicklingError: bad pickle data


The problematic pickle is really small, so I hope I'll report that I have a fix soon.

    0: (    MARK
    1: i        INST       '__main__ Bug' (MARK at 0)
   15: p    PUT        0
   18: (    MARK
   19: d        DICT       (MARK at 18)
   20: p    PUT        1
   23: b    BUILD
   24: .    STOP
highest protocol among opcodes = 0

----------
assignee: lemburg -> 
Added file: http://bugs.python.org/file17784/pickle-bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Mon Jun 28 02:43:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 00:43:37 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277685817.03.0.469501467164.issue5180@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17785/unpickle-bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Mon Jun 28 03:25:02 2010
From: report at bugs.python.org (ipatrol)
Date: Mon, 28 Jun 2010 01:25:02 +0000
Subject: [issue3428] httplib.HTTPMessage undocumented
In-Reply-To: <1216746541.05.0.162492292768.issue3428@psf.upfronthosting.co.za>
Message-ID: <1277688302.54.0.514712176112.issue3428@psf.upfronthosting.co.za>


ipatrol <ipatrol6010 at yahoo.com> added the comment:

This is still not fixed. Also, it would be nice to add the response code in somewhere as I don't see it in the stdlib epydoc pages

----------
nosy: +ipatrol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3428>
_______________________________________

From report at bugs.python.org  Mon Jun 28 03:27:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 01:27:10 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277688430.28.0.699450158907.issue5180@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

As promised, here is the fix (issue5180-pickle.diff) for the "unpickle-bug.py" issue.   Unfortunately, it looks like more bugs remain.  27.bench is still not loadable.

----------
stage:  -> unit test needed
Added file: http://bugs.python.org/file17786/issue5180-pickle.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Mon Jun 28 04:11:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 02:11:13 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277691073.84.0.885848979642.issue5180@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The remaining bug is a bit harder.  If you try to run unpickle-bug-2.py on the same pickle, you get

$ python3 unpickle-bug-2.py /tmp/bug.pkl 
<__main__.Bug object at 0x1006a8f40>
Traceback (most recent call last):
  File "unpickle-bug-2.py", line 9, in <module>
    bug = pickle.Unpickler(open(sys.argv[1], 'rb')).load() # doesn't
TypeError: ('__init__() takes exactly 2 arguments (1 given)', <class '__main__.Bug'>, ())


The problem is acknowledged in the source code of instantiate function in _pickle.c:

    /* XXX: The pickle.py module does not create instances this way when the                                             
       args tuple is empty. See Unpickler._instantiate(). */
 

Clearly, this is wrong because pickle.py way succeeds where _pickle does not.


PS: I did not mean to unassign MAL, but I think this is more of alexandre.vassalotti's issue.

----------
assignee:  -> lemburg
Added file: http://bugs.python.org/file17787/unpickle-bug-2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Mon Jun 28 04:11:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Jun 2010 02:11:47 +0000
Subject: [issue9085] Version number inconsistency in email package
In-Reply-To: <1277537275.59.0.8947906135.issue9085@psf.upfronthosting.co.za>
Message-ID: <1277691107.87.0.90603405718.issue9085@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

So you are saying that there are significant differences between the 2.5 email and the 2.6 email?  Can you give any details?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9085>
_______________________________________

From report at bugs.python.org  Mon Jun 28 05:00:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 03:00:05 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277694005.17.0.988442483703.issue5180@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a patch which makes python3 read 27.bench without errors.  I think this should be applied while a complete solution for unpickling old style class instances from text mode (protocol = 0) pickles is found.

----------
Added file: http://bugs.python.org/file17788/issue5180-fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Mon Jun 28 08:00:31 2010
From: report at bugs.python.org (Tokio Kikuchi)
Date: Mon, 28 Jun 2010 06:00:31 +0000
Subject: [issue9085] Version number inconsistency in email package
In-Reply-To: <1277537275.59.0.8947906135.issue9085@psf.upfronthosting.co.za>
Message-ID: <1277704831.07.0.733394933447.issue9085@psf.upfronthosting.co.za>


Tokio Kikuchi <tkikuchi at users.sourceforge.net> added the comment:

I couldn't track down the bug but the symptom is that python 2.5 -- mailman 2.1.13 combination make Japanese message 'mojibake'.  Using only email package for generating message cause no trouble as far as I can check, so the bug may be in mailman (with combination of python 2.5).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9085>
_______________________________________

From report at bugs.python.org  Mon Jun 28 12:20:29 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 28 Jun 2010 10:20:29 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1277694005.17.0.988442483703.issue5180@psf.upfronthosting.co.za>
Message-ID: <4C287769.8030302@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> I am attaching a patch which makes python3 read 27.bench without errors.  I think this should be applied while a complete solution for unpickling old style class instances from text mode (protocol = 0) pickles is found.

Please use a different strategy for "porting" the Unicode tests to
Python3:

Create a new test modules Bytes (which reuses the Strings
tests) and a new test module Strings3 which reuses the Unicode
tests. The Strings3 module should then use the patches you
applied to the Unicode module.

Finally, let the two test module Strings and Unicode fail with
an ImportError in Python3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Mon Jun 28 12:58:44 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 28 Jun 2010 10:58:44 +0000
Subject: [issue3428] httplib.HTTPMessage undocumented
In-Reply-To: <1216746541.05.0.162492292768.issue3428@psf.upfronthosting.co.za>
Message-ID: <1277722724.52.0.590406848841.issue3428@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r82322 and r82323.

Actually urllib.urlopen.info method return a mimetools.Message instance and a HTTPMessage instance is used within httplib only. It is more internal purposes to deal with headers with add_continue like methods is required.

ipatrol, the return codes of HTTP is documented in the httplib documentation.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3428>
_______________________________________

From report at bugs.python.org  Mon Jun 28 13:25:35 2010
From: report at bugs.python.org (Jakub Wilk)
Date: Mon, 28 Jun 2010 11:25:35 +0000
Subject: [issue3990] The Linux2 platform definition is incorrect for alpha,
	hppa, mips, sparc
In-Reply-To: <1222622636.83.0.91904211749.issue3990@psf.upfronthosting.co.za>
Message-ID: <1277724335.82.0.0959279249841.issue3990@psf.upfronthosting.co.za>


Changes by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3990>
_______________________________________

From report at bugs.python.org  Mon Jun 28 13:30:32 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 28 Jun 2010 11:30:32 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1277602289.41.0.933413768888.issue5180@psf.upfronthosting.co.za>
Message-ID: <4C2887D3.3090401@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> The bytes/string issu was a red herring: with pickle.load(open('27.bench', 'b')), I get the same stack trace as from command line pybench invocation.
> 
> 
>>>> pickle.load(open('27.bench', 'rb'))
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "/Users/sasha/Work/python-svn/py3k-commit/Lib/pickle.py", line 1321, in load
>     encoding=encoding, errors=errors).load()
>   File "/Users/sasha/Work/python-svn/py3k-commit/Lib/pickle.py", line 830, in load
>     dispatch[key[0]](self)
>   File "/Users/sasha/Work/python-svn/py3k-commit/Lib/pickle.py", line 1055, in load_inst
>     klass = self.find_class(module, name)
>   File "/Users/sasha/Work/python-svn/py3k-commit/Lib/pickle.py", line 1115, in find_class
>     __import__(module, level=0)
>   File "/Users/sasha/Work/python-svn/py3k-commit/Tools/pybench/Unicode.py", line 17
>     s = unicode(u''.join(map(str,range(100))))
>                   ^
> SyntaxError: invalid syntax

Note that pybench is written in a way that it can handle ImportErrors
and SyntaxErrors gracefully. This is per design, since test modules can
well be written for more recent Python versions that support a certain
features or syntax not present in earlier versions.

In the above case, it may be a good idea to redirect pickle to
the new Strings3 module (see my other message). Likewise, the
Strings test module should redirect to the new Bytes test module
in Python3.

The Unicode and Strings modules should not be loaded in Python3.
Instead, the Bytes and Strings3 modules should be used. This can
be changed in Setup.py of pybench.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Mon Jun 28 13:43:29 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Jun 2010 11:43:29 +0000
Subject: [issue9097] os.chdir(path) to return current dir
In-Reply-To: <1277725409.82.0.324179081421.issue9097@psf.upfronthosting.co.za>
Message-ID: <1277725409.82.0.324179081421.issue9097@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

os.chdir(path) is often used with os.getcwd() call and doesn't return anything. It can return the name of the directory before the change.

prev = os.chdir(path)
...
os.chdir(prev)

Maybe it will also be possible to implement 'with' construct:

with os.chdir(path):
  ...

----------
messages: 108822
nosy: techtonik
priority: normal
severity: normal
status: open
title: os.chdir(path) to return current dir
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9097>
_______________________________________

From report at bugs.python.org  Mon Jun 28 14:16:32 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 Jun 2010 12:16:32 +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: <1277727392.65.0.802471866787.issue8611@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Mon Jun 28 14:43:51 2010
From: report at bugs.python.org (Martin Ellison)
Date: Mon, 28 Jun 2010 12:43:51 +0000
Subject: [issue9098] MSYS build fails with `S_IXGRP' undeclared
In-Reply-To: <1277729031.36.0.263470334817.issue9098@psf.upfronthosting.co.za>
Message-ID: <1277729031.36.0.263470334817.issue9098@psf.upfronthosting.co.za>


New submission from Martin Ellison <martin.ellison at gmail.com>:

Python 2.6.5 build fails on MSYS with the following messages

martin at EDWARD /c/Downloads/Python-2.6.5
$ make
gcc -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -
I. -IInclude -I./Include   -DPy_BUILD_CORE -o Python/import.o Python/import.c
Python/import.c: In function `write_compiled_module':
Python/import.c:882: error: `S_IXGRP' undeclared (first use in this function)
Python/import.c:882: error: (Each undeclared identifier is reported only once
Python/import.c:882: error: for each function it appears in.)
Python/import.c:882: error: `S_IXOTH' undeclared (first use in this function)
Python/import.c: In function `PyImport_ImportModuleNoBlock':
Python/import.c:2063: warning: unused variable `me'
make: *** [Python/import.o] Error 1

----------
components: Build
messages: 108823
nosy: Martin.Ellison
priority: normal
severity: normal
status: open
title: MSYS build fails with `S_IXGRP' undeclared
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9098>
_______________________________________

From report at bugs.python.org  Mon Jun 28 14:55:00 2010
From: report at bugs.python.org (Alexander Myodov)
Date: Mon, 28 Jun 2010 12:55:00 +0000
Subject: [issue9099] multiprocessing/win32:
In-Reply-To: <1277729700.77.0.590017326086.issue9099@psf.upfronthosting.co.za>
Message-ID: <1277729700.77.0.590017326086.issue9099@psf.upfronthosting.co.za>


New submission from Alexander Myodov <amyodov at gmail.com>:

I am using Python 2.6.5/win32, and working with multiprocessing module, doing that with Python interpreter embedded using Cython (if that may be related to the problem).

While creating a subprocess and a Pipe to communicate with it, I've got the following traceback (particulaly on the line "parent_conn, child_conn = Pipe()"):

Traceback (most recent call last):
  File "test_fork.py", line 24, in init test_fork (test_fork.c:810)
    vasia.main()
  File "Z:\multiprocessing_cython_w32\vasia.py", line 15, in main
    parent_conn, child_conn = Pipe()
  File "Z:\python-win32\2.6.5\Lib\multiprocessing\__init__.py", line 106, in Pipe
    return Pipe(duplex)
  File "Z:\python-win32\2.6.5\Lib\multiprocessing\connection.py", line 202, in Pipe
    h2, win32.PIPE_READMODE_MESSAGE, None, None
WindowsError: [Error 0] Success

Lines 202-204 in multiprocessing/connection.py contain the following: 

        win32.SetNamedPipeHandleState(                                                                                             
            h2, win32.PIPE_READMODE_MESSAGE, None, None                                                                            
            ) 

It seems to me that for some reason SetNamedPipeHandleState might be returning 0 even while it didn't fail actually; a quick check confirmed that it could be fixed by changing the above lines to the following:

        try:                                                                                                                       
            win32.SetNamedPipeHandleState(                                                                                         
                h2, win32.PIPE_READMODE_MESSAGE, None, None                                                                        
                )                                                                                                                  
        except WindowsError, e:                                                                                                    
(win32)                                                                                                       
            if e.args[0] != 0: # 0 is error code for SUCCESS                                                                       
                raise

----------
components: Extension Modules, Windows
messages: 108824
nosy: honeyman
priority: normal
severity: normal
status: open
title: multiprocessing/win32:
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9099>
_______________________________________

From report at bugs.python.org  Mon Jun 28 14:57:34 2010
From: report at bugs.python.org (David Kirkby)
Date: Mon, 28 Jun 2010 12:57:34 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1277729854.76.0.678712287044.issue8852@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Thank you Mark for confirming what I found. 

I understand your reservations about the code if you don't know of its correctness. I must admit I don't myself. I don't have a clue how this _socket module should be built. 

But it is clear to me that the original code is attempting to compile code using PACKET_LOOPBACK, PACKET_FASTROUTE and SIOCGIFNAME, despite they are not defined. Although I'm not a mind-reader, I believer the original programmer probably thought they were defined in the header file netpacket/packet.h, when in fact they are not on Solaris. 

I wish I could take Martin v. L?wis up on his "5-for-one deal", where I review 5 issues and he deals with this one. Unfortunately, I'm very new to python, so really are not going to be a lot of help to anyone in reviewing issues. I will just have to keep that patch in Sage until it either gets to the top of Martin's TODO list, or someone else deals with it. 

Dave

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Mon Jun 28 15:00:33 2010
From: report at bugs.python.org (Alexander Myodov)
Date: Mon, 28 Jun 2010 13:00:33 +0000
Subject: [issue9099] multiprocessing/win32: WindowsError: [Error 0] Success on
	Pipe()
In-Reply-To: <1277729700.77.0.590017326086.issue9099@psf.upfronthosting.co.za>
Message-ID: <1277730033.77.0.809382443208.issue9099@psf.upfronthosting.co.za>


Alexander Myodov <amyodov at gmail.com> added the comment:

Sorry for formatting above, a copypaste issue.

The lines 202-204:
        win32.SetNamedPipeHandleState(
            h2, win32.PIPE_READMODE_MESSAGE, None, None
            )

The change that fixes the problem (at least for me):
        try:
            win32.SetNamedPipeHandleState(
                h2, win32.PIPE_READMODE_MESSAGE, None, None
                )
        except WindowsError, e:
            if e.args[0] != 0: # 0 is error code for SUCCESS
                raise

----------
title: multiprocessing/win32: -> multiprocessing/win32: WindowsError: [Error 0] Success on Pipe()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9099>
_______________________________________

From report at bugs.python.org  Mon Jun 28 15:00:56 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 28 Jun 2010 13:00:56 +0000
Subject: [issue9098] MSYS build fails with `S_IXGRP' undeclared
In-Reply-To: <1277729031.36.0.263470334817.issue9098@psf.upfronthosting.co.za>
Message-ID: <1277730056.49.0.243936148639.issue9098@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I don't think MSYS (or mingw32) is supported at all.
I'm even surprised that the build went so far.

----------
assignee:  -> loewis
nosy: +amaury.forgeotdarc, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9098>
_______________________________________

From report at bugs.python.org  Mon Jun 28 15:27:43 2010
From: report at bugs.python.org (Zsolt Cserna)
Date: Mon, 28 Jun 2010 13:27:43 +0000
Subject: [issue9100] test_sysconfig fails (test_user_similar)
In-Reply-To: <1277731663.45.0.56366593786.issue9100@psf.upfronthosting.co.za>
Message-ID: <1277731663.45.0.56366593786.issue9100@psf.upfronthosting.co.za>


New submission from Zsolt Cserna <zsolt.cserna at morganstanley.com>:

Python 2.7rc2

test_user_similar test in test_sysconfig fails for me. I think it's because I have different --exec-prefix and --prefix specified. The test assumes that get_config_var('base') is the part of the global_path = get_path('platstdlib', 'posix_prefix') which is not necessarily true.

I've attached the pdb output containing the variable names.

----------
components: Tests
files: pdb_test_user_similar.txt
messages: 108828
nosy: csernazs
priority: normal
severity: normal
status: open
title: test_sysconfig fails (test_user_similar)
versions: Python 2.7
Added file: http://bugs.python.org/file17789/pdb_test_user_similar.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9100>
_______________________________________

From report at bugs.python.org  Mon Jun 28 15:30:35 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 28 Jun 2010 13:30:35 +0000
Subject: [issue9097] os.chdir(path) to return current dir
In-Reply-To: <1277725409.82.0.324179081421.issue9097@psf.upfronthosting.co.za>
Message-ID: <1277731835.15.0.436157261401.issue9097@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

-0 for having os.chdir be responsible for the previous directory. I'm not too much against this, but it's very easily done in it's current state.

-1 for making os.chdir into a context manager which reverts itself upon exit. There are a number of race conditions this would have to handle and I think it's better for something like this to be implemented by the user. For example, if the original directory gets removed while you are within the block, what is the best fallback directory to change to upon exit? For the standard library, I don't think we can answer that.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9097>
_______________________________________

From report at bugs.python.org  Mon Jun 28 15:32:22 2010
From: report at bugs.python.org (Martin Ellison)
Date: Mon, 28 Jun 2010 13:32:22 +0000
Subject: [issue9098] MSYS build fails with `S_IXGRP' undeclared
In-Reply-To: <1277730056.49.0.243936148639.issue9098@psf.upfronthosting.co.za>
Message-ID: <AANLkTik8R7tux2z7l4fcHhgk1avJroL01FKc7Svy9Ec6@mail.gmail.com>


Martin Ellison <martin.ellison at gmail.com> added the comment:

I thought Python ran everywhere. That's what the documentation says.

Regards,
Martin
(m.e at acm.org)

On 28 June 2010 21:00, Amaury Forgeot d'Arc <report at bugs.python.org> wrote:

>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> I don't think MSYS (or mingw32) is supported at all.
> I'm even surprised that the build went so far.
>
> ----------
> assignee:  -> loewis
> nosy: +amaury.forgeotdarc, loewis
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue9098>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file17790/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9098>
_______________________________________
-------------- next part --------------
I thought Python ran everywhere. That&#39;s what the documentation says.<br><br clear="all">Regards,<br>Martin<br>(<a href="mailto:m.e at acm.org">m.e at acm.org</a>)<br>
<br><br><div style="margin: 0pt;" name="sig_c36e5b1594"></div><div class="gmail_quote">On 28 June 2010 21:00, 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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); 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>
I don&#39;t think MSYS (or mingw32) is supported at all.<br>
I&#39;m even surprised that the build went so far.<br>
<br>
----------<br>
assignee: ??-&gt; loewis<br>
nosy: +amaury.forgeotdarc, loewis<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/issue9098" target="_blank">http://bugs.python.org/issue9098</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Mon Jun 28 15:55:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Jun 2010 13:55:15 +0000
Subject: [issue9099] multiprocessing/win32: WindowsError: [Error 0] Success on
	Pipe()
In-Reply-To: <1277729700.77.0.590017326086.issue9099@psf.upfronthosting.co.za>
Message-ID: <1277733315.34.0.352557393757.issue9099@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9099>
_______________________________________

From report at bugs.python.org  Mon Jun 28 16:04:34 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 28 Jun 2010 14:04:34 +0000
Subject: [issue9098] MSYS build fails with `S_IXGRP' undeclared
In-Reply-To: <1277729031.36.0.263470334817.issue9098@psf.upfronthosting.co.za>
Message-ID: <1277733874.74.0.673429942942.issue9098@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

> I thought Python ran everywhere. That's what the documentation says.

Python does *run* on Windows (when compiled with Visual Studio or gcc via Cygwin), it just might not be setup to build with the MSYS compiler.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9098>
_______________________________________

From report at bugs.python.org  Mon Jun 28 16:13:26 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 28 Jun 2010 14:13:26 +0000
Subject: [issue8653] urlparse.urlparse/urlsplit doc missing
In-Reply-To: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>
Message-ID: <1277734406.1.0.6327977902.issue8653@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r82324, r82325, r82326, r82327.
Only the urlunsplit need the docstrings, I added that.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8653>
_______________________________________

From report at bugs.python.org  Mon Jun 28 17:37:23 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Jun 2010 15:37:23 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Quite often people use .json files for storing configuration. Having a reference to json module from chapter "14. File Formats" would be a good pointer for those looking to .ini alternatives.

----------
assignee: docs at python
components: Documentation
messages: 108833
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: reference json format in file formats chapter
versions: Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9101>
_______________________________________

From report at bugs.python.org  Mon Jun 28 17:42:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 15:42:02 +0000
Subject: [issue9102] pybench: Cannot compare 2.x and 3.x benchmarks
In-Reply-To: <1277739722.07.0.677340784013.issue9102@psf.upfronthosting.co.za>
Message-ID: <1277739722.07.0.677340784013.issue9102@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

There are several issues that prevent

$ python3 Tools/pybench/pybench.py -s 27.bench -c 32.bench

from working.

1. There is a bug in _pickle that prevents 2.x pickles that contain classic class instances from loading in 3.x.  This is addressed in issue5180.

2. Once _pickle issue is addresses, 2.7 benchmark files still cannot be loaded because they contain references to the Unicode tests and Unicode.py is not loadable in python3.

3. Once Unicode.py gets 2to3 treatment, we are still left with 

* Benchmark versions differ: cannot compare this benchmark to "32.bench" !


The last issue is probably the simplest.  Version number was bumped up in r69411, and a log entry says that the intent was to keep pybench 2.1 compatible with 2.x.  Indeed, pybench 2.1 from py3k runs under trunk python and resulting benchmark file can be compared with 3.x generated benchmark once issues 1 and 2 above are resolved.  It may, however be worth consideration to synchronize pybench versions shipped with 27 and 32.  I understand that this is likely to be too late for 2.7, but I am checking 2.7 version in case this is considered appropriate for 2.7.1.

The Unicode.py issue was discussed under issue5180 in msg108819 and msg108821.  I like MAL's suggestion of Strings3 module, but I think it would be useful to be able to compare 2.x str performance to both 3.x str and 3.x bytes.  Similarly, I think String3 should have from __future__ import unicode_literals and be loadable in 2.7/2.6 and server as means to compare 2.x and 3.x unicode performance.

For the _pickle issue, I am about to attach a patch to issue5180.

----------
components: Demos and Tools
messages: 108834
nosy: belopolsky, lemburg, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: pybench: Cannot compare 2.x and 3.x benchmarks
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9102>
_______________________________________

From report at bugs.python.org  Mon Jun 28 17:45:03 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 28 Jun 2010 15:45:03 +0000
Subject: [issue9097] os.chdir(path) to return current dir
In-Reply-To: <1277725409.82.0.324179081421.issue9097@psf.upfronthosting.co.za>
Message-ID: <1277739903.77.0.426731128321.issue9097@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

-1 on chdir returning a the directory name.
-1 on having it as context manager.

Both are non-intuitive and may not serve any utility value. This can be verified by looking the code at the places where these functions are currently used. Brian also mentions about the dangers in that approach.
.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9097>
_______________________________________

From report at bugs.python.org  Mon Jun 28 18:08:22 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 16:08:22 +0000
Subject: [issue9102] pybench: Cannot compare 2.x and 3.x benchmarks
In-Reply-To: <1277739722.07.0.677340784013.issue9102@psf.upfronthosting.co.za>
Message-ID: <1277741302.96.0.736269149674.issue9102@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
dependencies: +3.1 cannot unpickle 2.7-created pickle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9102>
_______________________________________

From report at bugs.python.org  Mon Jun 28 18:09:41 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Jun 2010 16:09:41 +0000
Subject: [issue9103] API keyword
In-Reply-To: <AANLkTil4-Bf0gK-zXTGP7vWbWpFQ9uvON6wK_2ZGBies@mail.gmail.com>
Message-ID: <AANLkTil4-Bf0gK-zXTGP7vWbWpFQ9uvON6wK_2ZGBies@mail.gmail.com>


New submission from anatoly techtonik <techtonik at gmail.com>:

Need API keyword to filter refused API proposals.
-- 
anatoly t.

----------
messages: 108836
nosy: techtonik
priority: normal
severity: normal
status: open
title: API keyword

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9103>
_______________________________________

From report at bugs.python.org  Mon Jun 28 18:10:52 2010
From: report at bugs.python.org (ipatrol)
Date: Mon, 28 Jun 2010 16:10:52 +0000
Subject: [issue3428] httplib.HTTPMessage undocumented
In-Reply-To: <1216746541.05.0.162492292768.issue3428@psf.upfronthosting.co.za>
Message-ID: <1277741452.4.0.100893832294.issue3428@psf.upfronthosting.co.za>


ipatrol <ipatrol6010 at yahoo.com> added the comment:

What about urllib2? It's explicitly mentioned as the return value of .info()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3428>
_______________________________________

From report at bugs.python.org  Mon Jun 28 18:12:00 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Jun 2010 16:12:00 +0000
Subject: [issue9103] API keyword
In-Reply-To: <AANLkTil4-Bf0gK-zXTGP7vWbWpFQ9uvON6wK_2ZGBies@mail.gmail.com>
Message-ID: <1277741520.01.0.483212398886.issue9103@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Please post on meta-tracker.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9103>
_______________________________________

From report at bugs.python.org  Mon Jun 28 18:12:27 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Jun 2010 16:12:27 +0000
Subject: [issue9103] API keyword
In-Reply-To: <AANLkTil4-Bf0gK-zXTGP7vWbWpFQ9uvON6wK_2ZGBies@mail.gmail.com>
Message-ID: <1277741547.42.0.160362089283.issue9103@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Oops. Wrong tracker http://psf.upfronthosting.co.za/roundup/meta/issue341

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9103>
_______________________________________

From report at bugs.python.org  Mon Jun 28 18:18:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 16:18:12 +0000
Subject: [issue9104] test_exceptions does not test pickling with pickle.py
In-Reply-To: <1277741892.3.0.0849773844587.issue9104@psf.upfronthosting.co.za>
Message-ID: <1277741892.3.0.0849773844587.issue9104@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

This is probably one example of many where pickling is only tested with _pickle module if it is available rather than separately with C and Python implementation.  I am attaching a patch which implements one possible testing strategy.  If this is acceptable, I think the machinery of retrieving multiple module implementations should be moved to test.support and reused in other test modules.

----------
components: Library (Lib)
files: test_exceptions.diff
keywords: patch
messages: 108840
nosy: alexandre.vassalotti, belopolsky, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: test_exceptions does not test pickling with pickle.py
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17791/test_exceptions.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9104>
_______________________________________

From report at bugs.python.org  Mon Jun 28 18:50:11 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Jun 2010 16:50:11 +0000
Subject: [issue9097] os.chdir(path) to return current dir
In-Reply-To: <1277725409.82.0.324179081421.issue9097@psf.upfronthosting.co.za>
Message-ID: <1277743811.43.0.832097170385.issue9097@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Brian, in case you remove previous directory - you will get the same exception that in the following code.

prev = os.chdir(somepath)
os.rmdir(prev)
os.chdir(prev)

Senthil, your arguments are strange. Both use cases are at least useful for me (if not intuitive). I also can't see how can I verify you assumptions by looking at the code. If you want to say that not every piece of code need to return to parent directory after chdir - that's pretty obvious. If you had a list of use cases for os.chdir() - I could go through them to mark where this can be used (or not).

label:api

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9097>
_______________________________________

From report at bugs.python.org  Mon Jun 28 18:58:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 16:58:30 +0000
Subject: [issue9104] test_exceptions does not test pickling with pickle.py
In-Reply-To: <1277741892.3.0.0849773844587.issue9104@psf.upfronthosting.co.za>
Message-ID: <1277744310.25.0.531843632045.issue9104@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9104>
_______________________________________

From report at bugs.python.org  Mon Jun 28 19:04:54 2010
From: report at bugs.python.org (=?utf-8?q?Domen_Ko=C5=BEar?=)
Date: Mon, 28 Jun 2010 17:04:54 +0000
Subject: [issue9077] argparse does not handle arguments correctly after --
In-Reply-To: <1277422498.3.0.635108415577.issue9077@psf.upfronthosting.co.za>
Message-ID: <1277744694.62.0.489884119317.issue9077@psf.upfronthosting.co.za>


Domen Ko?ar <ielectric at gmail.com> added the comment:

I always used optparse like this, using the rargs (maybe this is not main intention, but worked so far):

>>> import optparse
>>> parser = optparse.OptionParser()
>>> parser.add_option('--test', action='store_true')
<Option at 0x7f55bdb32dd0: --test>
>>> parser.parse_args(['--test', 'foo', 'foo1', '--', 'foo2', 'foo3'])
(<Values at 0x7f55bda89170: {'test': True}>, ['foo', 'foo1', 'foo2', 'foo3'])
>>> parser.rargs
['foo2', 'foo3']
>>> parser.largs
['foo', 'foo1']

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9077>
_______________________________________

From report at bugs.python.org  Mon Jun 28 19:08:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jun 2010 17:08:19 +0000
Subject: [issue9104] test_exceptions does not test pickling with pickle.py
In-Reply-To: <1277741892.3.0.0849773844587.issue9104@psf.upfronthosting.co.za>
Message-ID: <1277744899.81.0.0796810146386.issue9104@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It looks good on the principle. As you say, factoring out this kind of machinery in test.support is probably the way to go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9104>
_______________________________________

From report at bugs.python.org  Mon Jun 28 19:09:34 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 28 Jun 2010 17:09:34 +0000
Subject: [issue3428] httplib.HTTPMessage undocumented
In-Reply-To: <1277741452.4.0.100893832294.issue3428@psf.upfronthosting.co.za>
Message-ID: <20100628170922.GB10019@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

That was a Documentation mistake. Thanks for pointing out.
Corrected it in revision 82334 and merged to other branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3428>
_______________________________________

From report at bugs.python.org  Mon Jun 28 19:14:55 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 28 Jun 2010 17:14:55 +0000
Subject: [issue9097] os.chdir(path) to return current dir
In-Reply-To: <1277743811.43.0.832097170385.issue9097@psf.upfronthosting.co.za>
Message-ID: <20100628171446.GC10019@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Mon, Jun 28, 2010 at 04:50:12PM +0000, anatoly techtonik wrote:
>I also can't see how can I verify you assumptions by looking at the code.

In the python source:

find -name "*.py" | xargs grep 'os.chdir'

gives 143 instances of its usage. 

I looked a couple of them (subprocess.py, forking.py) and found that
returning a value as per your suggestion would add in an additional
line of code instead of any obvious advantage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9097>
_______________________________________

From report at bugs.python.org  Mon Jun 28 19:20:54 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 17:20:54 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277745654.55.0.77581115264.issue5180@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a patch which focuses on fixing _pickle behavior.   I opened a separate issue9102 to deal with pybench specific problems.

Marc-Andre,

I am reassigning this issue to myself and assigning issue9102 to you.  I hope you don't mind.

My patch attempts to emulate 2.x PyInstance_NewRaw with a call to tp_alloc.  I considered using tp_new, but although __new__ is not special for classic classes, there is nothing to prevent users to define __new__ in their classic classes or add __new__ when they port these classes to 3.x.  (BTW, I wonder what 2to3 does if classic class has __new__ defined.)  This is slightly unorthodox use of tp_alloc, so I will follow up with a question on python-dev.

----------
assignee: lemburg -> belopolsky
nosy: +mark.dickinson
Added file: http://bugs.python.org/file17792/issue5180.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Mon Jun 28 19:25:56 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Jun 2010 17:25:56 +0000
Subject: [issue9105] pickle security note should be more prominent
In-Reply-To: <1277745956.4.0.951690442784.issue9105@psf.upfronthosting.co.za>
Message-ID: <1277745956.4.0.951690442784.issue9105@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Pickle warning about insecurity is located only at the second page near the bottom of "Relationship to other Python modules" chapter. For me the proper place for it is the first page of documentation.

----------
assignee: docs at python
components: Documentation
messages: 108847
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: pickle security note should be more prominent
versions: Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9105>
_______________________________________

From report at bugs.python.org  Mon Jun 28 19:34:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 17:34:49 +0000
Subject: [issue9105] pickle security note should be more prominent
In-Reply-To: <1277745956.4.0.951690442784.issue9105@psf.upfronthosting.co.za>
Message-ID: <1277746489.31.0.303509315992.issue9105@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

See also issue8855.

I believe Anatoly refers to 

http://docs.python.org/py3k/library/pickle.html

I agree, the warning can be moved up so that it is visible on the first page in typical rendering.

Note that there is also

http://docs.python.org/py3k/tutorial/inputoutput.html#the-pickle-module

which contains no warning at all.

----------
keywords: +easy
nosy: +belopolsky
stage:  -> needs patch
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9105>
_______________________________________

From report at bugs.python.org  Mon Jun 28 19:40:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Jun 2010 17:40:05 +0000
Subject: [issue9097] os.chdir(path) to return current dir
In-Reply-To: <1277725409.82.0.324179081421.issue9097@psf.upfronthosting.co.za>
Message-ID: <1277746805.8.0.585648102447.issue9097@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In addition, os functions tend to be thin wrappers around system functions, and the system chdir does not return the cwd.  Thus we'd be adding code to chdir that would be executed every time it was called even though it would only be used occasionally.  Given that it only saves one line of python code in those same restricted cases, this does not seem like a sensible addition.

You can, of course, write your own function that does this.

The same is true of the idea of a chdir context manager: you can trivially write your own if you don't care about the issues Brian raised.  If you do care then we'd have to figure out how to handle those issues.  And how to handle them is different on different OSes (and I'm not just talking about windows vs posix, either; what happens when you delete the cwd differs on the different unix flavors).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9097>
_______________________________________

From report at bugs.python.org  Mon Jun 28 20:28:24 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Jun 2010 18:28:24 +0000
Subject: [issue9106] remove numbers from 3-.. level entries in docs toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

It seems that left side ToC menu will be more clear without numeric prefixes from chapter on 3-.. nesting levels. How about to remove them?

For example - the ToC menu now starting from root level:

15.6. logging ? Logging facility for Python
    * 15.6.1. Logging tutorial
          o 15.6.1.1. Simple examples
          o 15.6.1.2. Loggers
          o 15.6.1.3. Handlers
          o 15.6.1.4. Formatters
          o 15.6.1.5. Configuring Logging
          o 15.6.1.6. Configuring Logging for a Library
    * 15.6.2. Logging Levels
    * 15.6.3. Useful Handlers
...

will look like:

15.6. logging ? Logging facility for Python
    * 1. Logging tutorial
          o 1.1. Simple examples
          o 1.2. Loggers
          o 1.3. Handlers
          o 1.4. Formatters
          o 1.5. Configuring Logging
          o 1.6. Configuring Logging for a Library
    * 2. Logging Levels
    * 3. Useful Handlers
...

----------
assignee: docs at python
components: Documentation
messages: 108850
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: remove numbers from 3-.. level entries in docs toc
versions: Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9106>
_______________________________________

From report at bugs.python.org  Mon Jun 28 20:30:16 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Jun 2010 18:30:16 +0000
Subject: [issue9105] pickle security note should be more prominent
In-Reply-To: <1277745956.4.0.951690442784.issue9105@psf.upfronthosting.co.za>
Message-ID: <1277749816.56.0.221141467649.issue9105@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Also http://docs.python.org/library/pickle.html

http://docs.python.org/library/logging.html#sending-and-receiving-logging-events-across-a-network
and
http://mail.python.org/pipermail/python-dev/2010-June/101179.html

The link to Nadia blog is also very helpful for investigation of pickle problems http://nadiana.com/python-pickle-insecure

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9105>
_______________________________________

From report at bugs.python.org  Mon Jun 28 20:31:19 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 28 Jun 2010 18:31:19 +0000
Subject: [issue9045] 2.7rc1: 64-bit OSX installer is not built with 64-bit
	tkinter
In-Reply-To: <1277642911.08.0.532507309123.issue9045@psf.upfronthosting.co.za>
Message-ID: <DDF29E90-EA3D-490B-859C-71F1346C2841@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On 2010-06-27, at 5:48 AM, Ronald Oussoren wrote:

> Even when building using an SDK you can use frameworks in /Library/Frameworks because $SDKROOT/Library/Frameworks is a symlink to the real /Library/Frameworks.

When building on 10.6, we are relying on Apple's Tcl/Tk 8.5 in /System/Library/Frameworks 

But 10.5 SDK only has Tcl/Tk 8.4 (i386+ppc) on a 10.6 machine:
$ ls -l /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Tcl.framework/Versions/
total 8
drwxr-xr-x  3 root  wheel  170 19 Jan 18:21 8.4
lrwxr-xr-x  1 root  wheel    3 19 Jan 18:19 Current -> 8.4

For Python 2.7, do you think it is possible to use the (64-bit) Tcl/Tk 8.5 from /System/Library/Framework when building with 10.5 SDK on a 10.6 machine?

-srid

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9045>
_______________________________________

From report at bugs.python.org  Mon Jun 28 20:37:50 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 18:37:50 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277750270.73.0.50549987355.issue5180@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17781/issue5180.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Mon Jun 28 20:38:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 18:38:03 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277750283.14.0.155614222663.issue5180@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17788/issue5180-fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Mon Jun 28 20:38:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 18:38:48 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277750328.52.0.801077725737.issue5180@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Mon Jun 28 20:45:22 2010
From: report at bugs.python.org (S Arrowsmith)
Date: Mon, 28 Jun 2010 18:45:22 +0000
Subject: [issue4963] mimetypes.guess_extension result changes after
	mimetypes.init()
In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>
Message-ID: <1277750722.24.0.158126797779.issue4963@psf.upfronthosting.co.za>


S Arrowsmith <siona at chiark.greenend.org.uk> added the comment:

I've dug into it -- again -- and my original analysis still holds. Getting consistent guess_extension() results across an explicit init() call depends on dict.items() returning keys in the same order on two different dictionaries (the original, hard-coded types_map and the one created by the first, implicit init() call).

Why should this be different on Debian to other Linuxes, even given same data as a "working" distribution? Is there something in the implementation details of dict.items() which is that distribution dependent?

(A "fix", BTW, is to insert a call to _default_mime_types() either in init() or in MimeTypes.__init__ before it calls init().)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4963>
_______________________________________

From report at bugs.python.org  Mon Jun 28 21:30:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 19:30:05 +0000
Subject: [issue9104] test_exceptions does not test pickling with pickle.py
In-Reply-To: <1277741892.3.0.0849773844587.issue9104@psf.upfronthosting.co.za>
Message-ID: <1277753405.4.0.611383489425.issue9104@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

In the new patch, issue9104.diff, I factored out import machinery into test.support.import_module_implementations and added it to a a couple of other test modules.  I did not attempt to improve all pickle tests.

The availability of import_module_implementations raises an interesting question of what to do in cases like heapq where one can potentially test 4 combinations of heapq/_heapq with pickle/_pickle.  Given that currently pickling of heapq objects is either not supported or not tested, we don't need to worry about it, but as parallel optimized/pure python module implementations proliferate, we may face exponential explosion of potential test cases.

----------
Added file: http://bugs.python.org/file17793/issue9104.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9104>
_______________________________________

From report at bugs.python.org  Mon Jun 28 21:30:57 2010
From: report at bugs.python.org (Krauzi)
Date: Mon, 28 Jun 2010 19:30:57 +0000
Subject: [issue9107] PyModule_Create not working properly
In-Reply-To: <1277753457.53.0.646916927225.issue9107@psf.upfronthosting.co.za>
Message-ID: <1277753457.53.0.646916927225.issue9107@psf.upfronthosting.co.za>


New submission from Krauzi <krauzi_gmbh at yahoo.de>:

Hi guys i have a big problem with my code:
PyModule_Create doesnt add any methods to the module (all methods are correctly added to the PyMethodDef structure respective the PyModuleDef).
With python 2.6.5 everything works well (Py_InitModule used instead of PyModule_Create [+ PyImport_AddModule]).
I looked into the source but everything seems correct there.

The code worked neither Visual Studio 2010 nor on 2008.

----------
components: None
messages: 108855
nosy: Krauzi
priority: normal
severity: normal
status: open
title: PyModule_Create not working properly
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9107>
_______________________________________

From report at bugs.python.org  Mon Jun 28 21:31:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 19:31:44 +0000
Subject: [issue9104] test_exceptions does not test pickling with pickle.py
In-Reply-To: <1277741892.3.0.0849773844587.issue9104@psf.upfronthosting.co.za>
Message-ID: <1277753504.14.0.887819182123.issue9104@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17793/issue9104.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9104>
_______________________________________

From report at bugs.python.org  Mon Jun 28 21:32:54 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 19:32:54 +0000
Subject: [issue9104] test_exceptions does not test pickling with pickle.py
In-Reply-To: <1277741892.3.0.0849773844587.issue9104@psf.upfronthosting.co.za>
Message-ID: <1277753574.95.0.550670256207.issue9104@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17794/issue9104.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9104>
_______________________________________

From report at bugs.python.org  Mon Jun 28 21:35:38 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 28 Jun 2010 19:35:38 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1277753738.67.0.335360077661.issue2986@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The discussion on #152807 references two other closed tracker issues:
#1678339 Test case that currently fails
#1678345 Patch to change behavior - rejected because crippled behavior is supposedly intentional and removing the change would slow things down.

The patch simply removes the internal heuristic. I think a better patch would be to make it optional, with a tunable popularity threshold.

I say 'supposedly intentional' because the code comments only justify the popularity hack for code line comparison and give no indication of awareness that it disables SequenceMatcher for general purpose use, and in particular, for non-toy finite character set comparisons of the type (ascii) used in all the examples.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Mon Jun 28 22:24:31 2010
From: report at bugs.python.org (ThomasH)
Date: Mon, 28 Jun 2010 20:24:31 +0000
Subject: [issue3430] httplib.HTTPResponse documentations inconsistent
In-Reply-To: <1216747880.73.0.0581734704537.issue3430@psf.upfronthosting.co.za>
Message-ID: <1277756671.59.0.320385960123.issue3430@psf.upfronthosting.co.za>


ThomasH <thomas.bugzilla at gmx.net> added the comment:

Still applies. Neither the 2.7 documentation has changed (judging from the current online dev docs), nor the implementation (judging from current svn). So my first two lists are still valid. I cannot comment on the third, as I don't have a 2.7 installation at hand, or will have any time soon.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3430>
_______________________________________

From report at bugs.python.org  Mon Jun 28 22:28:10 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 28 Jun 2010 20:28:10 +0000
Subject: [issue9094] Make python-m pickletools do something useful
In-Reply-To: <1277680335.26.0.237686854485.issue9094@psf.upfronthosting.co.za>
Message-ID: <1277756890.53.0.692424324358.issue9094@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Good idea! 

You can remove the doctest behavior. I don't think it is useful. But if you remove it, make sure you add an usage message when no argument is given.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9094>
_______________________________________

From report at bugs.python.org  Mon Jun 28 22:32:29 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 28 Jun 2010 20:32:29 +0000
Subject: [issue9045] 2.7rc1: 64-bit OSX installer is not built with 64-bit
	tkinter
In-Reply-To: <1277143341.0.0.74848452771.issue9045@psf.upfronthosting.co.za>
Message-ID: <1277757149.84.0.87130515587.issue9045@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

I tried patching setup.py to force linking to Apple's Tcl/Tk:

--- python/setup.py.original	2010-06-28 11:40:26.000000000 -0700
+++ python/setup.py	2010-06-28 11:45:39.000000000 -0700
@@ -1682,6 +1682,15 @@
         for F in framework_dirs:
             # both Tcl.framework and Tk.framework should be present
 
+            # When building for 64-bit (presumably on 10.6, with 10.5 SDK),
+            # skip the SDK Tcl/Tk and instead use the one on /System/Library
+            # which is Apple's Tcl/Tk 8.5 with 64-bit.
+            if PT_CONFIG_mac_64bit:
+                F = '/System/Library/Frameworks/' # force Apple's one
+                for fw in 'Tcl', 'Tk':
+                    if not exists(join(F, fw + '.framework')):
+                        raise IOError('No %s found in %s' % (fw, F))
+                break
 
             for fw in 'Tcl', 'Tk':
                 if is_macosx_sdk_path(F):


But unfortunately, even though we use 8.5 header files ... the link line uses `-isysroot`, thereby linking to 8.4:

gcc -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.5.sdk/ -isysroot /Developer/SDKs/MacOSX10.5.sdk/ -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.5.sdk/ -isysroot /Developer/SDKs/MacOSX10.5.sdk/ build/temp.macosx-10.5-intel-2.7/Users/sridharr/as/apy/trunk/build/pyhg_trunk-macosx-hgtip27/python/Modules/_tkinter.o build/temp.macosx-10.5-intel-2.7/Users/sridharr/as/apy/trunk/build/pyhg_trunk-macosx-hgtip27/python/Modules/tkappinit.o -L/Library/Frameworks/Python.framework/Versions/2.7/lib -o build/lib.macosx-10.5-intel-2.7/_tkinter.so -framework Tcl -framework Tk
ld: warning: in /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks//Tk.framework/Tk, missing required architecture x86_64 in file
*** WARNING: renaming "_tkinter" since importing it failed: dlopen(build/lib.macosx-10.5-intel-2.7/_tkinter.so, 2): Symbol not found: _Tk_GetNumMainWindows

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9045>
_______________________________________

From report at bugs.python.org  Mon Jun 28 22:36:54 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 28 Jun 2010 20:36:54 +0000
Subject: [issue9104] test_exceptions does not test pickling with pickle.py
In-Reply-To: <1277741892.3.0.0849773844587.issue9104@psf.upfronthosting.co.za>
Message-ID: <1277757414.95.0.762900576208.issue9104@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

The code for import_module_implementations seems a bit fragile. Prefixing the module name with an underscore might not always yield the name of the optimized implementation.  An explicit dictionary to map the Python and C implementations may be a better approach.

Otherwise, the code looks good. Feel free to commit it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9104>
_______________________________________

From report at bugs.python.org  Mon Jun 28 22:42:41 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 28 Jun 2010 20:42:41 +0000
Subject: [issue3430] httplib.HTTPResponse documentations inconsistent
In-Reply-To: <1216747880.73.0.0581734704537.issue3430@psf.upfronthosting.co.za>
Message-ID: <1277757761.67.0.306138043536.issue3430@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Yes, I know httplib documentation needs improvement. There is a great deal of documentation in the module itself. A lot can be .rst'ifed.

----------
assignee: georg.brandl -> orsenthil
nosy: +orsenthil
resolution:  -> accepted
stage:  -> needs patch
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3430>
_______________________________________

From report at bugs.python.org  Mon Jun 28 22:46:12 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 28 Jun 2010 20:46:12 +0000
Subject: [issue655802] cPickle not always same as pickle
Message-ID: <1277757972.22.0.259398675017.issue655802@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

It's a documentation enhancement request. The updated documentation in Python 3 for pickle added most of the requested details.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue655802>
_______________________________________

From report at bugs.python.org  Mon Jun 28 22:51:35 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 28 Jun 2010 20:51:35 +0000
Subject: [issue9098] MSYS build fails with `S_IXGRP' undeclared
In-Reply-To: <1277729031.36.0.263470334817.issue9098@psf.upfronthosting.co.za>
Message-ID: <1277758295.61.0.726002616889.issue9098@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Martin (Ellison): What people are trying to say is that likely, nobody will be working on this, and likely so for the next few years. So unless you volunteer to provide a patch, I recommend to close the issue as "won't fix". Unassigning myself.

----------
assignee: loewis -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9098>
_______________________________________

From report at bugs.python.org  Mon Jun 28 22:51:55 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 28 Jun 2010 20:51:55 +0000
Subject: [issue1536] pickle's documentation is severely outdated
In-Reply-To: <1196535861.35.0.87845321139.issue1536@psf.upfronthosting.co.za>
Message-ID: <1277758315.56.0.112902272743.issue1536@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

The new documentation for pickle in Python 3 fixes this.

I still believe we should outline the differences between pickle.py and cPickle. But at this point, it's unlikely I will put the time to do it. Feel free to open a new issue if you want this to be done.

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1536>
_______________________________________

From report at bugs.python.org  Mon Jun 28 22:51:58 2010
From: report at bugs.python.org (ThomasH)
Date: Mon, 28 Jun 2010 20:51:58 +0000
Subject: [issue3428] httplib.HTTPMessage undocumented
In-Reply-To: <1216746541.05.0.162492292768.issue3428@psf.upfronthosting.co.za>
Message-ID: <1277758318.45.0.874145546983.issue3428@psf.upfronthosting.co.za>


ThomasH <thomas.bugzilla at gmx.net> added the comment:

> Actually urllib.urlopen.info method return a mimetools.Message instance

But the urllib.rst documentation is still flawed:

"The :meth:`info` method returns an instance of the class :class:`httplib.HTTPMessage`"

(http://svn.python.org/view/python/trunk/Doc/library/urllib.rst?revision=81775&view=markup)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3428>
_______________________________________

From report at bugs.python.org  Mon Jun 28 22:58:19 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 28 Jun 2010 20:58:19 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277758699.73.0.113040427984.issue5180@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Thank you for the nice investigative work! 

I will try my best to review this patch by next week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Mon Jun 28 23:00:58 2010
From: report at bugs.python.org (Casey McGinty)
Date: Mon, 28 Jun 2010 21:00:58 +0000
Subject: [issue6589] smtpd.SMTPServer can cause asyncore.loop to enter
	infinite event loop
In-Reply-To: <1248753598.39.0.190804723361.issue6589@psf.upfronthosting.co.za>
Message-ID: <1277758858.7.0.34774892515.issue6589@psf.upfronthosting.co.za>


Casey McGinty <casey.mcginty at gmail.com> added the comment:

This is how it gets in an "invalid state". Not sure why you can't look at the code and see the mistake.

"There is no code in the
SMTPServere.__init__ method that catches the exception raised, caused by
the failed bind attempt. After the exception is caught, the first thread
continues to run, but asyncore is in an invalid state because it still
has the registration of the second SMTPServer instance that never completed."

As far as running in a thread. I have a program that needs must start and stop the SMTPServer dynamically. I did this by putting SMTPServer in a thread. Maybe there is another way to do it, but if you are not going to support this, then it should be documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6589>
_______________________________________

From report at bugs.python.org  Mon Jun 28 23:04:34 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 28 Jun 2010 21:04:34 +0000
Subject: [issue9097] os.chdir(path) to return current dir
In-Reply-To: <1277725409.82.0.324179081421.issue9097@psf.upfronthosting.co.za>
Message-ID: <1277759074.37.0.884370417972.issue9097@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

-1 on this functionality being in os, for the same reasons David mentions.

I find both of these behaviors useful and I have small utility functions of my own that do the same (and ignore any errors). I'm not so sure they need to be in stdlib, though. As mentioned, you need to either handle the errors, or do what I do and just fail if any of these conditions arise.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9097>
_______________________________________

From report at bugs.python.org  Mon Jun 28 23:12:37 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 28 Jun 2010 21:12:37 +0000
Subject: [issue9107] PyModule_Create not working properly
In-Reply-To: <1277753457.53.0.646916927225.issue9107@psf.upfronthosting.co.za>
Message-ID: <1277759557.8.0.502182313135.issue9107@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The issue tracker is not here to get help.
Please ask your question on the comp.lang.python newgroup, or the python-list mailing list.

There, I think you will have to show part of your code; there will certainly be several people willing to help you.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9107>
_______________________________________

From report at bugs.python.org  Mon Jun 28 23:16:41 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 28 Jun 2010 21:16:41 +0000
Subject: [issue3385] cPickle to pickle conversion in py3k missing methods
In-Reply-To: <1216234897.3.0.336444541402.issue3385@psf.upfronthosting.co.za>
Message-ID: <1277759801.42.0.784770504779.issue3385@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

> Do I understand correctly that the issue is that python
> Pickler class has dispatch attribute but C Pickler does
> not?

Yes.

> The add_dispatch_check-0.patch patch does not seem
> to add class attribute, it adds an instance attribute
> instead.

I know. That's why I said it was a preliminary patch. :-) Also, see msg71159 about the class vs instance attribute issue.

There's a lot of code out there that do crazy things with pickle's dispatch dictionary. For now, it is best if we leave the method names alone. If people wants to keep doing their funky stuff with pickle, then we can point them to pickle._Pickler and pickle._Unpickler, which will always point to the Python implementations.

That said, I do not believe it's a good idea to add the dispatch attribute to _pickle anymore. But, I acknowledge there is a need for overriding the pickling mechanism for specific types. We should find a clean way to support this.

I am closing this issue as "won't fix".

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3385>
_______________________________________

From report at bugs.python.org  Mon Jun 28 23:24:49 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 28 Jun 2010 21:24:49 +0000
Subject: [issue9106] remove numbers from 3-.. level entries in docs toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277760289.28.0.0589495548739.issue9106@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9106>
_______________________________________

From report at bugs.python.org  Mon Jun 28 23:25:03 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 28 Jun 2010 21:25:03 +0000
Subject: [issue8943] Bug in InteractiveConsole
In-Reply-To: <1276014263.34.0.524334073977.issue8943@psf.upfronthosting.co.za>
Message-ID: <1277760303.96.0.102734464343.issue8943@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

One easy fix for this would be to make InteractiveConsole use the string "__main__" instead of "__console__". But other than that, I don't think we can fix this within pickle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8943>
_______________________________________

From report at bugs.python.org  Mon Jun 28 23:34:59 2010
From: report at bugs.python.org (muzuiget)
Date: Mon, 28 Jun 2010 21:34:59 +0000
Subject: [issue9108] list object variable assign with multiplication sign
In-Reply-To: <1277760899.63.0.253038665786.issue9108@psf.upfronthosting.co.za>
Message-ID: <1277760899.63.0.253038665786.issue9108@psf.upfronthosting.co.za>


New submission from muzuiget <muzuiget at gmail.com>:

platform: ubuntu 10.04 amd64, python 2.6.5 r265:79063

run below code 

a = [{}, {}, {}]
b = [{}] + [{}] + [{}]
c = [{}] * 3
print a, len(a), type(a)
print b, len(b), type(b)
print c, len(c), type(c)
a[1]["test"] = 1234
b[1]["test"] = 1234
c[1]["test"] = 1234
print a
print b
print c

the output is 

[{}, {}, {}] 3 <type 'list'>
[{}, {}, {}] 3 <type 'list'>
[{}, {}, {}] 3 <type 'list'>
[{}, {'test': 1234}, {}]
[{}, {'test': 1234}, {}]
[{'test': 1234}, {'test': 1234}, {'test': 1234}]

each dict key in variable c seen to assign with the same value.

----------
components: None
messages: 108872
nosy: muzuiget
priority: normal
severity: normal
status: open
title: list object variable assign with multiplication sign
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9108>
_______________________________________

From report at bugs.python.org  Mon Jun 28 23:40:12 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 28 Jun 2010 21:40:12 +0000
Subject: [issue9108] list object variable assign with multiplication sign
In-Reply-To: <1277760899.63.0.253038665786.issue9108@psf.upfronthosting.co.za>
Message-ID: <1277761212.35.0.280515030329.issue9108@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

That's because with [{}] * 3 you get a list with 3 copies of the same object, so all the elements in c refer to the same dict:
>>> a = [{}, {}, {}]
>>> b = [{}] + [{}] + [{}]
>>> c = [{}] * 3
>>> map(id, a)
[12850496, 12850784, 12850928]
>>> map(id, b)
[12851648, 12851072, 12851792]
>>> map(id, c)
[12852080, 12852080, 12852080]

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9108>
_______________________________________

From report at bugs.python.org  Tue Jun 29 00:24:23 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Mon, 28 Jun 2010 22:24:23 +0000
Subject: [issue9109] absolute import cleanups for Python 3
In-Reply-To: <1277763863.2.0.681054558963.issue9109@psf.upfronthosting.co.za>
Message-ID: <1277763863.2.0.681054558963.issue9109@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-pythonbugs at arctrix.com>:

It looks like there is a bunch of legacy relative import cruft kicking around in Python 3.  The first thing I noticed is that __import__.__doc__ claims that level=-1 is the default (i.e. use the Python 2 behavior).  A little testing shows that the docs don't lie and __import__ in Python 3 defaults trying a relative import first.

What is the status of implicit relative imports in Python 3?  Can the level=-1 code be removed?

----------
components: Interpreter Core
messages: 108874
nosy: nas
priority: normal
severity: normal
status: open
title: absolute import cleanups for Python 3
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9109>
_______________________________________

From report at bugs.python.org  Tue Jun 29 00:25:10 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Mon, 28 Jun 2010 22:25:10 +0000
Subject: [issue9109] absolute import cleanups for Python 3
In-Reply-To: <1277763863.2.0.681054558963.issue9109@psf.upfronthosting.co.za>
Message-ID: <1277763910.63.0.896334069672.issue9109@psf.upfronthosting.co.za>


Changes by Neil Schemenauer <nas-python at arctrix.com>:


----------
assignee:  -> brett.cannon
nosy: +brett.cannon -nas

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9109>
_______________________________________

From report at bugs.python.org  Tue Jun 29 00:30:48 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 28 Jun 2010 22:30:48 +0000
Subject: [issue9109] absolute import cleanups for Python 3
In-Reply-To: <1277763863.2.0.681054558963.issue9109@psf.upfronthosting.co.za>
Message-ID: <1277764248.12.0.806389802405.issue9109@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/issue9109>
_______________________________________

From report at bugs.python.org  Tue Jun 29 00:48:32 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 28 Jun 2010 22:48:32 +0000
Subject: [issue9109] absolute import cleanups for Python 3
In-Reply-To: <1277763863.2.0.681054558963.issue9109@psf.upfronthosting.co.za>
Message-ID: <1277765312.25.0.360839332572.issue9109@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Having level=-1 doesn't even work in Python 3 like it did in Python 2 (it seems to just act as if level is 0), so yes the -1 code can be removed. Probably need all values less than 0 to get rounded up to 0 for backwards-compatibility with Python 2.x code which calls __import__ directly.

----------
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9109>
_______________________________________

From report at bugs.python.org  Tue Jun 29 00:48:39 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 28 Jun 2010 22:48:39 +0000
Subject: [issue9109] absolute import cleanups for Python 3
In-Reply-To: <1277763863.2.0.681054558963.issue9109@psf.upfronthosting.co.za>
Message-ID: <1277765319.92.0.477601830712.issue9109@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9109>
_______________________________________

From report at bugs.python.org  Tue Jun 29 00:48:49 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 28 Jun 2010 22:48:49 +0000
Subject: [issue9109] absolute import cleanups for Python 3
In-Reply-To: <1277763863.2.0.681054558963.issue9109@psf.upfronthosting.co.za>
Message-ID: <1277765329.36.0.91735656078.issue9109@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/issue9109>
_______________________________________

From report at bugs.python.org  Tue Jun 29 00:49:41 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Mon, 28 Jun 2010 22:49:41 +0000
Subject: [issue4151] Separate build dir broken
In-Reply-To: <1224522256.17.0.820973690454.issue4151@psf.upfronthosting.co.za>
Message-ID: <1277765381.36.0.714690297783.issue4151@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

I believe the latest problem reported has been fixed by SVN rev 80649.

----------
assignee:  -> nascheme
nosy:  -nas
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4151>
_______________________________________

From report at bugs.python.org  Tue Jun 29 00:58:18 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 28 Jun 2010 22:58:18 +0000
Subject: [issue9110] contextlib.ContextDecorator
In-Reply-To: <1277765898.65.0.314299135702.issue9110@psf.upfronthosting.co.za>
Message-ID: <1277765898.65.0.314299135702.issue9110@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Patch to add a ContextDecorator class to contextlib. This allows context managers that inherit from ContextDecorator (including using it as a mixin) to be used as decorators as well as context managers.

Context managers inheriting from ContextDecorator still have to implement __enter__ and __exit__ as normal. As the decorator behaviour is implemented using a with statement __exit__ retains its optional exception handling even when used as a decorator.

In addition contextlib.GeneratorContextManager, used to implement contextlib.contextmanager, inherits from ContextDecorator. Context managers created with contextlib.contextmanager can therefore be used as decorators too.

----------
assignee: michael.foord
components: Library (Lib)
files: contextdecorator.patch
keywords: patch
messages: 108877
nosy: michael.foord, ncoghlan
priority: normal
severity: normal
stage: patch review
status: open
title: contextlib.ContextDecorator
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file17795/contextdecorator.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9110>
_______________________________________

From report at bugs.python.org  Tue Jun 29 01:14:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jun 2010 23:14:23 +0000
Subject: [issue9094] Make python-m pickletools do something useful
In-Reply-To: <1277680335.26.0.237686854485.issue9094@psf.upfronthosting.co.za>
Message-ID: <1277766863.24.0.616390632415.issue9094@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, assuming you want to make it useful, I'd make that behaviour depend on a command-line option, such that other actions can be added later.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9094>
_______________________________________

From report at bugs.python.org  Tue Jun 29 01:22:12 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 28 Jun 2010 23:22:12 +0000
Subject: [issue9110] contextlib.ContextDecorator
In-Reply-To: <1277765898.65.0.314299135702.issue9110@psf.upfronthosting.co.za>
Message-ID: <1277767332.97.0.308595067163.issue9110@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


Added file: http://bugs.python.org/file17796/docs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9110>
_______________________________________

From report at bugs.python.org  Tue Jun 29 01:32:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jun 2010 23:32:41 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277767961.1.0.370916312034.issue5180@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> My patch attempts to emulate 2.x PyInstance_NewRaw with a call to
> tp_alloc.

This is certainly the wrong thing to do. You could at least try PyBaseObject_Type.tp_new (see object_new() in typeobject.c), but even this is not necessarily right (for example if the class is derived from an extension type defining its own tp_new).

So, IMO, the right thing to do would be to choose the first base type that isn't a Python-defined class and use its tp_new:

    staticbase = subtype;
    while (staticbase && (staticbase->tp_flags & Py_TPFLAGS_HEAPTYPE))
        staticbase = staticbase->tp_base;

(these two lines are from tp_new_wrapper() in typeobject.c)

That way you choose the right constructor function, yet don't call the Python-defined __new__ function. That's the only reasonable way of doing it I can imagine. It also follows the following behaviour:

>>> class C(int):
...   def __new__(cls, *a):
...     print "__new__", a
...     return int.__new__(cls, *a)
... 
>>> C(5)
__new__ (5,)
5
>>> s = pickle.dumps(C(5))
__new__ (5,)
>>> x = pickle.loads(s)
>>> x
5

As you can see, int.__new__ has been called on unpickling but not C.__new__ (no print).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Tue Jun 29 01:34:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jun 2010 23:34:52 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277768092.07.0.575050837895.issue5180@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(and to follow on my example, I'd point that the unpickled instance is still an instance of the right class:

>>> type(x)
<class '__main__.C'>

)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Tue Jun 29 01:43:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jun 2010 23:43:49 +0000
Subject: [issue9104] test_exceptions does not test pickling with pickle.py
In-Reply-To: <1277741892.3.0.0849773844587.issue9104@psf.upfronthosting.co.za>
Message-ID: <1277768629.06.0.865430366179.issue9104@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> An explicit dictionary to map the Python and C implementations may be a 
> better approach.

+1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9104>
_______________________________________

From report at bugs.python.org  Tue Jun 29 02:15:54 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 29 Jun 2010 00:15:54 +0000
Subject: [issue9045] 2.7rc1: 64-bit OSX installer is not built with 64-bit
	tkinter
In-Reply-To: <1277143341.0.0.74848452771.issue9045@psf.upfronthosting.co.za>
Message-ID: <1277770554.62.0.268401261728.issue9045@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Here's one resolution:

1. Edit setup.py to make INCLUDE/LIB paths for OpenSSL use the SDKROOT (for 10.5+ compat):
[...]
search_for_ssl_incs_in = ["/Developer/SDKs/MacOSX10.5.sdk/usr/include/" if ON_SNOW_LEOPARD else "/usr/include"]
search_for_ssl_libs_in = ["/Developer/SDKs/MacOSX10.5.sdk/usr/lib/" if ON_SNOW_LEOPARD else "/usr/lib"]

2. Force the 10.5 SDK to use Apple's Tcl/Tk 8.5 (10.5 users must install ActiveTcl, and then launch Python as "arch -i386 python2.7" if they want to use tkinter):

$ sudo ln -s /System/Library/Frameworks/Tcl.framework /Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks/

$ sudo ln -s /System/Library/Frameworks/Tk.framework /Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks/

3. Build with 10.5 SDK

$ export MACOSX_DEPLOYMENT_TARGET=10.5
$ ./configure --enable-framework --enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk/ --with-universal-archs=intel
$ make

And the result is a Python that works on 10.5+ and gives you 64-bit Tkinter for 10.6 users.

This is how I am intending to build ActivePython 2.7 this weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9045>
_______________________________________

From report at bugs.python.org  Tue Jun 29 02:31:11 2010
From: report at bugs.python.org (Miki Tebeka)
Date: Tue, 29 Jun 2010 00:31:11 +0000
Subject: [issue9111] cmd.do_help documentation should mention docstrings
In-Reply-To: <1277771470.94.0.943327236295.issue9111@psf.upfronthosting.co.za>
Message-ID: <1277771470.94.0.943327236295.issue9111@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

cmd.Cmd looks for help either by searching for help_XXX method or by the
docstring of do_XXX. The latter is not mentioned in the docs.

----------
components: Library (Lib)
messages: 108883
nosy: tebeka
priority: normal
severity: normal
status: open
title: cmd.do_help documentation should mention docstrings
versions: Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9111>
_______________________________________

From report at bugs.python.org  Tue Jun 29 03:01:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 01:01:19 +0000
Subject: [issue9094] Make python-m pickletools do something useful
In-Reply-To: <1277680335.26.0.237686854485.issue9094@psf.upfronthosting.co.za>
Message-ID: <1277773279.65.0.470253436079.issue9094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> Well, assuming you want to make it useful, I'd make that
> behaviour depend on a command-line option, ..

OK, Antoine, you asked for it. :-)

issue9094.diff

----------
Added file: http://bugs.python.org/file17797/issue9094.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9094>
_______________________________________

From report at bugs.python.org  Tue Jun 29 03:45:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 01:45:42 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277775942.55.0.746912271978.issue5180@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Jun 28, 2010 at 7:32 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>> My patch attempts to emulate 2.x PyInstance_NewRaw with a call to
>> tp_alloc.
>
> This is certainly the wrong thing to do. You could at least try
> PyBaseObject_Type.tp_new (see object_new() in typeobject.c), but
> even this is not necessarily right (for example if the
> class is derived from an extension type defining its own tp_new).

Well, this is not so obviously wrong as you make it sound.  If you look closer at object_new(), you will see that in sane situations it reduces to type->tp_alloc(type, 0) call.  Remember, this is called in very special circumstances: when unpickling old style class instances from a 2.x generated pickle.  No arguments are available for tp_new call, so excess_args check does not apply.  The other check is for an ABC, but the situation where an old-style class becomes an ABC in 2.x to 3.x transition is hardly sane.  If such sanity check is necessary, I would rather check the flag explicitly in _pickle.c rather than having to generate dummy args and kwds to satisfy tp_new signature.

>
> So, IMO, the right thing to do would be to choose the first base
> type that isn't a Python-defined class and use its tp_new:
>
> ? ?staticbase = subtype;
> ? ?while (staticbase && (staticbase->tp_flags & Py_TPFLAGS_HEAPTYPE))
> ? ? ? ?staticbase = staticbase->tp_base;
>
> (these two lines are from tp_new_wrapper() in typeobject.c)
>

This looks like overengineering to me.  I think 3.x should simply refuse to unpickle old style class instances into anything that is not subclassed in python directly from object.  It would be helpful at this point if you could provide a test case where tp_alloc logic does not work.  Regardless of what algorithm we ultimately choose, I would like to include such test in regrtest.

PS: Note that in my patch I've eliminated one control path that was calling instantiate(..) erroneously, but I have not reviewed the code carefully enough to eliminate the possibility that instantiate(..) would be called to instantiate new-style class instances.

PPS: What is you opinion on the pickle.py trick of monkey patching __class__ on an instance of an empty class?  Do you think this can be fooled?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Tue Jun 29 03:58:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Jun 2010 01:58:37 +0000
Subject: [issue9106] remove numbers from 3-.. level entries in docs toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277776717.71.0.522009945793.issue9106@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

-1

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9106>
_______________________________________

From report at bugs.python.org  Tue Jun 29 04:06:49 2010
From: report at bugs.python.org (Greg Ward)
Date: Tue, 29 Jun 2010 02:06: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: <1277777209.45.0.785927576448.issue2236@psf.upfronthosting.co.za>


Greg Ward <greg at gerg.ca> added the comment:

> Is it too late for 2.7?

I have no idea.

It does look as though someone has written unit tests for distutils, so the patch needs a test change too.  Henrique?

----------
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2236>
_______________________________________

From report at bugs.python.org  Tue Jun 29 04:09:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Jun 2010 02:09:15 +0000
Subject: [issue6589] smtpd.SMTPServer can cause asyncore.loop to enter
	infinite event loop
In-Reply-To: <1248753598.39.0.190804723361.issue6589@psf.upfronthosting.co.za>
Message-ID: <1277777355.51.0.344947625654.issue6589@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If you can provide a short example that reproduces the problem it will be much more likely to get fixed.

----------
nosy: +r.david.murray
stage:  -> unit test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6589>
_______________________________________

From report at bugs.python.org  Tue Jun 29 04:31:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 02:31:56 +0000
Subject: [issue1581183] pickle protocol 2 failure on int subclass
Message-ID: <1277778716.77.0.791816270768.issue1581183@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I reproduced the problem in py3k (both protocol 2 and 3).  See issue1581183-test-py3k.py attached.

----------
nosy: +alexandre.vassalotti, belopolsky
versions: +Python 3.2
Added file: http://bugs.python.org/file17798/issue1581183-test-py3k.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1581183>
_______________________________________

From report at bugs.python.org  Tue Jun 29 04:55:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 02:55:30 +0000
Subject: [issue960821] Add an updating load function in pickle
Message-ID: <1277780130.59.0.565002530188.issue960821@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This functionality already exists.  

"""
If a string is returned [from __reduce__() method], the string should be interpreted as the name of a global variable. It should be the object?s local name relative to its module; the pickle module searches the module namespace to determine the object?s module. This behaviour is typically useful for singletons.
""" -- http://docs.python.org/dev/py3k/library/pickle.html

----------
assignee:  -> belopolsky
nosy: +belopolsky
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue960821>
_______________________________________

From report at bugs.python.org  Tue Jun 29 06:09:49 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 29 Jun 2010 04:09:49 +0000
Subject: [issue9106] remove numbers from 3-.. level entries in docs toc
In-Reply-To: <1277776717.71.0.522009945793.issue9106@psf.upfronthosting.co.za>
Message-ID: <AANLkTilWkZE-tQ03T5ZSRe40AR5TQQ7wAezoGRZbYInZ@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> -1

Why? Do you like wrapped menu entries three lines long?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9106>
_______________________________________

From report at bugs.python.org  Tue Jun 29 07:05:10 2010
From: report at bugs.python.org (.:. brainsik)
Date: Tue, 29 Jun 2010 05:05:10 +0000
Subject: [issue5212] Incorrect note about md5 in hmac module documentation
In-Reply-To: <1234312792.25.0.547667950303.issue5212@psf.upfronthosting.co.za>
Message-ID: <1277787910.47.0.673525513727.issue5212@psf.upfronthosting.co.za>


.:. brainsik <spork-python at theory.org> added the comment:

Since the note is incorrect, it seems like it should be removed. What "results it is based on" are you referring to and what complaints are you concerned about?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5212>
_______________________________________

From report at bugs.python.org  Tue Jun 29 07:10:47 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 29 Jun 2010 05:10:47 +0000
Subject: [issue5212] Incorrect note about md5 in hmac module documentation
In-Reply-To: <1234312792.25.0.547667950303.issue5212@psf.upfronthosting.co.za>
Message-ID: <1277788247.11.0.670767897689.issue5212@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The supposed 'known weaknesses'. I have no particular opinion.
Anyway, we have your recommendation: remove the note.
I will let others defend it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5212>
_______________________________________

From report at bugs.python.org  Tue Jun 29 09:12:54 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 29 Jun 2010 07:12:54 +0000
Subject: [issue9077] argparse does not handle arguments correctly after --
In-Reply-To: <1277422498.3.0.635108415577.issue9077@psf.upfronthosting.co.za>
Message-ID: <1277795574.7.0.300622483963.issue9077@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No, this is not intentional.  Look at the docs for these attributes:

parser.largs
    the current list of leftover arguments, ie. arguments that have been consumed but are neither options nor option arguments. Feel free to modify parser.largs, e.g. by adding more arguments to it. (This list will become args, the second return value of parse_args().)
parser.rargs
    the current list of remaining arguments, ie. with opt_str and value (if applicable) removed, and only the arguments following them still there. Feel free to modify parser.rargs, e.g. by consuming more arguments.


In short, they are used *while* parsing options, and have no meaning afterwards; that the OptionParser stops moving items from rargs to largs after the "--" is an implementation detail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9077>
_______________________________________

From report at bugs.python.org  Tue Jun 29 09:26:07 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 29 Jun 2010 07:26:07 +0000
Subject: [issue4925] Improve error message of subprocess when cannot open
In-Reply-To: <1231777617.86.0.584511455662.issue4925@psf.upfronthosting.co.za>
Message-ID: <1277796367.05.0.604836611058.issue4925@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

in PC/_subprocess.c, it should be enough to use PyErr_SetFromWindowsErrWithFilename() instead of PyErr_SetFromWindowsErr()

----------
keywords: +easy
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4925>
_______________________________________

From report at bugs.python.org  Tue Jun 29 10:06:50 2010
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 29 Jun 2010 08:06:50 +0000
Subject: [issue9112] argparse missing documentation for error() method
In-Reply-To: <1277798810.6.0.529590004484.issue9112@psf.upfronthosting.co.za>
Message-ID: <1277798810.6.0.529590004484.issue9112@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

The argparse module's ArgumentParser class has an error() method that appears to have the same behavior as the optparse error() method, but this method is not mentioned in the documentation.

----------
assignee: docs at python
components: Documentation
messages: 108896
nosy: docs at python, mark
priority: normal
severity: normal
status: open
title: argparse missing documentation for error() method
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9112>
_______________________________________

From report at bugs.python.org  Tue Jun 29 10:36:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Jun 2010 08:36:49 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1277775942.55.0.746912271978.issue5180@psf.upfronthosting.co.za>
Message-ID: <1277800603.3226.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Well, this is not so obviously wrong as you make it sound.  If you
> look closer at object_new(), you will see that in sane situations it
> reduces to type->tp_alloc(type, 0) call.

Today, yes. But tomorrow it may entail additional operations.

> If such sanity check is necessary, I would rather check the flag
> explicitly in _pickle.c rather than having to generate dummy args and
> kwds to satisfy tp_new signature.

I find it better to "generate dummy args and kwds to satisfy tp_new
signature". I see no point in a partial inlining of an internal function
when we could call it instead.

> > So, IMO, the right thing to do would be to choose the first base
> > type that isn't a Python-defined class and use its tp_new:
> >
> >    staticbase = subtype;
> >    while (staticbase && (staticbase->tp_flags & Py_TPFLAGS_HEAPTYPE))
> >        staticbase = staticbase->tp_base;
> >
> > (these two lines are from tp_new_wrapper() in typeobject.c)
> >
> 
> This looks like overengineering to me.  I think 3.x should simply
> refuse to unpickle old style class instances into anything that is not
> subclassed in python directly from object.

Right, but it would lead to almost the same code... Since you have to
find the first non-Python base type and check that it is "object".

> It would be helpful at this point if you could provide a test case
> where tp_alloc logic does not work.

I'll try to find one.

> PPS: What is you opinion on the pickle.py trick of monkey patching
> __class__ on an instance of an empty class?  Do you think this can be
> fooled?

I don't think so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Tue Jun 29 10:42:06 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 29 Jun 2010 08:42:06 +0000
Subject: [issue9106] remove numbers from 3-.. level entries in docs toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277800926.53.0.712822710533.issue9106@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This should be taken to the Sphinx tracker, as the feature needs to be implemented first.

----------
nosy: +georg.brandl
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9106>
_______________________________________

From report at bugs.python.org  Tue Jun 29 10:44:31 2010
From: report at bugs.python.org (Zsolt Cserna)
Date: Tue, 29 Jun 2010 08:44:31 +0000
Subject: [issue8799] Hang in lib/test/test_threading.py
In-Reply-To: <1274694258.02.0.421667436928.issue8799@psf.upfronthosting.co.za>
Message-ID: <1277801071.24.0.474989582895.issue8799@psf.upfronthosting.co.za>


Changes by Zsolt Cserna <zsolt.cserna at morganstanley.com>:


----------
nosy: +csernazs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8799>
_______________________________________

From report at bugs.python.org  Tue Jun 29 12:32:04 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 29 Jun 2010 10:32:04 +0000
Subject: [issue9106] remove numbers from 3-.. level entries in docs toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277807524.83.0.456782256145.issue9106@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

http://bitbucket.org/birkenfeld/sphinx/issue/460/strip-section-numbers-from-toc-menu

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9106>
_______________________________________

From report at bugs.python.org  Tue Jun 29 13:04:51 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 29 Jun 2010 11:04:51 +0000
Subject: [issue9113] Tools/msi still uses string exceptions
In-Reply-To: <1277809491.49.0.571731039318.issue9113@psf.upfronthosting.co.za>
Message-ID: <1277809491.49.0.571731039318.issue9113@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

string exceptions still used in a couple of places:

Tools/msi/msi.py:354
Tools/msi/msi.py:368
Tools/msi/msilib.py:238

----------
components: Demos and Tools
messages: 108900
nosy: doko
priority: normal
severity: normal
status: open
title: Tools/msi still uses string exceptions
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9113>
_______________________________________

From report at bugs.python.org  Tue Jun 29 13:09:05 2010
From: report at bugs.python.org (Matt Joiner)
Date: Tue, 29 Jun 2010 11:09:05 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1277809745.94.0.257396567419.issue3823@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

I take it this is out for 2.7, will it be in 3.2?

----------
nosy: +anacrolix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Tue Jun 29 14:25:00 2010
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 29 Jun 2010 12:25:00 +0000
Subject: [issue9114] br"" string literals don't appear to be documented
In-Reply-To: <1277814300.14.0.365243275067.issue9114@psf.upfronthosting.co.za>
Message-ID: <1277814300.14.0.365243275067.issue9114@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

It appears that br"" (raw bytes) isn't documented, at least not along with string and bytes literals:
http://docs.python.org/py3k/reference/lexical_analysis.html#literals

Yet they are supported:
http://mail.python.org/pipermail/python-ideas/2010-June/007529.html

----------
assignee: docs at python
components: Documentation
messages: 108902
nosy: docs at python, mark
priority: normal
severity: normal
status: open
title: br"" string literals don't appear to be documented
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9114>
_______________________________________

From report at bugs.python.org  Tue Jun 29 14:27:49 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Jun 2010 12:27:49 +0000
Subject: [issue9114] br"" string literals don't appear to be documented
In-Reply-To: <1277814300.14.0.365243275067.issue9114@psf.upfronthosting.co.za>
Message-ID: <1277814469.33.0.406985778066.issue9114@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/issue9114>
_______________________________________

From report at bugs.python.org  Tue Jun 29 14:28:10 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Jun 2010 12:28:10 +0000
Subject: [issue9113] Tools/msi still uses string exceptions
In-Reply-To: <1277809491.49.0.571731039318.issue9113@psf.upfronthosting.co.za>
Message-ID: <1277814490.48.0.748443165607.issue9113@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/issue9113>
_______________________________________

From report at bugs.python.org  Tue Jun 29 14:42:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Jun 2010 12:42:28 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1277815348.39.0.573757088863.issue2504@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> accepted
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Tue Jun 29 14:55:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Jun 2010 12:55:13 +0000
Subject: [issue1288056] pygettext: provide comments to help translators
Message-ID: <1277816113.31.0.609865535903.issue1288056@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It appears that I had mistaken comments in the source and comments in the pot/po files:

     /* TRANSLATORS: The placeholder indicates etc. */
     printf (_("Something.\n"));

These will be extracted by ?xgettext?, leading to a .pot file that contains this:

     #. TRANSLATORS: The placeholder indicates etc.
     #: src/hello.c:178
     #, c-format
     msgid "Report bugs to <%s>.\n"
     msgstr ""


(From <http://www.gnu.org/software/gettext/manual/gettext.html>)

----------
stage:  -> needs patch
title: pygettext - provide comments to help translators -> pygettext: provide comments to help translators
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1288056>
_______________________________________

From report at bugs.python.org  Tue Jun 29 14:55:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Jun 2010 12:55:36 +0000
Subject: [issue1288056] pygettext: extract translators comments
Message-ID: <1277816136.24.0.803563437783.issue1288056@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: pygettext: provide comments to help translators -> pygettext: extract translators comments

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1288056>
_______________________________________

From report at bugs.python.org  Tue Jun 29 15:29:46 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 29 Jun 2010 13:29:46 +0000
Subject: [issue3428] httplib.HTTPMessage undocumented
In-Reply-To: <1277758318.45.0.874145546983.issue3428@psf.upfronthosting.co.za>
Message-ID: <20100629132935.GA4468@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Mon, Jun 28, 2010 at 08:51:58PM +0000, ThomasH wrote:
> But the urllib.rst documentation is still flawed:

Fixed now in the r82363. Did a find and grep on all instances of
HTTPMessage and verified that it is only at proper places now.

Thanks for pointing out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3428>
_______________________________________

From report at bugs.python.org  Tue Jun 29 15:37:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Jun 2010 13:37:03 +0000
Subject: [issue9112] argparse missing documentation for error() method
In-Reply-To: <1277798810.6.0.529590004484.issue9112@psf.upfronthosting.co.za>
Message-ID: <1277818623.07.0.259561520064.issue9112@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/issue9112>
_______________________________________

From report at bugs.python.org  Tue Jun 29 15:46:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Jun 2010 13:46:54 +0000
Subject: [issue9106] remove numbers from 3-.. level entries in docs toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277819214.66.0.562208520926.issue9106@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If the change is confined to the left menu bar only, I'd be happy to have the numbers go away entirely.  But only putting in partial numbers strikes me as an invitation to confusion.  If other people prefer your scheme that's fine with me.  Almost the only time I look at the left menu bar (except on the front page of docs) is when I want to find the 'show source' link.

----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9106>
_______________________________________

From report at bugs.python.org  Tue Jun 29 16:06:41 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 29 Jun 2010 14:06:41 +0000
Subject: [issue9110] contextlib.ContextDecorator
In-Reply-To: <1277765898.65.0.314299135702.issue9110@psf.upfronthosting.co.za>
Message-ID: <1277820401.6.0.624407039876.issue9110@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Looks pretty good to me, but you may want to doublecheck some of your test criteria.

Firstly, the two "*_with_exception" checks don't look quite right to me. I would have expected to see something like the following for both of them: 

  self.assertIsNotNone(context.exc)
  self.assertIs(context.exc[0], NameError).

Secondly, I can't even begin to guess what the method decoration test is currently trying to show. Why 3 instantiations? Why check the instance assignments rather than the context manager behaviour? Either I'm completely missing something, or this currently isn't testing what you meant to test :)

Finally, you may as well include a second typo test to cover the __enter__ misspelling case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9110>
_______________________________________

From report at bugs.python.org  Tue Jun 29 16:13:38 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 29 Jun 2010 14:13:38 +0000
Subject: [issue9110] contextlib.ContextDecorator
In-Reply-To: <1277765898.65.0.314299135702.issue9110@psf.upfronthosting.co.za>
Message-ID: <1277820818.27.0.694811645077.issue9110@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Hey Nick,

The tests are pretty much just copied from the previous version, so they aren't all appropriate. In fact I think that the first two tests (and even the typo tests) can just go as they really just test Python semantics and not the ContextDecorator itself.

The method tests are testing that the arguments (including keyword arguments) are properly passed through to the decorated function. I started to write a comment to that effect as I realised it wasn't obvious, but forgot to finish the comment... Separate instantiations just mean we don't need to worry about previous values.

(I did them as methods as I was *starting* to write a test for general descriptor decorating - but the general case for that is very hard to solve so people just have to use their decorators in the right order instead. Nonetheless it is nice to have a test that decorates a method as well as the other function decorating tests.)

Your improvement to the exceptions tests are good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9110>
_______________________________________

From report at bugs.python.org  Tue Jun 29 16:14:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Jun 2010 14:14:13 +0000
Subject: [issue9106] remove numbers from 3-.. level entries in docs toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277820853.54.0.943462816907.issue9106@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 for removing numbers.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9106>
_______________________________________

From report at bugs.python.org  Tue Jun 29 16:18:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Jun 2010 14:18:03 +0000
Subject: [issue9103] API keyword
In-Reply-To: <AANLkTil4-Bf0gK-zXTGP7vWbWpFQ9uvON6wK_2ZGBies@mail.gmail.com>
Message-ID: <1277821083.87.0.867057719222.issue9103@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9103>
_______________________________________

From report at bugs.python.org  Tue Jun 29 16:24:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Jun 2010 14:24:21 +0000
Subject: [issue9095] patchcheck should handle extraneous whitespace in .rst
	files
In-Reply-To: <1277683188.13.0.698937807833.issue9095@psf.upfronthosting.co.za>
Message-ID: <1277821461.79.0.715283553663.issue9095@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Feel free to assign patchcheck bugs to me. I?ll write a patch and then assign to you for review.

----------
nosy: +merwok
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9095>
_______________________________________

From report at bugs.python.org  Tue Jun 29 16:27:59 2010
From: report at bugs.python.org (Zsolt Cserna)
Date: Tue, 29 Jun 2010 14:27:59 +0000
Subject: [issue9115] test_site: support for systems without unsetenv
In-Reply-To: <1277821678.96.0.414728435775.issue9115@psf.upfronthosting.co.za>
Message-ID: <1277821678.96.0.414728435775.issue9115@psf.upfronthosting.co.za>


New submission from Zsolt Cserna <zsolt.cserna at morganstanley.com>:

On systems where there's no unsetenv function (for example solaris 8), test_site fails because the PYTHONUSERBASE environment variable remains set to "xoxo" (set in the previous tests).

This results a failed test_s_option test.

----------
components: Tests
files: test_site.py.diff
keywords: patch
messages: 108910
nosy: csernazs
priority: normal
severity: normal
status: open
title: test_site: support for systems without unsetenv
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17799/test_site.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9115>
_______________________________________

From report at bugs.python.org  Tue Jun 29 16:29:10 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 29 Jun 2010 14:29:10 +0000
Subject: [issue9110] contextlib.ContextDecorator
In-Reply-To: <1277820818.27.0.694811645077.issue9110@psf.upfronthosting.co.za>
Message-ID: <AANLkTilY4O2ckPsPRVt5yN2AI66VbZs_eHrx1URlNLNU@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

On Wed, Jun 30, 2010 at 12:13 AM, Michael Foord <report at bugs.python.org> wrote:
>
> Michael Foord <michael at voidspace.org.uk> added the comment:
>
> Hey Nick,
>
> The tests are pretty much just copied from the previous version, so they aren't all appropriate. In fact I think that the first two tests (and even the typo tests) can just go as they really just test Python semantics and not the ContextDecorator itself.

Ah, yep, I can see how they would have been more important with the
old 2.4 compatible implementation. However, it's still useful to keep
them as a sanity check that the test context manager isn't doing
anything silly (i.e. if they pass and the decorator tests fail,
ContextDecorator is obviously at fault, whereas without these first
two tests the bug could be in the test context manager).

> The method tests are testing that the arguments (including keyword arguments) are properly passed through to the decorated function. I started to write a comment to that effect as I realised it wasn't obvious, but forgot to finish the comment... Separate instantiations just mean we don't need to worry about previous values.
>
> (I did them as methods as I was *starting* to write a test for general descriptor decorating - but the general case for that is very hard to solve so people just have to use their decorators in the right order instead. Nonetheless it is nice to have a test that decorates a method as well as the other function decorating tests.)

That makes sense, but a comment to that effect would be *very* helpful :)

Comments on the docs patch (I neglected to look at that initially):

For the @contextmanager updates, I would move the description of the
effect into an extra paragraph in the main body of the description,
then just use the versionadded tag to when the change was made.

For the ContextDecorator description itself, you may want to write the
last part of the first example (i.e. just the with statement) in a
doctest layout so you can show the expected output.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9110>
_______________________________________

From report at bugs.python.org  Tue Jun 29 17:02:44 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Jun 2010 15:02:44 +0000
Subject: [issue8939] Use C type names (PyUnicode etc;) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1277823764.22.0.710563072572.issue8939@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/issue8939>
_______________________________________

From report at bugs.python.org  Tue Jun 29 17:42:36 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 15:42:36 +0000
Subject: [issue1581183] pickle protocol 2 failure on int subclass
Message-ID: <1277826156.81.0.273220245227.issue1581183@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

At least part of the problem has nothing to do with subclassing from int and instead is related to pickling objects with circular references.

I am attaching a patch that demonstrates the problem.  In issue1581183-test.diff, I modified memoize so that it does nothing rather than fails an assert if object is already in the memo.  This makes python and C implementations behave the same, but still fail to produce correct results. Pickling with protocol 2 break circular reference and instead creates two independent objects.

----------
assignee:  -> belopolsky
keywords: +patch
Added file: http://bugs.python.org/file17800/issue1581183-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1581183>
_______________________________________

From report at bugs.python.org  Tue Jun 29 17:58:12 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Jun 2010 15:58:12 +0000
Subject: [issue9114] br"" string literals don't appear to be documented
In-Reply-To: <1277814300.14.0.365243275067.issue9114@psf.upfronthosting.co.za>
Message-ID: <1277827092.78.0.325555815367.issue9114@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r82373.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9114>
_______________________________________

From report at bugs.python.org  Tue Jun 29 17:58:27 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 29 Jun 2010 15:58: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: <1277827107.42.0.0793977492373.issue9116@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

Debug and Release builds of py3k both throw up a Visual Studio debugger prompt when running this test on Windows. I don't have much time at the moment to investigate, but I find it odd that this isn't occurring on the two Windows py3k buildbots.



Output of the release build after selecting not to debug:

C:\python-dev\py3k>PCbuild\amd64\python.exe -m test.regrtest test_capi
test_capi
test test_capi failed -- Traceback (most recent call last):
  File "C:\python-dev\py3k\lib\test\test_capi.py", line 50, in test_no_FatalError_infinite_loop
    b'Fatal Python error:'
AssertionError: b"Fatal Python error: PyThreadState_Get: no current thread\r\n\r
\nThis application has requested the Runtime to terminate it in an unusual way.\
nPlease contact the application's support team for more information." != b'Fatal
 Python error: PyThreadState_Get: no current thread'

1 test failed:
    test_capi

----------
components: Interpreter Core, Tests
messages: 108914
nosy: brian.curtin
priority: normal
severity: normal
status: open
title: test_capi.test_no_FatalError_infinite_loop crash on Windows
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9116>
_______________________________________

From report at bugs.python.org  Tue Jun 29 17:59:53 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 29 Jun 2010 15:59:53 +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: <1277827193.1.0.918741264896.issue9116@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I should also note that this doesn't appear to happen on release31-maint or trunk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9116>
_______________________________________

From report at bugs.python.org  Tue Jun 29 18:01:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 16:01:48 +0000
Subject: [issue1581183] pickle protocol 2 failure on int subclass
Message-ID: <1277827308.75.0.329546008557.issue1581183@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17800/issue1581183-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1581183>
_______________________________________

From report at bugs.python.org  Tue Jun 29 18:02:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 16:02:05 +0000
Subject: [issue1581183] pickle protocol 2 failure on int subclass
Message-ID: <1277827325.74.0.110270528161.issue1581183@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17801/issue1581183-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1581183>
_______________________________________

From report at bugs.python.org  Tue Jun 29 18:07:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Jun 2010 16:07:03 +0000
Subject: [issue9114] br"" string literals don't appear to be documented
In-Reply-To: <1277814300.14.0.365243275067.issue9114@psf.upfronthosting.co.za>
Message-ID: <1277827623.7.0.346740064235.issue9114@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9114>
_______________________________________

From report at bugs.python.org  Tue Jun 29 18:18:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Jun 2010 16:18:09 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1277828289.76.0.728337876836.issue3823@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I take it this is out for 2.7, will it be in 3.2?

The patch for issue8550 has been committed. The SSLContext API should solve this issue:
http://docs.python.org/dev/py3k/library/ssl.html#ssl.SSLContext.wrap_socket

If it doesn't, please explain why.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Tue Jun 29 18:52:40 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 16:52:40 +0000
Subject: [issue9117] class syntax not fully documented in reference manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Looking at:

http://docs.python.org/dev/py3k/reference/compound_stmts.html#class-definitions

I see:

classdef    ::=  [decorators] "class" classname [inheritance] ":" suite
inheritance ::=  "(" [expression_list] ")"
classname   ::=  identifier

this seems to be missing the keyword arguments that are now possible in a classdef (e.g. for specifying a metaclass).  I believe that *args and **kwargs are now also syntactically accepted in a class definition.

----------
assignee: docs at python
components: Documentation
messages: 108917
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: class syntax not fully documented in reference manual
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9117>
_______________________________________

From report at bugs.python.org  Tue Jun 29 19:02:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 17:02:05 +0000
Subject: [issue9117] class syntax not fully documented in reference manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277830925.75.0.410166084661.issue9117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Am working on a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9117>
_______________________________________

From report at bugs.python.org  Tue Jun 29 19:10:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 17:10:56 +0000
Subject: [issue1581183] pickle protocol 2 failure on int subclass
Message-ID: <1277831456.3.0.517448676443.issue1581183@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Upon further investigation, I conclude that the problem is in the user code.  I am attaching int_subclass_pickle_problem_fixed.py which fixes the user code as follows:

     def __getnewargs__(self):
-        return (int(self), self.an_enum)
+        return (int(self), None)

Note that with this change, the object is pickled correctly because __setstate__ takes care of resetting self.an_enum.

The problem is that self-referential state should not be passed via __getnewargs__ mechanism.  This is because when pickler starts writing newargs, it is already committed to creating a new object (otherwise it would not need to serialize newargs in the first place.)  If the newargs contain the object that is being pickled, it will be serialized twice unless this situation is caught in memoize.

What can be improved, is the diagnostic and possibly documentation.  If after saving newargs, memo contains the object that is being pickled, an exception should be raised explaining that __getnewargs__() should not contain self-references.

----------
keywords:  -patch
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1581183>
_______________________________________

From report at bugs.python.org  Tue Jun 29 19:19:43 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 17:19:43 +0000
Subject: [issue9117] class syntax not fully documented in reference manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277831983.72.0.72413557365.issue9117@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> I believe that *args and **kwargs are now also syntactically
> accepted in a class definition.

Indeed:

>>> class a: pass
>>> class b: pass
>>> bases = (a, b)
>>> class c(*bases): pass
>>> kwds = {'metaclass':type}
>>> class c(*bases, **kwds): pass

works!

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9117>
_______________________________________

From report at bugs.python.org  Tue Jun 29 19:27:42 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Jun 2010 17:27:42 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1277832462.46.0.476091755302.issue8998@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Apart from the question of API, please also include a section on the legal implications this move would have on Python in the PEP.

We currently only include OpenSSL in the Windows installers and (for some reason) don't pay much attention to the implications this has (the fact is not mentioned on the download page and the Windows installer doesn't show the required OpenSSL old-style BSD attribution).

If we are to require OpenSSL or some other crypto lib, possibly even our own (e.g. pycrypto) for all platforms, then we could no longer just ignore the fact that crypto code is subject to strong legislation in many countries of the world.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 29 19:29:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 17:29:37 +0000
Subject: [issue6827] deepcopy erroneously doesn't call __setstate__ if
	__getstate__ returns empty dict
In-Reply-To: <1251926992.64.0.823425954467.issue6827@psf.upfronthosting.co.za>
Message-ID: <1277832577.42.0.170301028713.issue6827@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I see the following under <http://docs.python.org/dev/py3k/library/pickle.html#pickling-class-instances>:

Note If __getstate__() returns a false value, the __setstate__() method will not be called.  That was added in r62216 and highlighted in r67045.

Is there anything else that needs to be done here?

----------
assignee:  -> belopolsky
nosy: +belopolsky
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6827>
_______________________________________

From report at bugs.python.org  Tue Jun 29 19:49:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Jun 2010 17:49:20 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1277832462.46.0.476091755302.issue8998@psf.upfronthosting.co.za>
Message-ID: <1277833756.3349.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If we are to require OpenSSL or some other crypto lib,

We already depend on OpenSSL for both hashlib and ssl, this proposal
wouldn't change anything in this regard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 29 20:03:53 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 18:03:53 +0000
Subject: [issue9117] class syntax not fully documented in reference manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277834633.34.0.837796311989.issue9117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It looks like fixing the production list is the easy part (see attached patch):  as far as I can tell, the *syntax* for class definitions is pretty much identical to that for function calls.  (The semantics are different, of course.)  It would be good if someone could check this patch for sanity, though.

The description in that section still needs updating.

----------
keywords: +patch
Added file: http://bugs.python.org/file17802/issue9117.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9117>
_______________________________________

From report at bugs.python.org  Tue Jun 29 20:22:45 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 29 Jun 2010 18:22:45 +0000
Subject: [issue9095] patchcheck should handle extraneous whitespace in .rst
	files
In-Reply-To: <1277683188.13.0.698937807833.issue9095@psf.upfronthosting.co.za>
Message-ID: <1277835765.26.0.209267877613.issue9095@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Knock yourself out!

----------
assignee:  -> merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9095>
_______________________________________

From report at bugs.python.org  Tue Jun 29 20:25:14 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Jun 2010 18:25:14 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1277833756.3349.0.camel@localhost.localdomain>
Message-ID: <4C2A3A87.6090107@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> If we are to require OpenSSL or some other crypto lib,
> 
> We already depend on OpenSSL for both hashlib and ssl, this proposal
> wouldn't change anything in this regard.

hashlib can still works without OpenSSL and hash algorithms don't
fall under crypto laws. ssl doesn't work without OpenSSL, but also
doesn't require adding any crypto code to the stdlib.

The main point that needs to be addressed is shipping Python
with crypto code. If OpenSSL is optionally used, we're fine,
but if we start shipping crypto code, things are more contrived.

See http://rechten.uvt.nl/koops/cryptolaw/ for a survey.

We're hosting the Python software on servers in The Netherlands,
so have to follow the Wassenaar Arrangement if we include
crypto code. Fortunately, that agreement includes a clause which
pretty much exempts open source crypto code from export regulations.

However, users of Python downloading installers with crypto software
would import and use it in their resp. countries and that may get
them into trouble, so they need to be warned if we decide to
ship crypto code with Python.

They way I understand Geremy's suggestion is to just include a
wrapper for OpenSSL, so that's fine. The PEP should include a
mention of the above to argue against putting e.g. pycrypto
into the stdlib (not because it's poor software, much to the
contrary, only because it causes lots of problems for our
users and the developers).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 29 20:30:37 2010
From: report at bugs.python.org (Gustavo Niemeyer)
Date: Tue, 29 Jun 2010 18:30:37 +0000
Subject: [issue9071] TarFile doesn't support member files with a leading "./"
In-Reply-To: <1277403062.33.0.252734901258.issue9071@psf.upfronthosting.co.za>
Message-ID: <1277836237.47.0.893345396389.issue9071@psf.upfronthosting.co.za>


Gustavo Niemeyer <gustavo at niemeyer.net> added the comment:

Indeed, nice use of the time machine! :-)

Thanks Lars!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9071>
_______________________________________

From report at bugs.python.org  Tue Jun 29 20:32:49 2010
From: report at bugs.python.org (Jack Diederich)
Date: Tue, 29 Jun 2010 18:32:49 +0000
Subject: [issue9118] help() on a property descriptor launches interactive help
In-Reply-To: <1277836369.81.0.859952586368.issue9118@psf.upfronthosting.co.za>
Message-ID: <1277836369.81.0.859952586368.issue9118@psf.upfronthosting.co.za>


New submission from Jack Diederich <jackdied at gmail.com>:

ython 2.7b2+ (trunk:81337, May 19 2010, 12:16:22) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class X(object):
...   @property
...   def foo(self): pass
... 
>>> help(X.foo.fset)

Welcome to Python 2.7!  This is the online help utility.

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://docs.python.org/tutorial/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, or topics, type "modules",
"keywords", or "topics".  Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as "spam", type "modules spam".

help> ^D
You are now leaving help and returning to the Python interpreter.
If you want to ask for help on a particular object directly from the
interpreter, you can type "help(object)".  Executing "help('string')"
has the same effect as typing a particular string at the help> prompt.
>>>

----------
components: Library (Lib)
messages: 108928
nosy: jackdied
priority: low
severity: normal
stage: needs patch
status: open
title: help() on a property descriptor launches interactive help
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9118>
_______________________________________

From report at bugs.python.org  Tue Jun 29 20:37:38 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Jun 2010 18:37:38 +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: <1277836658.93.0.259031299275.issue9119@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

This needs to be done to protect our users (importing crypto code or using it may be illegal in their home country, see http://rechten.uvt.nl/koops/cryptolaw/ for a survey) and to satisfy an attribution requirement in the OpenSSL license and code base:

"""
This product includes cryptographic software written by Eric Young (eay at cryptsoft.com). This product includes software written by Tim Hudson (tjh at cryptsoft.com). This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)
"""

----------
assignee: docs at python
components: Build, Documentation
messages: 108929
nosy: docs at python, lemburg
priority: normal
severity: normal
status: open
title: Python download page needs to mention crypto code in Windows installer
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/issue9119>
_______________________________________

From report at bugs.python.org  Tue Jun 29 20:38:38 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Jun 2010 18:38:38 +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: <1277836718.55.0.227029795055.issue9119@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

See the OpenSSL license for details on the notice requirement:

http://www.openssl.org/source/license.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9119>
_______________________________________

From report at bugs.python.org  Tue Jun 29 20:39:56 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Jun 2010 18:39:56 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1277832462.46.0.476091755302.issue8998@psf.upfronthosting.co.za>
Message-ID: <4C2A3DF9.7030600@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Marc-Andre Lemburg wrote:
> 
> We currently only include OpenSSL in the Windows installers and (for some reason) don't pay much attention to the implications this has (the fact is not mentioned on the download page and the Windows installer doesn't show the required OpenSSL old-style BSD attribution).

I've opened issue9119 to address this part.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 29 20:41:36 2010
From: report at bugs.python.org (geremy condra)
Date: Tue, 29 Jun 2010 18:41:36 +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: <1277836896.73.0.139405935889.issue9119@psf.upfronthosting.co.za>


Changes by geremy condra <debatem1 at gmail.com>:


----------
nosy: +debatem1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9119>
_______________________________________

From report at bugs.python.org  Tue Jun 29 20:47:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 18:47:11 +0000
Subject: [issue9117] class syntax not fully documented in reference manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277837231.79.0.196938146668.issue9117@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The production looks right to me, but I think it should be broken in two or more lines.  Since it is rendered pre-formatted, long line results in a horizontal scroll bar unless the browser window is extremely wide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9117>
_______________________________________

From report at bugs.python.org  Tue Jun 29 21:02:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 19:02:09 +0000
Subject: [issue7673] audioop: check that length is a multiple of the size
In-Reply-To: <1263171957.43.0.71285781195.issue7673@psf.upfronthosting.co.za>
Message-ID: <1277838129.93.0.868072532918.issue7673@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The patch looks fine to me.

- Please could you add some tests, to exercise the 'not a whole number of frames' errors?

- The patch obviously predates the grand reindenting, so its indentation needs fixing up

PEP 7 nits:

 - Please don't put spaces just inside the parens in an 'if' statement:  i.e., use "if (size != 1 ...)", not "if ( size != 1 ...)"  (I notice that the "if ( x == NULL )" style is already prevalent, though not universal, in the module, though.)

 - the 'else' clause of an if should be at the start of the line (i.e.,
on a new line below the closing brace of the 'if', if present)

Is there any particular reason that Python 3.1 is not included in the versions?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7673>
_______________________________________

From report at bugs.python.org  Tue Jun 29 21:04:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Jun 2010 19:04:08 +0000
Subject: [issue4963] mimetypes.guess_extension result changes after
	mimetypes.init()
In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>
Message-ID: <1277838248.92.0.300476634689.issue4963@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It must be that the different key order only happens on the one platform because of the quirky nature of dictionary construction.  That is, there is *something* on that platform that is changing where things get hashed when the dictionary is recreated.

The problem with fixing this is that any fix is going to change the behavior, unless we go to the lengths of recording the order of the initializations in add_type and replay it when init is called a second time.  That solution is pretty much a non-starter :)

The mimetypes docs say that init can be called more than once,  They say that a MimeTypes object starts out "with the same database as provided by the rest of the module".  The docs explain how the initial database state is created.

What the docs don't do is say what *happens* when you call init more than once.  There are two possibilities: either we (1) restart from the initial state, or we (2) start from the current (possibly modified) state of the database and then add whatever is specified in the init call.  (Actually, there's a third possibility: we could also add back in anything from the default init that was deleted; but this halfway version is unlikely to be anyone's intent or expectation.)

The actual implementation of the mimetypes module does (2) if and only if you pass init a list of files.  If you don't then it does something that isn't even the third way above: it reloads *just* the data from the system files it managed to find, without reloading the data from the internal tables.

Clearly this behavior is....odd.  When no files are passed, init should do one of two things: either nothing, or reset the global db state to its initial value.

It's not so clear what the behavior should be when you pass init one or more files.  It is possible, even highly probable, that there is code out there that depends on the fact that doing so is additive.

Given this analysis, I think that the best fix would be implement (and document) the following behavior for init:

  If called with no arguments, it rebuilds the module database from scratch

  If called with a list of files, it adds the contents of those files to the module database

The second is a backward compatibility hack.  Ideally it would be deprecated in favor of some sort of load_mime_files method.

It is possible that the first will also break code, but I think it is less likely, and probably an acceptable risk in a new major release.  But I'd be prepared to change it to 'init does nothing' if breakage showed up during RC testing.

The problem with this "fix" is that it does not, in fact, address the root cause of the OP's bug report.  The specific behavior he observes when calling init() would be fixed, but the underlying problem remains.  If he were to instead instantiate a new MimeTypes db, then when it "copies" the module database, it will build its own database by running the old database in key order, and once again the results returned by guess_extension might mutate.  This means that the new db is *not* a copy of the old db when it starts.

That problem could be fixed by having MimeTypes.__init__ do a copy of the types_map and types_map_inv data structures instead of rebuilding them from scratch.  This would mean shifting the initialization of these structures out of MimeTypes and in to init (in the 'reinitialize' code path) or perhaps into _default_mime_types, but I don't see that as a big problem, once init is doing a full reinitialization by default.  (There is also the question of whether it should be a 'deep copy', but I don't think that is needed since a user would need to be doing something pretty hackish to run afoul of a shallow-copy-induced problem.)

Can anyone see flaws in this analysis and proposed solution?  I've marked the fix as easy since a python hacker should be able to knock out a solution in a day, but it isn't trivial.  And I have no clue how to write a unit test for the MimeTypes.__init__ order-shifting bug.

I'm also resetting the priority to normal since I consider the ambiguity of what calling init twice actually does to be a bigger issue than it sometimes changing the results of a function with 'guess' in its name :)

I've attached a patch with a unit test for the 'init doesn't re-init' behavior.

(By the way, it also appears to me from reading the code that read_mime_types is buggy in that it actually returns a merge of the loaded file with the current module DB state, but I haven't checked that observation.)

----------
keywords: +easy, patch
priority: low -> normal
resolution: works for me -> 
Added file: http://bugs.python.org/file17803/mimetypes-init-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4963>
_______________________________________

From report at bugs.python.org  Tue Jun 29 21:09:07 2010
From: report at bugs.python.org (geremy condra)
Date: Tue, 29 Jun 2010 19:09:07 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <4C2A3A87.6090107@egenix.com>
Message-ID: <AANLkTinL5qPIoYizesTXRaLhNyv1WWRWFu3fKv9szR0q@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

On Tue, Jun 29, 2010 at 2:25 PM, 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:
>>
>>> If we are to require OpenSSL or some other crypto lib,
>>
>> We already depend on OpenSSL for both hashlib and ssl, this proposal
>> wouldn't change anything in this regard.
>
> hashlib can still works without OpenSSL and hash algorithms don't
> fall under crypto laws. ssl doesn't work without OpenSSL, but also
> doesn't require adding any crypto code to the stdlib.

This won't change the status quo, as my code simply leverages OpenSSL
rather than being an independent implementation.

> The main point that needs to be addressed is shipping Python
> with crypto code. If OpenSSL is optionally used, we're fine,
> but if we start shipping crypto code, things are more contrived.

As I say, we're doing things exactly how they're already done. Python
would not be shipping any more crypto code with this module than it
already does.

> See http://rechten.uvt.nl/koops/cryptolaw/ for a survey.

I've looked over it before and didn't notice anything glaringly
applicable, outside of the Windows situation. IANAL, though.

> We're hosting the Python software on servers in The Netherlands,
> so have to follow the Wassenaar Arrangement if we include
> crypto code. Fortunately, that agreement includes a clause which
> pretty much exempts open source crypto code from export regulations.

Again, this seems to me something more relevant to the OpenSSL folks than to us.

> However, users of Python downloading installers with crypto software
> would import and use it in their resp. countries and that may get
> them into trouble, so they need to be warned if we decide to
> ship crypto code with Python.

Your suggestion about a warning for Windows downloads seems
appropriate. I'm not sure how much more than that needs to be done,
though.

> They way I understand Geremy's suggestion is to just include a
> wrapper for OpenSSL, so that's fine. The PEP should include a
> mention of the above to argue against putting e.g. pycrypto
> into the stdlib (not because it's poor software, much to the
> contrary, only because it causes lots of problems for our
> users and the developers).

I'll add mention of the concern over export laws, but it's probably
not feasible to get similar security properties out of any
reimplementation that could be crafted in a reasonable time anyway.

As a note, I intend to have prototype code ready at approximately the
same time as the PEP, so, time permitting, you should be able to play
with this before too long.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Tue Jun 29 21:11:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 19:11:18 +0000
Subject: [issue9117] class syntax not fully documented in reference manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277838678.15.0.603660855603.issue9117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, good plan.  I'll do that.

I'm also not sure about the 'comprehension' bit;  it's true that a comprehension is syntactically valid here (e.g., "class A(x for x in range(3))"), but it's also entirely useless:  it has to be the sole argument, so there can't be a metaclass argument, so the metaclass would have to be type.  But type (quite sensibly) won't accept a generator as a base class.

Oh well;  I suppose it doesn't *have* to make sense to be valid syntax...

This still leaves the hard part, which is distilling the essence of PEP 3115 and adding it to the reference manual.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9117>
_______________________________________

From report at bugs.python.org  Tue Jun 29 21:28:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 19:28:40 +0000
Subject: [issue9120] Reduce pickle size for an empty set
In-Reply-To: <1277839720.0.0.346517516652.issue9120@psf.upfronthosting.co.za>
Message-ID: <1277839720.0.0.346517516652.issue9120@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Empty sets are pickled as set([]).  The pickle contains serialization of an empty list that is passed to set constructor during unpickling:

>>> dis(dumps(set()))
    0: \x80 PROTO      3
    2: c    GLOBAL     'builtins set'
   16: q    BINPUT     0
   18: ]    EMPTY_LIST
   19: q    BINPUT     1
   21: \x85 TUPLE1
   22: q    BINPUT     2
   24: R    REDUCE
   25: q    BINPUT     3
   27: .    STOP

The proposed patch pickles empty set as set() instead:


>>> dis(dumps(set()))
    0: \x80 PROTO      3
    2: c    GLOBAL     'builtins set'
   16: q    BINPUT     0
   18: )    EMPTY_TUPLE
   19: R    REDUCE
   20: q    BINPUT     1
   22: .    STOP

----------
components: Interpreter Core
files: empty-set-pickle.diff
keywords: patch
messages: 108937
nosy: alexandre.vassalotti, belopolsky, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Reduce pickle size for an empty set
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17804/empty-set-pickle.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9120>
_______________________________________

From report at bugs.python.org  Tue Jun 29 21:44:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 19:44:56 +0000
Subject: [issue9117] class syntax not fully documented in reference manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277840696.07.0.447616930054.issue9117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Updated patch.  I've reorganized that documentation section a bit, and added a link to PEP 3115.  This isn't ideal, but it's better than nothing.

----------
Added file: http://bugs.python.org/file17805/issue9117_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9117>
_______________________________________

From report at bugs.python.org  Tue Jun 29 21:46:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 19:46:31 +0000
Subject: [issue9117] class syntax not fully documented in reference manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277840791.88.0.649750611462.issue9117@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

And the same patch, but this time *without* the irrelevant audioop changes. :)

----------
Added file: http://bugs.python.org/file17806/issue9117_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9117>
_______________________________________

From report at bugs.python.org  Tue Jun 29 21:46:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 19:46:38 +0000
Subject: [issue9117] class syntax not fully documented in reference manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277840798.24.0.509975012028.issue9117@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file17805/issue9117_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9117>
_______________________________________

From report at bugs.python.org  Tue Jun 29 21:49:06 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 19:49:06 +0000
Subject: [issue9120] Reduce pickle size for an empty set
In-Reply-To: <1277839720.0.0.346517516652.issue9120@psf.upfronthosting.co.za>
Message-ID: <1277840945.99.0.51783622572.issue9120@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This seems a bit like premature (space) optimization to me.  Is it really worth special-casing this?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9120>
_______________________________________

From report at bugs.python.org  Tue Jun 29 21:49:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 19:49:42 +0000
Subject: [issue9104] test_exceptions does not test pickling with pickle.py
In-Reply-To: <1277741892.3.0.0849773844587.issue9104@psf.upfronthosting.co.za>
Message-ID: <1277840982.95.0.864933171351.issue9104@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> An explicit dictionary to map the Python and C implementations may be a 
> better approach.


Do you mean a global 

optimized_module = {'pickle': '_pickle'}

in test/support.py?


I don't think I like this idea.  Even with an explicit dictionary like that,  support.import_module_implementations() will not support all possible ways that alternative implementations of a given module may be provided in cpython.  It works for pickle/_pickle and heapq/_heapq, but won't work for io/_io/_pyio.  I would like import_module_implementations() to promote uniformity in the way parallel pure/native modules are designed.  Test suites for modules that want more flexibility can always call import_fresh_module() directly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9104>
_______________________________________

From report at bugs.python.org  Tue Jun 29 21:59:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 19:59:00 +0000
Subject: [issue9079] Make gettimeofday available in time module
In-Reply-To: <1277427154.32.0.0996770896527.issue9079@psf.upfronthosting.co.za>
Message-ID: <1277841540.6.0.0952003826113.issue9079@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

To keep things clean, would it be possible to separate this into two patches, one containing the refactoring and one for the newly exposed gettimeofday?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9079>
_______________________________________

From report at bugs.python.org  Tue Jun 29 22:02:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Jun 2010 20:02:15 +0000
Subject: [issue6827] deepcopy erroneously doesn't call __setstate__ if
	__getstate__ returns empty dict
In-Reply-To: <1251926992.64.0.823425954467.issue6827@psf.upfronthosting.co.za>
Message-ID: <1277841735.96.0.539525331597.issue6827@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Given that the API is what is, then it looks like the needed doc improvements have been done.

----------
stage:  -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6827>
_______________________________________

From report at bugs.python.org  Tue Jun 29 22:07:27 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 20:07:27 +0000
Subject: [issue8947] Provide  as_integer_ratio() method to Decimal
In-Reply-To: <1276030268.17.0.98739433208.issue8947@psf.upfronthosting.co.za>
Message-ID: <1277842047.83.0.33124375772.issue8947@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

After discussions on IRC, I'm going to close this as rejected.  Convergence of the float and Decimal APIs is a nice idea, but in this case it's not clear that it really works.  In particular, for duck typing to be sensible, int and Fraction would also have to grow an as_integer_ratio method.  And that seems a superfluous when those two types already have the same functionality in the form of .numerator and .denominator attributes.

I also agree with Raymond that we shouldn't be fattening the decimal API without good reason.

Alexander:  wouldn't conversion to Fraction solve the issue in this case?  The Fraction constructor accepts floats, Decimal instances and ints directly.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8947>
_______________________________________

From report at bugs.python.org  Tue Jun 29 22:11:01 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 20:11:01 +0000
Subject: [issue9120] Reduce pickle size for an empty set
In-Reply-To: <1277839720.0.0.346517516652.issue9120@psf.upfronthosting.co.za>
Message-ID: <1277842261.19.0.784416341252.issue9120@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It is both space and time optimization.

Fred was a proponent of small pickle sizes in the past, so I am adding him to the nosy list.

I am not too keen on this to happen, though.  It just seemed more natural to me not to create an empty list to unpickle an empty set.

By the same logic, allowing set() as an alternative to set([]) in python code is "premature optimization".

The patched code is a bit cleaner than the original without goto's and unnecessary XDECREFs.  (I am not sure what the latest word on redundant initializations is, so I kept =NULLs intact.)

On the other hand collections.deque does not optimize empty case either.

----------
nosy: +fdrake
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9120>
_______________________________________

From report at bugs.python.org  Tue Jun 29 22:12:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 20:12:36 +0000
Subject: [issue1789] assumption about unsigned long byte size in struct module
	usage
In-Reply-To: <1200051073.62.0.595441392864.issue1789@psf.upfronthosting.co.za>
Message-ID: <1277842356.07.0.262437599252.issue1789@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Doc patch committed in revisions r82379 through r82382.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1789>
_______________________________________

From report at bugs.python.org  Tue Jun 29 22:27:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 20:27:37 +0000
Subject: [issue9079] Make gettimeofday available in time module
In-Reply-To: <1277427154.32.0.0996770896527.issue9079@psf.upfronthosting.co.za>
Message-ID: <1277843257.3.0.256622667535.issue9079@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The original patch, gettimeofday.diff was just refactoring.  I unlinked it to keep the file list clean, but it is still available:

http://bugs.python.org/file17766/gettimeofday.diff

I decided to expose time.gettimeofday() in the same patch mostly in order to be able to better explain the consequences of the change such as date.today() now being equivalent to date.fromtimestamp(time.gettimeofday()[0]) rather than date.fromtimestamp(time.time()).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9079>
_______________________________________

From report at bugs.python.org  Tue Jun 29 22:39:54 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 29 Jun 2010 20:39:54 +0000
Subject: [issue9113] Tools/msi still uses string exceptions
In-Reply-To: <1277809491.49.0.571731039318.issue9113@psf.upfronthosting.co.za>
Message-ID: <1277843994.24.0.169866007873.issue9113@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is not a problem. Tools/msi is being used with Python 2.5 only.

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9113>
_______________________________________

From report at bugs.python.org  Tue Jun 29 22:41:59 2010
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 29 Jun 2010 20:41:59 +0000
Subject: [issue9121] Glossary entry for nested scope incorrect
In-Reply-To: <1277844119.14.0.595834938187.issue9121@psf.upfronthosting.co.za>
Message-ID: <1277844119.14.0.595834938187.issue9121@psf.upfronthosting.co.za>


New submission from Ethan Furman <ethan at stoneleaf.us>:

It currently states "Note that nested scopes work only for reference and not for assignment which will always write to the innermost scope."

This should be updated to read, e.g. "Note that unless the new nonlocal keyword is used nested scopes work only for reference and not for assignment which will otherwise write to the innermost scope."

----------
assignee: docs at python
components: Documentation
messages: 108949
nosy: docs at python, stoneleaf
priority: normal
severity: normal
status: open
title: Glossary entry for nested scope incorrect
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9121>
_______________________________________

From report at bugs.python.org  Tue Jun 29 22:55:01 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Jun 2010 20:55:01 +0000
Subject: [issue9121] Glossary entry for nested scope incorrect
In-Reply-To: <1277844119.14.0.595834938187.issue9121@psf.upfronthosting.co.za>
Message-ID: <1277844901.22.0.78350034001.issue9121@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Already fixed.

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9121>
_______________________________________

From report at bugs.python.org  Tue Jun 29 23:01:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 21:01:16 +0000
Subject: [issue1749662] New byte packing format for the struct module
Message-ID: <1277845276.29.0.181423327796.issue1749662@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1749662>
_______________________________________

From report at bugs.python.org  Tue Jun 29 23:01:53 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 29 Jun 2010 21:01:53 +0000
Subject: [issue9120] Reduce pickle size for an empty set
In-Reply-To: <1277839720.0.0.346517516652.issue9120@psf.upfronthosting.co.za>
Message-ID: <1277845313.36.0.628721581233.issue9120@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Will think about this one for a while.  Initial reaction is that the case isn't common enough to care about, and that the 5 byte savings isn't worth the extra code path.

> By the same logic, allowing set() as an alternative 
> to set([]) in python code is "premature optimization".

That wasn't an optimization -- it was needed for API 
consistency with other types (i.e. list(), dict(), etc).
The zero argument form supports a use case for
polymorphic creation of an empty container regardless
of type.

----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9120>
_______________________________________

From report at bugs.python.org  Tue Jun 29 23:13:01 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 29 Jun 2010 21:13:01 +0000
Subject: [issue9106] remove numbers from 3-.. level entries in docs toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277845981.45.0.152049104211.issue9106@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

That just proves that side menu is not very useful. When I need to jump to a sibling paragraph I usually click the rightmost entry in top bar. It takes two clicks to get there and one page reload instead of one.

Perhaps the ToC menu could be expanded using JS and some keyboard shortcut for convenience.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9106>
_______________________________________

From report at bugs.python.org  Tue Jun 29 23:34:42 2010
From: report at bugs.python.org (Alexander Myodov)
Date: Tue, 29 Jun 2010 21:34:42 +0000
Subject: [issue9122] Problems with multiprocessing,
	Python embedding and Windows
In-Reply-To: <1277847282.9.0.57284514454.issue9122@psf.upfronthosting.co.za>
Message-ID: <1277847282.9.0.57284514454.issue9122@psf.upfronthosting.co.za>


New submission from Alexander Myodov <amyodov at gmail.com>:

Hello,

I am using Python 2.6.5 and Cython (to embed the Python interpreter) to create a simple launcher.exe launcher which then imports and uses the remaining logic from the other modules, conveniently stored in a single modules.zip file (i.e. importing from inside zip file). Such setup causes some issues when it comes to the multiprocessing.

First of all, the __main__ module is built as a binary (via Cython->mingw), but the stuff like freeze is not used. In multiprocessing/forking.py, when it comes to determination of the primary path, there is a WINEXE variable which affects the further processing. In its assignment, getattr(sys, 'frozen', False) obviously results in False, causing the WINEXE variable be False too (though in my case it is obviously wrong, the stuff like imp.is_builtin("__main__") shows that the main module is indeed builtin). This is the first problem which probably could be solved by adding an additional check for something like imp.is_builtin("__main__") to WINEXE assignment.
Further, as the WINEXE is wrongly False, it causes the "if not WINEXE:" branch to be processed, and adds the 'main_path' to the data, containing the name of the .exe file. 
On the forked side, d['main_path'] is received and parsed, and the name of the .exe file is split out of its extension, and such name is attempted to be imported, using imp.find_module/imp.load_module. The import fails, as there is indeed no such files wildly lying around in the installation; on the other hand, to get a quick fix of the problem, I thought of adding the appropriate launcher.py(.pyo/.pyc) files into the modules.zip, so that they still could be externally imported by the "launcher" name, even though it is already builtin under the __main__ name; but the second problem is that the imp.find_module/imp.load_module functions do not find the module inside the zip files, like the import statement does.

----------
components: Extension Modules, Windows
messages: 108953
nosy: honeyman
priority: normal
severity: normal
status: open
title: Problems with multiprocessing, Python embedding and Windows
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9122>
_______________________________________

From report at bugs.python.org  Wed Jun 30 00:19:00 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 22:19:00 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1277849940.54.0.562826161307.issue1692335@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The case in msg76028 are probably not pointing to a bug.  If subclass' __init__ passes its args to the base class __init__ (as it probably should), pickling works: 

class E(Exception):
    """Extension with values, init called with args."""
    def __init__(self, foo):
        self.foo = foo
        Exception.__init__(self, foo)

>>> from pickle import *
>>> loads(dumps(E(1)))
E(1,)
>>> _.foo
1

What would be a use case for not setting args?  Even if there was a valid use case for it, it would be easy to simply provide custom __getinitargs__ or __reduce__ to support it.

Note that with msg76028 definitions, eval(repr(C('foo'))) also raises a TypeError, so properly supporting args hiding in exception subclasses would probably involve overriding __repr__ as well.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Wed Jun 30 00:21:01 2010
From: report at bugs.python.org (Casey McGinty)
Date: Tue, 29 Jun 2010 22:21:01 +0000
Subject: [issue6589] smtpd.SMTPServer can cause asyncore.loop to enter
	infinite event loop
In-Reply-To: <1248753598.39.0.190804723361.issue6589@psf.upfronthosting.co.za>
Message-ID: <1277850061.45.0.283494776212.issue6589@psf.upfronthosting.co.za>


Casey McGinty <casey.mcginty at gmail.com> added the comment:

I attached a simple script that reproduces the report issue. I hope it helps.

----------
Added file: http://bugs.python.org/file17807/smtp_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6589>
_______________________________________

From report at bugs.python.org  Wed Jun 30 01:16:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Jun 2010 23:16:14 +0000
Subject: [issue9106] remove numbers from 3-.. level entries in docs toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277853374.34.0.768982147547.issue9106@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No, it just proves that I don't use the side menu.  I use google and the 'find' function of my browser :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9106>
_______________________________________

From report at bugs.python.org  Wed Jun 30 01:19:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 23:19:11 +0000
Subject: [issue6477] Pickling of NoneType raises PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <1277853551.1.0.0171657175568.issue6477@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Ellipsis and NotImplemented are different from None because they are not pickleable themselves.  The None situation is more similar to that of say module level functions:


>>> def f(): pass
... 
>>> dumps(f)  # works
b'\x80\x03c__main__\nf\nq\x00.'
>>> dumps(type(f))  # does not work
Traceback (most recent call last):
  ..
_pickle.PicklingError: Can't pickle <class 'function'>: attribute lookup builtins.function failed


I think documentation at http://docs.python.org/dev/py3k/library/pickle.html#what-can-be-pickled-and-unpickled

Can be improved in two ways:

1. s/types/objects/ in "The following types can be pickled"

2. Add a note that "type(x) can be pickled" does not follow from "x can be pickled."  The object type(x) must itself fall into one on the listed categories.

3. "built-in functions defined at the top level of a module" should probably be "built-in classes or functions defined at the top level of the builtins module"

4. "instances of such classes" should be "instances of picklable classes"

5. "__setstate__() is picklable" should be "output of __getstate__() is picklable"

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6477>
_______________________________________

From report at bugs.python.org  Wed Jun 30 02:54:10 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 30 Jun 2010 00:54:10 +0000
Subject: [issue9120] Reduce pickle size for an empty set
In-Reply-To: <1277839720.0.0.346517516652.issue9120@psf.upfronthosting.co.za>
Message-ID: <1277859250.28.0.807479978024.issue9120@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

> Fred was a proponent of small pickle sizes in the past,
> so I am adding him to the nosy list.

Thanks!

I am a proponent of small pickle sizes, in cases where it
matters.  I'm not convinced this is such a case.

The case for a small pickle size for datetime objects is
that they're very common in pickle-based persistent object
stores, such as ZODB.

Set objects are much less common in this environment; this
extends to most of Python's mutable data structures.  There
are three cases worth noting:

1. A separate persistent object is used to provide an API
   around the core Python data type, with an identical or
   similar API.  This is done to take care of noting
   changes, so the need to update the stored object is
   tracked.  In these cases, minor changes in the pickled
   size of the core object are swamped by the reference to
   the wrapper class.

2. An immutable object is used instead, and updates simply
   replace the value.  This allows the referring object to
   be responsible for change tracking, but means that types
   like the set, list, and dictionary aren't frequently
   used (though they may be used by other objects are part
   of their pickled representations).

3. Application objects may use mutable objects as part of
   their stored data value, but keep careful track of
   updates themselves.  This is most often the case when
   we want to avoid multiple round-trips to the storage
   server, and the size of the pickle isn't particularly
   interesting.

This isn't an argument that the change shouldn't be made,
but experiences with ZODB-like storages don't necessarily
suggest that all pickle sizes need be minimized.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9120>
_______________________________________

From report at bugs.python.org  Wed Jun 30 03:21:03 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 30 Jun 2010 01:21:03 +0000
Subject: [issue9075] ssl module sets "debug" flag on SSL struct
In-Reply-To: <1277420595.3.0.797937330193.issue9075@psf.upfronthosting.co.za>
Message-ID: <1277860863.82.0.203712820863.issue9075@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9075>
_______________________________________

From report at bugs.python.org  Wed Jun 30 04:47:40 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 30 Jun 2010 02:47:40 +0000
Subject: [issue1643370] recursive urlparse
Message-ID: <1277866060.15.0.532535065104.issue1643370@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

This is already handled via namedtuple in the urlparse. All the parts of the url are available by parsing.

----------
resolution:  -> out of date
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1643370>
_______________________________________

From report at bugs.python.org  Wed Jun 30 05:04:14 2010
From: report at bugs.python.org (Eric Huss)
Date: Wed, 30 Jun 2010 03:04:14 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1277867054.64.0.14729723797.issue1692335@psf.upfronthosting.co.za>


Eric Huss <eric at huss.org> added the comment:

Alexander, the use case I was involved with was an RPC system which allowed exceptions to propagate over the connection.  In this case, you do not have absolute control over which exceptions may be raised, or who wrote the code that is raising the exception.  There are many cases, even in the standard library, where people do not pass all arguments to the base exception class.  Some of these are probably mistakes, but in general pickle shouldn't fail on otherwise legitimate objects.

There are other cases where passing all arguments up is not wanted, or at least cumbersome.  If you have multiple levels of inheritance, and subclasses add additional arguments to the init, they wouldn't have a way to include those arguments to the base class unless all classes were written with *args in the init function, which many people would not know or remember to do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Wed Jun 30 05:40:37 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 30 Jun 2010 03:40:37 +0000
Subject: [issue9106] remove numbers from 3-.. level entries in docs toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277869237.54.0.962562726609.issue9106@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

PHP site have a very convenient feature that if you enter http://php.net/some_func - it automatically executes function lookup for you or shows corresponding doc page, i.e. http://php.net/sort

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9106>
_______________________________________

From report at bugs.python.org  Wed Jun 30 05:44:36 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 30 Jun 2010 03:44:36 +0000
Subject: [issue1643370] recursive urlparse
Message-ID: <1277869476.41.0.188538726495.issue1643370@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Senthil, please read the proposals more attentively. From the docs of urlparse at http://docs.python.org/library/urlparse.html

"The components are not broken up in smaller parts (for example, the network location is a single string), and % escapes are not expanded."

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1643370>
_______________________________________

From report at bugs.python.org  Wed Jun 30 05:48:35 2010
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Wed, 30 Jun 2010 03:48:35 +0000
Subject: [issue9123] insecure os.urandom on VMS
In-Reply-To: <1277869715.19.0.305414138773.issue9123@psf.upfronthosting.co.za>
Message-ID: <1277869715.19.0.305414138773.issue9123@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

os.urandom() on VMS invokes OpenSSL's RAND_pseudo_bytes(). That is documented on:

http://www.openssl.org/docs/crypto/RAND_bytes.html

as being predictable and therefore unsuitable for many cryptographic purposes. This is inconsistent with the documentation of os.urandom():

"""
urandom(n) -> str\n\n\
Return a string of n random bytes suitable for cryptographic use.
"""

This probably means that users of Python on VMS are vulnerable to attack based on the predictability of the results they get from os.urandom().

Honestly, I would have guessed that there *were* no users of Python on VMS when I started this bug report, but look--apparently there are:

http://www.vmspython.org

To fix this, change the call from RAND_pseudo_bytes() to RAND_bytes(). It has the same type signature and actually does what os.urandom() needs.

----------
messages: 108963
nosy: zooko
priority: normal
severity: normal
status: open
title: insecure os.urandom on VMS

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9123>
_______________________________________

From report at bugs.python.org  Wed Jun 30 05:49:28 2010
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Wed, 30 Jun 2010 03:49:28 +0000
Subject: [issue9123] insecure os.urandom on VMS
In-Reply-To: <1277869715.19.0.305414138773.issue9123@psf.upfronthosting.co.za>
Message-ID: <1277869768.11.0.314116783552.issue9123@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

HACK Zooko-Ofsimplegeos-MacBook-Pro:~/playground/python/release27-trunk$ svn diff
Index: Modules/posixmodule.c
===================================================================
--- Modules/posixmodule.c       (revision 82382)
+++ Modules/posixmodule.c       (working copy)
@@ -8481,7 +8481,7 @@
     result = PyString_FromStringAndSize(NULL, howMany);
     if (result != NULL) {
         /* Get random data */
-        if (RAND_pseudo_bytes((unsigned char*)
+        if (RAND_bytes((unsigned char*)
                               PyString_AS_STRING(result),
                               howMany) < 0) {
             Py_DECREF(result);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9123>
_______________________________________

From report at bugs.python.org  Wed Jun 30 05:49:57 2010
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Wed, 30 Jun 2010 03:49:57 +0000
Subject: [issue9123] insecure os.urandom on VMS
In-Reply-To: <1277869715.19.0.305414138773.issue9123@psf.upfronthosting.co.za>
Message-ID: <1277869797.91.0.620334967916.issue9123@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

This issue is a security vulnerability.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9123>
_______________________________________

From report at bugs.python.org  Wed Jun 30 06:00:22 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 30 Jun 2010 04:00:22 +0000
Subject: [issue9097] os.chdir(path) to return current dir
In-Reply-To: <1277725409.82.0.324179081421.issue9097@psf.upfronthosting.co.za>
Message-ID: <1277870422.12.0.843838761909.issue9097@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Even though I think that crossplatform language should normalize underlying platform behaviour, you've convinced me. Unneeded extra code execution decides. I also found that in another scenario it is better to return wrapper for target directory to implement chained API similar to string handling.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9097>
_______________________________________

From report at bugs.python.org  Wed Jun 30 11:47:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Jun 2010 09:47:06 +0000
Subject: [issue9123] insecure os.urandom on VMS
In-Reply-To: <1277869715.19.0.305414138773.issue9123@psf.upfronthosting.co.za>
Message-ID: <1277891226.73.0.0411040530953.issue9123@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib)
nosy: +loewis
type:  -> security
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9123>
_______________________________________

From report at bugs.python.org  Wed Jun 30 11:50:11 2010
From: report at bugs.python.org (S Arrowsmith)
Date: Wed, 30 Jun 2010 09:50:11 +0000
Subject: [issue4963] mimetypes.guess_extension result changes after
	mimetypes.init()
In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>
Message-ID: <1277891411.45.0.320670142161.issue4963@psf.upfronthosting.co.za>


S Arrowsmith <siona at chiark.greenend.org.uk> added the comment:

That solution looks sound to me, in particular documenting the semantics of repeated init() calls!

As for the underlying problem, it seems to me that an alternative to copying the existing structures rather than rebuilding them would be to use OrderedDicts. Although I can't think why it might be a preferable alternative, other than being a bit clearer that order of insertion can affect behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4963>
_______________________________________

From report at bugs.python.org  Wed Jun 30 11:51:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Jun 2010 09:51:39 +0000
Subject: [issue9120] Reduce pickle size for an empty set
In-Reply-To: <1277839720.0.0.346517516652.issue9120@psf.upfronthosting.co.za>
Message-ID: <1277891499.82.0.657125503756.issue9120@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A further version of the pickle protocol could have a dedicated opcode for sets instead...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9120>
_______________________________________

From report at bugs.python.org  Wed Jun 30 12:21:43 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 10:21:43 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1277893303.61.0.806441132906.issue9011@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It turns out that removing this code from py3k wasn't a no-op.  It changed the semantics for complex literals.  In Python 3.1.2:

>>> -7j
-7j
>>> (-7j).real
0.0

But in current release31-maint branch, and in 3.2a0:

Python 3.2a0 (py3k:82347M, Jun 28 2010, 22:25:11) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> -7j
(-0-7j)
>>> (-7j).real
-0.0

So IMO r82044 (the release31-maint branch) should be reverted, to avoid nasty surprises when people upgrade from 3.1.2 to 3.1.3.

But I'd like to keep this change in py3k:  I consider that the 3.1 behaviour is buggy, and that the 3.2 behaviour is more correct (strange though it may seem at first sight), so I'd prefer to leave the current py3k behaviour as is, and add a Misc/NEWS entry describing the change if necessary.

Assigning this to me because I don't want it to get forgotten.  But if anyone else is interested in producing a patch for the cleanup of the CST->AST code, please do!

----------
assignee:  -> mark.dickinson
versions:  -Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Wed Jun 30 12:35:12 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 10:35:12 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1277894112.55.0.183312159636.issue9011@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r82044 reverted in r82389.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Wed Jun 30 12:56:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 10:56:55 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1277895415.13.0.0345987474921.issue9011@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Added tests for the current Python < 3.2 treatment of imaginary literals in r82390 (release31-maint).  These tests should be backported to trunk, but I'll wait until after the release of 2.7 for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Wed Jun 30 12:58:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Jun 2010 10:58:33 +0000
Subject: [issue1643370] recursive urlparse
Message-ID: <1277895513.05.0.0791854118726.issue1643370@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since no patch has been proposed since 2007, I think it is time to close this feature request for lack of interest.

In any case I think this functionality would be better situated in a Python3 URI/IRI parsing module with a full object model for the IRI, which is something complicated enough that it may need some time on PyPI before getting in to the standard library.

----------
nosy: +r.david.murray
resolution: out of date -> 
stage: committed/rejected -> unit test needed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1643370>
_______________________________________

From report at bugs.python.org  Wed Jun 30 13:18:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 11:18:25 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1277896705.06.0.519009016204.issue9011@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Added tests for Python 3.2's corrected treatment of negated imaginary literals in r82391, along with a Misc/NEWS entry indicating the changed behaviour.

Restored version numbers for this issue, which I seem to have accidentally deleted earlier.  (Including 3.1, since it could also benefit from the same cleanup.)

----------
versions: +Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Wed Jun 30 13:38:59 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 30 Jun 2010 11:38:59 +0000
Subject: [issue6589] smtpd.SMTPServer can cause asyncore.loop to enter
	infinite event loop
In-Reply-To: <1248753598.39.0.190804723361.issue6589@psf.upfronthosting.co.za>
Message-ID: <1277897939.91.0.257186131364.issue6589@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Although the use case is pretty uncommon and somewhat twisted (take a look at Lib/test/test_ftplib.py for a nicer approach on wrapping asyncore.loop() in a thread) it is true that if SMTPServer class raise an exception at instantiation time, some garbage remains in asyncore.

To replicate this problem there's no need to involve threads:

>>> import asyncore, smtpd
>>> s = smtpd.SMTPServer(('127.0.0.1', "xxx"),None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.5/smtpd.py", line 280, in __init__
    self.bind(localaddr)
  File "/usr/local/lib/python2.5/asyncore.py", line 303, in bind
    return self.socket.bind(addr)
  File "<string>", line 1, in bind
TypeError: an integer is required
>>> asyncore.socket_map
{3: <smtpd.SMTPServer ('127.0.0.1', 'xxx') at 0xb783528c>}
>>> 

I think it's ok for SMTPServer.__init__ to cleanup asyncore and finally raise the exception, as you suggested in the first place.
I'll provide a patch later today.

----------
assignee:  -> giampaolo.rodola
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6589>
_______________________________________

From report at bugs.python.org  Wed Jun 30 13:51:07 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 30 Jun 2010 11:51:07 +0000
Subject: [issue9110] contextlib.ContextDecorator
In-Reply-To: <1277765898.65.0.314299135702.issue9110@psf.upfronthosting.co.za>
Message-ID: <1277898667.23.0.0194379346004.issue9110@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

New patch uploaded with (I think) all suggested changes made. I left some text in the .. versionchanged:: tag for contextmanager as I think this is normal.

----------
Added file: http://bugs.python.org/file17808/contextdecorator.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9110>
_______________________________________

From report at bugs.python.org  Wed Jun 30 13:57:39 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 30 Jun 2010 11:57:39 +0000
Subject: [issue9110] contextlib.ContextDecorator
In-Reply-To: <1277898667.23.0.0194379346004.issue9110@psf.upfronthosting.co.za>
Message-ID: <AANLkTil9wZ1iqKPDKFQIbhr__Jv87KLl2xM5Anw4MQBd@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

On Wed, Jun 30, 2010 at 9:51 PM, Michael Foord <report at bugs.python.org> wrote:
> I left some text in the .. versionchanged:: tag for contextmanager as I think this is normal.

Yeah, what you did was what I meant (I just didn't say it very well)

The example use in the docs should call function() rather than invoke
the context manager explicitly.

Otherwise looks good, so I'd say go ahead and check it in :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9110>
_______________________________________

From report at bugs.python.org  Wed Jun 30 14:19:15 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 30 Jun 2010 12:19:15 +0000
Subject: [issue9110] contextlib.ContextDecorator
In-Reply-To: <1277765898.65.0.314299135702.issue9110@psf.upfronthosting.co.za>
Message-ID: <1277900355.78.0.621993155245.issue9110@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 82394.

I left examples of using ContextDecorator with a decorated *and* in a with statement in the documentation. Feel free to trim the with statement example if you feel it is redundant.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9110>
_______________________________________

From report at bugs.python.org  Wed Jun 30 14:28:23 2010
From: report at bugs.python.org (Steve Holden)
Date: Wed, 30 Jun 2010 12:28:23 +0000
Subject: [issue9124] Mailbox module demonstrates infeasibly slow performance
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>


New submission from Steve Holden <steve at holdenweb.com>:

The attached program completes in less than half a second under Python 2.5. Under Python 3 it takes almost three minutes on the same system. The issue appears to be heavy use of decoding, at least in a Windows system, during creation of the mailbox toc. The disparity may be less remarkable when not profiling.

Further attachments will include a test data file (a Thunderbird mailbox taken from the same host system) and profiler outputs from the 2.5 and 3.1 runs of this program.

----------
components: Library (Lib)
files: test_thunderbird_mailbox.py
messages: 108978
nosy: holdenweb
priority: normal
severity: normal
stage: unit test needed
status: open
title: Mailbox module demonstrates infeasibly slow performance
type: performance
versions: Python 3.1
Added file: http://bugs.python.org/file17809/test_thunderbird_mailbox.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jun 30 14:29:27 2010
From: report at bugs.python.org (Steve Holden)
Date: Wed, 30 Jun 2010 12:29:27 +0000
Subject: [issue9124] Mailbox module demonstrates infeasibly slow performance
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1277900967.82.0.0449714827463.issue9124@psf.upfronthosting.co.za>


Changes by Steve Holden <steve at holdenweb.com>:


Added file: http://bugs.python.org/file17810/test.mailbox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jun 30 14:32:30 2010
From: report at bugs.python.org (Steve Holden)
Date: Wed, 30 Jun 2010 12:32:30 +0000
Subject: [issue9124] Mailbox module demonstrates infeasibly slow performance
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1277901150.72.0.16656469821.issue9124@psf.upfronthosting.co.za>


Changes by Steve Holden <steve at holdenweb.com>:


Added file: http://bugs.python.org/file17811/test2.5.out

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jun 30 14:34:57 2010
From: report at bugs.python.org (Steve Holden)
Date: Wed, 30 Jun 2010 12:34:57 +0000
Subject: [issue9124] Mailbox module demonstrates infeasibly slow performance
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1277901297.79.0.366769446798.issue9124@psf.upfronthosting.co.za>


Changes by Steve Holden <steve at holdenweb.com>:


Added file: http://bugs.python.org/file17812/test3.1.out

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jun 30 14:40:44 2010
From: report at bugs.python.org (Steve Holden)
Date: Wed, 30 Jun 2010 12:40:44 +0000
Subject: [issue9124] Mailbox module demonstrates infeasibly slow performance
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1277901644.4.0.604762324505.issue9124@psf.upfronthosting.co.za>


Steve Holden <steve at holdenweb.com> added the comment:

Thread at http://aspn.activestate.com/ASPN/Mail/Message/python-dev/3873005 refers to this issue. Posted files are already attached herewith.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jun 30 14:47:19 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 30 Jun 2010 12:47:19 +0000
Subject: [issue6589] smtpd.SMTPServer can cause asyncore.loop to enter
	infinite event loop
In-Reply-To: <1248753598.39.0.190804723361.issue6589@psf.upfronthosting.co.za>
Message-ID: <1277902039.78.0.744887535574.issue6589@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +josiah.carlson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6589>
_______________________________________

From report at bugs.python.org  Wed Jun 30 15:43:36 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 30 Jun 2010 13:43:36 +0000
Subject: [issue7830] Flatten nested functools.partial
In-Reply-To: <1265051251.66.0.305258896073.issue7830@psf.upfronthosting.co.za>
Message-ID: <1277905416.62.0.745116170011.issue7830@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a patch, issue7830.diff, that takes an ultra-concervative approach: partials are only flattened if both outer and inner are of exact functools.partial type and the inner partial does not have __dict__.

----------
assignee:  -> belopolsky
keywords: +needs review -patch
nosy: +belopolsky -Alexander.Belopolsky
stage:  -> patch review
versions:  -Python 2.7
Added file: http://bugs.python.org/file17813/issue7830.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7830>
_______________________________________

From report at bugs.python.org  Wed Jun 30 15:58:20 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 30 Jun 2010 13:58:20 +0000
Subject: [issue9124] Mailbox module demonstrates infeasibly slow performance
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1277906300.19.0.90950402584.issue9124@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/issue9124>
_______________________________________

From report at bugs.python.org  Wed Jun 30 16:04:25 2010
From: report at bugs.python.org (Vojtech Fried)
Date: Wed, 30 Jun 2010 14:04:25 +0000
Subject: [issue8056] Piped parent's multiprocessing.Process children cannot
	write to stdout
In-Reply-To: <1267716428.75.0.581894623963.issue8056@psf.upfronthosting.co.za>
Message-ID: <1277906665.7.0.654854808961.issue8056@psf.upfronthosting.co.za>


Vojtech Fried <vojtech.fried at gmail.com> added the comment:

I have the same problem. Not only for piping but also when using redirection, e.g. 'stdout.py > log.txt'.
Interesting thing is that when I run it like 'python.exe stdout.py > log.txt' it works. I don't see why this should matter but apparently it does. ".py" files are registered to be open with '"C:\Python26\python.exe" "%1" %*'. 
My system: WinXp SP3, Python 2.6.5

----------
nosy: +Vojtech.Fried

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8056>
_______________________________________

From report at bugs.python.org  Wed Jun 30 16:18:41 2010
From: report at bugs.python.org (Tim Golden)
Date: Wed, 30 Jun 2010 14:18:41 +0000
Subject: [issue8056] Piped parent's multiprocessing.Process children cannot
	write to stdout
In-Reply-To: <1277906665.7.0.654854808961.issue8056@psf.upfronthosting.co.za>
Message-ID: <4C2B523C.408@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

That's (still...) a known issue with Windows file associations and 
redirects:

   http://support.microsoft.com/kb/321788

In theory it was fixed way back when. In practise...

On 30/06/2010 15:04, Vojtech Fried wrote:
>
> Vojtech Fried<vojtech.fried at gmail.com>  added the comment:
>
> I have the same problem. Not only for piping but also when using redirection, e.g. 'stdout.py>  log.txt'.
> Interesting thing is that when I run it like 'python.exe stdout.py>  log.txt' it works. I don't see why this should matter but apparently it does. ".py" files are registered to be open with '"C:\Python26\python.exe" "%1" %*'.
> My system: WinXp SP3, Python 2.6.5
>
> ----------
> nosy: +Vojtech.Fried
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue8056>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/mail%40timgolden.me.uk

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8056>
_______________________________________

From report at bugs.python.org  Wed Jun 30 16:36:03 2010
From: report at bugs.python.org (Vojtech Fried)
Date: Wed, 30 Jun 2010 14:36:03 +0000
Subject: [issue8056] Piped parent's multiprocessing.Process children cannot
	write to stdout
In-Reply-To: <1267716428.75.0.581894623963.issue8056@psf.upfronthosting.co.za>
Message-ID: <1277908563.49.0.327942267614.issue8056@psf.upfronthosting.co.za>


Vojtech Fried <vojtech.fried at gmail.com> added the comment:

Thanks, the registry change proposed in the article fixed it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8056>
_______________________________________

From report at bugs.python.org  Wed Jun 30 16:36:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 14:36:34 +0000
Subject: [issue9125] parser module doesn't like except-as syntax.
In-Reply-To: <1277908594.27.0.526273796473.issue9125@psf.upfronthosting.co.za>
Message-ID: <1277908594.27.0.526273796473.issue9125@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

There seems to be a parser module bug for the except-as syntax in Python 2.7.  After applying the attached patch (which adds a test to test_parser), and running test_parser, I get:


======================================================================
FAIL: test_try_stmt (__main__.RoundtripLegalSyntaxTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_parser.py", line 237, in test_try_stmt
    self.check_suite("try: pass\nexcept A as e: pass\n")
  File "Lib/test/test_parser.py", line 38, in check_suite
    self.roundtrip(parser.suite, s)
  File "Lib/test/test_parser.py", line 20, in roundtrip
    self.fail("could not roundtrip %r: %s" % (s, why))
AssertionError: could not roundtrip 'try: pass\nexcept A as e: pass\n': Expected node type 12, got 1.

----------
files: parser_except_as_bug.patch
keywords: patch
messages: 108984
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: parser module doesn't like except-as syntax.
versions: Python 2.7
Added file: http://bugs.python.org/file17814/parser_except_as_bug.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9125>
_______________________________________

From report at bugs.python.org  Wed Jun 30 16:37:01 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 14:37:01 +0000
Subject: [issue9125] parser module doesn't like except-as syntax.
In-Reply-To: <1277908594.27.0.526273796473.issue9125@psf.upfronthosting.co.za>
Message-ID: <1277908621.65.0.809072052171.issue9125@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
components: +Library (Lib)
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9125>
_______________________________________

From report at bugs.python.org  Wed Jun 30 16:38:08 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 14:38:08 +0000
Subject: [issue9125] parser module doesn't like except-as syntax.
In-Reply-To: <1277908594.27.0.526273796473.issue9125@psf.upfronthosting.co.za>
Message-ID: <1277908688.45.0.283398560772.issue9125@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's the correct test patch.

----------
Added file: http://bugs.python.org/file17815/parser_except_as_bug.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9125>
_______________________________________

From report at bugs.python.org  Wed Jun 30 16:38:13 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 14:38:13 +0000
Subject: [issue9125] parser module doesn't like except-as syntax.
In-Reply-To: <1277908594.27.0.526273796473.issue9125@psf.upfronthosting.co.za>
Message-ID: <1277908693.52.0.268442367678.issue9125@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file17814/parser_except_as_bug.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9125>
_______________________________________

From report at bugs.python.org  Wed Jun 30 16:41:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 14:41:48 +0000
Subject: [issue9125] parser module doesn't like except-as syntax.
In-Reply-To: <1277908594.27.0.526273796473.issue9125@psf.upfronthosting.co.za>
Message-ID: <1277908908.79.0.429717745576.issue9125@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Minimal steps to reproduce:

Python 2.7rc2+ (trunk:82378M, Jun 29 2010, 19:43:46) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import parser
>>> parser.sequence2st(parser.suite("try: pass\nexcept A as e: pass\n").totuple())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
parser.ParserError: Expected node type 12, got 1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9125>
_______________________________________

From report at bugs.python.org  Wed Jun 30 17:22:46 2010
From: report at bugs.python.org (John Van Praag)
Date: Wed, 30 Jun 2010 15:22:46 +0000
Subject: [issue9126] errors='replace' does not work at Windows command line
In-Reply-To: <1277911366.4.0.473449546724.issue9126@psf.upfronthosting.co.za>
Message-ID: <1277911366.4.0.473449546724.issue9126@psf.upfronthosting.co.za>


New submission from John Van Praag <john at jvp247.com>:

The declaration errors='replace' works from within IDLE but not at the Windows command line. I am attaching a program and text file that demonstrate the problem. The error shows up at the Windows command line as follows:

C:\Users\John\Documents\Python\bug_reports\001>python -m read_my_file
aaaaaaa aaaaaaaaaaaaa aaaaaaaaaaaaaaa aaaaaaaaa

bbbbbbbbbbb bbbbbbbbbbbb bbbbbbbbbbbbbbbbbbb bbbbbbbbbbbb

Traceback (most recent call last):
  File "C:\Python31\lib\runpy.py", line 128, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "C:\Python31\lib\runpy.py", line 34, in _run_code
    exec(code, run_globals)
  File "C:\Users\John\Documents\Python\bug_reports\001\read_my_file.py", line 20, in <module>
    readf()
  File "C:\Users\John\Documents\Python\bug_reports\001\read_my_file.py", line 17, in readf
    print(line)
  File "C:\Python31\lib\encodings\cp437.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode characters in position 10-11: character maps to <undefined>


NOTE: It appears I can only attach 1 file to this report. So I am copying the program here. The text file to read is attached.

'''
read_my_file.py:
Reads lines from faulty file.
Hangs at line 3 when run from Windows command line.
Platforms:
Windows Vista Ultimate 64-bit
Python 3.1.2
'''
#The file to read.
my_file = 'junk.txt'

def readf():
	#The declaration "errors='replace'" is suppposed replace characters the reader does not recognize with a dummy character such as a question mark.
	#This fix works in the interpreter, but not from the Windows command line.
	fh_read = open(my_file, errors='replace')
	for line in fh_read:
		print(line)

#Run.
readf()

----------
components: Windows
files: junk.txt
messages: 108987
nosy: jvanpraag
priority: normal
severity: normal
status: open
title: errors='replace' does not work at Windows command line
versions: Python 3.1
Added file: http://bugs.python.org/file17816/junk.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9126>
_______________________________________

From report at bugs.python.org  Wed Jun 30 17:26:33 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 15:26:33 +0000
Subject: [issue9125] parser module doesn't like except-as syntax.
In-Reply-To: <1277908594.27.0.526273796473.issue9125@psf.upfronthosting.co.za>
Message-ID: <1277911593.24.0.561296459606.issue9125@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a fix.

Benjamin, is this okay for 2.7, or should it wait for 2.7.1?

----------
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file17817/issue9125.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9125>
_______________________________________

From report at bugs.python.org  Wed Jun 30 17:28:58 2010
From: report at bugs.python.org (John Van Praag)
Date: Wed, 30 Jun 2010 15:28:58 +0000
Subject: [issue9029] errors='replace' works in IDLE,
	fails at Windows command line.
In-Reply-To: <1276951681.96.0.0963149365336.issue9029@psf.upfronthosting.co.za>
Message-ID: <1277911734.17915.1382656155@webmail.messagingengine.com>


John Van Praag <john at jvp247.com> added the comment:

I just now resubmitted, with a text file and program demonstrating the
problem: Issue9126.

I am new to submitting Python bug reports and I would like to do it
right. I found I could only attach 1 file to the bug report. However, I
had two files: The text file to read, and the program doing the reading.
Is there some way to attach multiple files to a bug report? If not, what
is the customary way to handle submissions where there is a file to be
processed, and a program doing the processing? And perhaps other files
exhibiting output(s)?

Thanks,

John

On Sat, 19 Jun 2010 12:48 +0000, "R. David Murray"
<report at bugs.python.org> wrote:
> 
> R. David Murray <rdmurray at bitdance.com> added the comment:
> 
> What you show is not a complete program, nor do you provide the complete
> traceback or the data causing the problem.  The most helpful thing would
> be a complete small program and data file demonstrating the problem. 
> That said, I'm wondering if your problem is the encoding of the terminal
> window.
> 
> ----------
> nosy: +r.david.murray
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue9029>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9029>
_______________________________________

From report at bugs.python.org  Wed Jun 30 17:42:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 15:42:37 +0000
Subject: [issue9125] parser module doesn't like except-as syntax.
In-Reply-To: <1277908594.27.0.526273796473.issue9125@psf.upfronthosting.co.za>
Message-ID: <1277912557.72.0.00824126897397.issue9125@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9125>
_______________________________________

From report at bugs.python.org  Wed Jun 30 17:42:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 15:42:47 +0000
Subject: [issue9125] parser module doesn't like except-as syntax.
In-Reply-To: <1277908594.27.0.526273796473.issue9125@psf.upfronthosting.co.za>
Message-ID: <1277912567.97.0.30743535971.issue9125@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9125>
_______________________________________

From report at bugs.python.org  Wed Jun 30 17:49:12 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 15:49:12 +0000
Subject: [issue9125] parser module doesn't like except-as syntax.
In-Reply-To: <1277908594.27.0.526273796473.issue9125@psf.upfronthosting.co.za>
Message-ID: <1277912952.71.0.408403919975.issue9125@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9125>
_______________________________________

From report at bugs.python.org  Wed Jun 30 17:54:57 2010
From: report at bugs.python.org (Benjamin Ryzman)
Date: Wed, 30 Jun 2010 15:54:57 +0000
Subject: [issue9127] subprocess.Popen.communicate() and SIGCHLD handlers
In-Reply-To: <1277913297.34.0.963310724242.issue9127@psf.upfronthosting.co.za>
Message-ID: <1277913297.34.0.963310724242.issue9127@psf.upfronthosting.co.za>


New submission from Benjamin Ryzman <benjamin+python at ryzman.fr>:

http://pastie.org/1025197

Is it deemed acceptable that setting up one's own SIGCHLD handler breaks communicate()?

I did not find it in the documentation.

With the above workaround one can mix communicate() processes with processes spawned in the background that one's too lazy to wait for.

----------
messages: 108990
nosy: zarkdav
priority: normal
severity: normal
status: open
title: subprocess.Popen.communicate() and SIGCHLD handlers
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9127>
_______________________________________

From report at bugs.python.org  Wed Jun 30 17:56:47 2010
From: report at bugs.python.org (Benjamin Ryzman)
Date: Wed, 30 Jun 2010 15:56:47 +0000
Subject: [issue9127] subprocess.Popen.communicate() and SIGCHLD handlers
In-Reply-To: <1277913297.34.0.963310724242.issue9127@psf.upfronthosting.co.za>
Message-ID: <1277913407.33.0.690578009641.issue9127@psf.upfronthosting.co.za>


Changes by Benjamin Ryzman <benjamin+python at ryzman.fr>:


----------
assignee:  -> docs at python
components: +Documentation, Library (Lib)
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9127>
_______________________________________

From report at bugs.python.org  Wed Jun 30 17:56:59 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 30 Jun 2010 15:56:59 +0000
Subject: [issue9127] subprocess.Popen.communicate() and SIGCHLD handlers
In-Reply-To: <1277913297.34.0.963310724242.issue9127@psf.upfronthosting.co.za>
Message-ID: <1277913419.6.0.68704902385.issue9127@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

You should include all relevant issue materials here, in the Python issue tracker.  This ticket will be useless as soon as pastie.org decides to forget about your paste.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9127>
_______________________________________

From report at bugs.python.org  Wed Jun 30 17:59:32 2010
From: report at bugs.python.org (Benjamin Ryzman)
Date: Wed, 30 Jun 2010 15:59:32 +0000
Subject: [issue9127] subprocess.Popen.communicate() and SIGCHLD handlers
In-Reply-To: <1277913297.34.0.963310724242.issue9127@psf.upfronthosting.co.za>
Message-ID: <1277913572.34.0.974747400231.issue9127@psf.upfronthosting.co.za>


Benjamin Ryzman <benjamin+python at ryzman.fr> added the comment:

Content of the above pastie:

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.
>>> import signal
>>> import subprocess
>>> signal.signal(signal.SIGCHLD,signal.SIG_IGN)
0
>>> subprocess.Popen(["echo","blah"], stdout=subprocess.PIPE).communicate()[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/subprocess.py", line 698, in communicate
    self.wait()
  File "/usr/lib/python2.6/subprocess.py", line 1170, in wait
    pid, sts = _eintr_retry_call(os.waitpid, self.pid, 0)
  File "/usr/lib/python2.6/subprocess.py", line 465, in _eintr_retry_call
    return func(*args)
OSError: [Errno 10] No child processes
>>> oldsignal = signal.signal(signal.SIGCHLD,signal.SIG_DFL)
>>> subprocess.Popen(["echo","blah"], stdout=subprocess.PIPE).communicate()[0]
'blah\n'
>>> signal.signal(signal.SIGCHLD,oldsignal)
0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9127>
_______________________________________

From report at bugs.python.org  Wed Jun 30 18:07:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 16:07:59 +0000
Subject: [issue9125] parser module doesn't like except-as syntax.
In-Reply-To: <1277908594.27.0.526273796473.issue9125@psf.upfronthosting.co.za>
Message-ID: <1277914079.09.0.264527187605.issue9125@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Updated patch, LBYL instead of EAFP flavour.

Oh, and this one actually compiles, too.

----------
Added file: http://bugs.python.org/file17818/issue9125_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9125>
_______________________________________

From report at bugs.python.org  Wed Jun 30 18:12:42 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 30 Jun 2010 16:12:42 +0000
Subject: [issue9125] parser module doesn't like except-as syntax.
In-Reply-To: <1277908594.27.0.526273796473.issue9125@psf.upfronthosting.co.za>
Message-ID: <1277914362.22.0.466847888517.issue9125@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Go ahead.

----------
stage: commit review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9125>
_______________________________________

From report at bugs.python.org  Wed Jun 30 18:37:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 16:37:31 +0000
Subject: [issue9125] parser module doesn't like except-as syntax.
In-Reply-To: <1277908594.27.0.526273796473.issue9125@psf.upfronthosting.co.za>
Message-ID: <1277915851.94.0.761935752747.issue9125@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Benjamin.  Applied in r82400 (trunk) and r82401 (release26-maint).

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9125>
_______________________________________

From report at bugs.python.org  Wed Jun 30 18:48:16 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 30 Jun 2010 16:48:16 +0000
Subject: [issue9120] Reduce pickle size for an empty set
In-Reply-To: <1277839720.0.0.346517516652.issue9120@psf.upfronthosting.co.za>
Message-ID: <1277916496.49.0.296771662453.issue9120@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> A further version of the pickle protocol could 
> have a dedicated opcode for sets instead...

-1 We don't have to introduce a new (and backwards incompatible) opcode for every possible container type.  The space savings is miniscule (because you still need to list out the items).  All that is saved is the enclosing list or tuple setup (five bytes in the case of sets). 

People concerned about pickle size would be much better off investing time into a more generic solution (such as adding a code to automatically run zip/gzip/bzip/xz etc).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9120>
_______________________________________

From report at bugs.python.org  Wed Jun 30 18:51:42 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 30 Jun 2010 16:51:42 +0000
Subject: [issue9029] errors='replace' works in IDLE,
	fails at Windows command line.
In-Reply-To: <1276890229.73.0.493277821026.issue9029@psf.upfronthosting.co.za>
Message-ID: <1277916702.85.0.548204151396.issue9029@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> errors='replace' does not work at Windows command line

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9029>
_______________________________________

From report at bugs.python.org  Wed Jun 30 19:02:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Jun 2010 17:02:20 +0000
Subject: [issue9120] Reduce pickle size for an empty set
In-Reply-To: <1277839720.0.0.346517516652.issue9120@psf.upfronthosting.co.za>
Message-ID: <1277917340.77.0.800564686153.issue9120@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> A further version of the pickle protocol could 
> > have a dedicated opcode for sets instead...
> 
> -1 We don't have to introduce a new (and backwards incompatible)
> opcode for every possible container type.

What I was implying is that someone interested in more efficient pickles could start the work of a new protocol version which would *include* such an improvement.

> All that is saved is the enclosing list or tuple setup (five bytes
> in the case of sets).

No, you would save the (string) reference to "builtins.set" and the whole constructor invocation boilerplate.

>>> len(pickle.dumps([1,2,3]))
14
>>> len(pickle.dumps({1,2,3}))
36

See? The difference is much more than 5 bytes.

What's more, you would avoid building a temporary list only to convert it to a set at the end.

> People concerned about pickle size would be much better off investing > time into a more generic solution (such as adding a code to
> automatically run zip/gzip/bzip/xz etc).

That's at the expense of (un)pickling speed, though, while the above suggestion would improve performance in addition to reducing pickle sizes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9120>
_______________________________________

From report at bugs.python.org  Wed Jun 30 19:13:13 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 30 Jun 2010 17:13:13 +0000
Subject: [issue6589] smtpd.SMTPServer can cause asyncore.loop to enter
	infinite event loop
In-Reply-To: <1248753598.39.0.190804723361.issue6589@psf.upfronthosting.co.za>
Message-ID: <1277917993.03.0.330388685216.issue6589@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Patch in attachment.

----------
keywords: +patch
Added file: http://bugs.python.org/file17819/smtpd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6589>
_______________________________________

From report at bugs.python.org  Wed Jun 30 19:45:02 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 30 Jun 2010 17:45:02 +0000
Subject: [issue9120] Reduce pickle size for an empty set
In-Reply-To: <1277839720.0.0.346517516652.issue9120@psf.upfronthosting.co.za>
Message-ID: <1277919902.77.0.0519030541831.issue9120@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

>> People concerned about pickle size would be much better off investing >> time into a more generic solution (such as adding a code to
>> automatically run zip/gzip/bzip/xz etc).

> That's at the expense of (un)pickling speed, ...

Wanted to reply here so that the suggestion doesn't get lost.

When talking about pickle speed performance, we need to take into account that most use cases for pickle are i/o bound.  IOW, the time to pickle and unpickle is dominated by the time needed to read/write the pickle to/from disk or to send it across the wire.  In those common use cases, any time spent compressing/decompressing is more than made for by savings in transport/storage time.   This is a fairly common speed optimization and it would be nice if pickles supported it directly (i.e. the sender specifies a compression option and the receiver automatically detects the option from an opcode in the pickle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9120>
_______________________________________

From report at bugs.python.org  Wed Jun 30 19:53:46 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 30 Jun 2010 17:53:46 +0000
Subject: [issue6589] smtpd.SMTPServer can cause asyncore.loop to enter
	infinite event loop
In-Reply-To: <1248753598.39.0.190804723361.issue6589@psf.upfronthosting.co.za>
Message-ID: <1277920426.68.0.94089622801.issue6589@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Fixed in r82404, r82406, r82407 and r82408.

----------
resolution:  -> fixed
stage: unit test needed -> 
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6589>
_______________________________________

From report at bugs.python.org  Wed Jun 30 19:54:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Jun 2010 17:54:45 +0000
Subject: [issue9120] Reduce pickle size for an empty set
In-Reply-To: <1277919902.77.0.0519030541831.issue9120@psf.upfronthosting.co.za>
Message-ID: <1277920479.3240.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> When talking about pickle speed performance, we need to take into
> account that most use cases for pickle are i/o bound.  IOW, the time
> to pickle and unpickle is dominated by the time needed to read/write
> the pickle to/from disk or to send it across the wire.  In those
> common use cases, any time spent compressing/decompressing is more
> than made for by savings in transport/storage time.

This is an oversimplification. Transport and storage performance is
mostly orthogonal to CPU performance; depending on the situation, you
might care about the former, or the latter, or both. Adding a
compression layer obviously taxes the CPU more, while optimizing
bytecode decreases CPU consumption as I've pointed out.

(for example, it is quite unlikely, IMO, that ZODB setups are I/O bound
rather than CPU bound, given that it's a database system written in
Python; and even optimized databases such as PostgreSQL can exhibit
CPU-bound behaviour, depending on the hardware configuration, the
database size and the queries issued)

> This is a fairly common speed optimization and it would be nice if
> pickles supported it directly (i.e. the sender specifies a compression
> option and the receiver automatically detects the option from an
> opcode in the pickle.

I'm not sure what would be the point. It is trivially easy for people to
add that compression layer to their own protocols if they want to. Also,
the C code for pickle doesn't have to be complicated by interfacing it
with various third-party compression libraries.

(a doc addition would be more reasonable)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9120>
_______________________________________

From report at bugs.python.org  Wed Jun 30 20:07:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 30 Jun 2010 18:07:11 +0000
Subject: [issue4384] Add a warnings.showwarning replacement for logging
In-Reply-To: <1227309698.77.0.511874051241.issue4384@psf.upfronthosting.co.za>
Message-ID: <1277921231.18.0.456454038149.issue4384@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage: needs patch -> committed/rejected
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4384>
_______________________________________

From report at bugs.python.org  Wed Jun 30 20:11:42 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 18:11:42 +0000
Subject: [issue9128] Parser module fails to validate class decorators
	correctly.
In-Reply-To: <1277921502.31.0.321329745458.issue9128@psf.upfronthosting.co.za>
Message-ID: <1277921502.31.0.321329745458.issue9128@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Python 2.7rc2+ (trunk:82399M, Jun 30 2010, 17:10:13) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import parser
[35303 refs]
>>> parser.sequence2st(parser.suite("@deco\nclass A(): pass").totuple())
<parser.st object at 0x10045d310>
XXX undetected error
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
parser.ParserError: Expected node type 262, got 330.
[35347 refs]

Patch attached.

----------
components: Extension Modules
files: parser_class_decorator.patch
keywords: patch
messages: 109002
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: Parser module fails to validate class decorators correctly.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17820/parser_class_decorator.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9128>
_______________________________________

From report at bugs.python.org  Wed Jun 30 20:44:27 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 30 Jun 2010 18:44:27 +0000
Subject: [issue9129] DoS smtpd module vulnerability
In-Reply-To: <1277923467.7.0.260357628044.issue9129@psf.upfronthosting.co.za>
Message-ID: <1277923467.7.0.260357628044.issue9129@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

Steps to reproduce the issue:

- in one shell run: "python -m smtpd -n"
- in another one run: "for i in {1..1000};do nmap -sT -p 8025 localhost;done"

The server will print out the following output and just quit (DoS):

giampaolo at ubuntu:~/svn/python-2.7$ ./python -m smtpd -n 
error: uncaptured python exception, closing channel <__main__.PureProxy listening localhost:8025 at 0xb74b0f4c> (<class 'socket.error'>:[Errno 107] Transport endpoint is not connected [/home/giampaolo/svn/python-2.7/Lib/asyncore.py|read|79] [/home/giampaolo/svn/python-2.7/Lib/asyncore.py|handle_read_event|430] [/home/giampaolo/svn/python-2.7/Lib/smtpd.py|handle_accept|296] [/home/giampaolo/svn/python-2.7/Lib/smtpd.py|__init__|124] [/home/giampaolo/svn/python-2.7/Lib/socket.py|meth|222])
giampaolo at ubuntu:~/svn/python-2.7$ 

This is due to issue 6706.

----------
components: Library (Lib)
messages: 109003
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: DoS smtpd module vulnerability
type: security
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9129>
_______________________________________

From report at bugs.python.org  Wed Jun 30 20:57:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 30 Jun 2010 18:57:41 +0000
Subject: [issue9120] Reduce pickle size for an empty set
In-Reply-To: <1277839720.0.0.346517516652.issue9120@psf.upfronthosting.co.za>
Message-ID: <1277924261.4.0.842383846861.issue9120@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> We don't have to introduce a new (and backwards incompatible)
> opcode for every possible container type.

I would draw the line at containers that have literal syntax (and necessarily have dedicated .pyc opcode).

This begs a question, however: why not use regular python bytecode in pickles?

I understand that originally pickle bytecode was supposed to restrict what functionality is available to unpickler, but this is a moot point these days.

The pickle documentation has a big red security warning (and some want to make it even bigger and redder, issue9105.)

Indeed, I've just checked that the following works:

>>> from pickle import *
>>> class evil:
...    def __reduce__(self):
...        return (exec, ("print('pwned!')",)) 
... 
>>> s = dumps(evil())
>>> loads(s)
pwned!


The advantages of using standard bytecode are numerous:

1. Python bytecode is much better understood than pickle bytecode.  Since it is exercised by every python program, bugs related to bytecode execution tend to be found and fixed quickly while pickle bytecode is considered to be quirky by many.

2. Much more effort had been spend on optimizing various aspects of python bytecode than pickle bytecode.

3. Using python bytecode will remove numerous arbitrary restrictions that current pickle protocol has such as not being able to pickle non module-level objects or anonymous functions.

The only downside I can think of is that doing this would place an extra constraint on bytecode evolution because pickles written by current version of python should remain loadable in all future versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9120>
_______________________________________

From report at bugs.python.org  Wed Jun 30 21:02:55 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 30 Jun 2010 19:02:55 +0000
Subject: [issue9129] DoS smtpd module vulnerability
In-Reply-To: <1277923467.7.0.260357628044.issue9129@psf.upfronthosting.co.za>
Message-ID: <1277924575.13.0.0413103333041.issue9129@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

It would be ideal to solve this issue in asyncore.py by fixing dispatcher.accept() once and for all, but I'm not sure whether this can be done in a fully retro-compatible way in terms of asyncore API.

Alternatively SMTPServer.handle_accept() can be fixed in the same way as pyftpdlib did:
http://code.google.com/p/pyftpdlib/source/browse/tags/release-0.5.2/pyftpdlib/ftpserver.py#622

   def handle_accept(self)
       try:
            sock, addr = self.accept()
        except TypeError:
            # sometimes accept() might return None
            return
        except socket.error, err:
            # ECONNABORTED might be thrown
            if err[0] != errno.ECONNABORTED:
                raise
            return
        else:
            # sometimes addr == None instead of (ip, port)
            if addr == None:
                return

----------
nosy: +josiah.carlson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9129>
_______________________________________

From report at bugs.python.org  Wed Jun 30 21:31:07 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 19:31:07 +0000
Subject: [issue9130] Parser module fails on short relative imports
In-Reply-To: <1277926266.72.0.295877621023.issue9130@psf.upfronthosting.co.za>
Message-ID: <1277926266.72.0.295877621023.issue9130@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Python 2.7rc2+ (trunk:82399M, Jun 30 2010, 17:10:13) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import parser
[35303 refs]
>>> parser.sequence2st(parser.suite("from . import me").totuple())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
parser.ParserError: VALIDATION FAILURE: report this to the maintainer!
[35341 refs]

Patch attached.

----------
assignee: mark.dickinson
components: Extension Modules
files: parser_relative_imports.patch
keywords: patch
messages: 109006
nosy: mark.dickinson
priority: normal
severity: normal
stage: commit review
status: open
title: Parser module fails on short relative imports
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17821/parser_relative_imports.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9130>
_______________________________________

From report at bugs.python.org  Wed Jun 30 21:35:04 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 19:35:04 +0000
Subject: [issue9130] Parser module fails on short relative imports
In-Reply-To: <1277926266.72.0.295877621023.issue9130@psf.upfronthosting.co.za>
Message-ID: <1277926504.35.0.762014763993.issue9130@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

With this patch, and the one in issue 9128, the parser module roundtrips correctly on all Lib/*.py and all Lib/test/*.py files (except for Lib/test/bad*.py).  Tested by doing:

./python.exe Demo/parser/test_parser.py Lib/*.py

and

./python.exe Demo/parser/test_parser.py Lib/test/*.py

(the latter after deleting the Lib/test/bad*.py files)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9130>
_______________________________________

From report at bugs.python.org  Wed Jun 30 21:48:00 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 30 Jun 2010 19:48:00 +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: <1277927280.23.0.76585633164.issue9131@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

test_set_reprs in test_pprint creates a complex arrangement of frozensets and tests the pretty-printed repr against a string hard-coded in the test.  The hard-coded repr depends on the sort order of frozensets.  

However, "Since sets only define partial ordering (subset relationships), the output of the list.sort() method is undefined for lists of sets." (quoting http://docs.python.org/release/3.1/library/stdtypes.html#set-types-set-frozenset)

In a nutshell, the test assumes frozenset({0}) will always sort before frozenset({1}), but:

>>> frozenset({0}) < frozenset({1})
False
>>> frozenset({1}) < frozenset({0})
False

Consequently, this test is fragile.  Small changes to Python's sort algorithm cause the test to fail when it should pass.

I ran into this while playing with optimizations to the sort function, but I imagine other Python implementations will also run into trouble with this test.

----------
assignee: stutzbach
components: Tests
messages: 109008
nosy: stutzbach
priority: low
severity: normal
stage: needs patch
status: open
title: test_set_reprs in test_pprint is fragile
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9131>
_______________________________________

From report at bugs.python.org  Wed Jun 30 21:59:11 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 30 Jun 2010 19:59:11 +0000
Subject: [issue9132] Documentation for comparing dictionaries is out of date
In-Reply-To: <1277927951.56.0.908504944608.issue9132@psf.upfronthosting.co.za>
Message-ID: <1277927951.56.0.908504944608.issue9132@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

reference/expressions.html#notin reads:

"Mappings (dictionaries) compare equal if and only if their sorted (key, value) lists compare equal. [4] Outcomes other than equality are resolved consistently, but are not otherwise defined. [5]"

However, the last sentence is no longer true.  I suggest changing the last sentence to:

"Comparisons other than equality testing raise a TypeError."

I think the footnote [5] is sufficiently historical that it could be removed as well.  Alternately, it could be updated to read, "In older versions of Python, outcomes other than equality were resolved consistently but were not otherwise defined."

----------
assignee: docs at python
components: Documentation
messages: 109009
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Documentation for comparing dictionaries is out of date
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9132>
_______________________________________

From report at bugs.python.org  Wed Jun 30 21:59:27 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 30 Jun 2010 19:59:27 +0000
Subject: [issue9132] Documentation for comparing dictionaries is out of date
In-Reply-To: <1277927951.56.0.908504944608.issue9132@psf.upfronthosting.co.za>
Message-ID: <1277927967.86.0.814984342411.issue9132@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9132>
_______________________________________

From report at bugs.python.org  Wed Jun 30 22:02:54 2010
From: report at bugs.python.org (Mike Lewis)
Date: Wed, 30 Jun 2010 20:02:54 +0000
Subject: [issue9133] Invalid UTF8 Byte sequence not raising exception/being
	substituted
In-Reply-To: <1277928174.53.0.503418777966.issue9133@psf.upfronthosting.co.za>
Message-ID: <1277928174.53.0.503418777966.issue9133@psf.upfronthosting.co.za>


New submission from Mike Lewis <mikelikespie at gmail.com>:

When I do
codecs.encode(codecs.decode('\xed\xbc\xad', 'utf8'), 'utf8')

its not throwing an exception.  '\xed\xbc\xad' is an invalid UTF8 byte sequence.

It maps to the value U+DF2D which is a "surrogate pair" it seems.

http://tools.ietf.org/html/rfc3629#section-4

explains:

      However, pairs of
      UCS-2 values between D800 and DFFF (surrogate pairs in Unicode
      parlance), being actually UCS-4 characters transformed through
      UTF-16, need special treatment: the UTF-16 transformation must be
      undone, yielding a UCS-4 character that is then transformed as
      above.

which would suggest that it is invalid.

However, I think wikipedia's explanation is a bit clearer:

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.


Thanks,
Mike

----------
components: Unicode
messages: 109010
nosy: Mike.Lewis
priority: normal
severity: normal
status: open
title: Invalid UTF8 Byte sequence not raising exception/being substituted
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9133>
_______________________________________

From report at bugs.python.org  Wed Jun 30 22:07:19 2010
From: report at bugs.python.org (Mike Lewis)
Date: Wed, 30 Jun 2010 20:07:19 +0000
Subject: [issue9133] Invalid UTF8 Byte sequence not raising exception/being
	substituted
In-Reply-To: <1277928174.53.0.503418777966.issue9133@psf.upfronthosting.co.za>
Message-ID: <1277928439.51.0.911025977889.issue9133@psf.upfronthosting.co.za>


Mike Lewis <mikelikespie at gmail.com> added the comment:

Sorry, meant to add this part to the quote from the rfc:

This leads to different results for character
   numbers above 0xFFFF; the CESU-8 encoding of those characters is NOT
   valid UTF-8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9133>
_______________________________________

From report at bugs.python.org  Wed Jun 30 22:11:52 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 30 Jun 2010 20:11:52 +0000
Subject: [issue9133] Invalid UTF8 Byte sequence not raising exception/being
	substituted
In-Reply-To: <1277928174.53.0.503418777966.issue9133@psf.upfronthosting.co.za>
Message-ID: <1277928712.22.0.282819613157.issue9133@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is already fixed in Python 3.
However I think that for backward compatibility reasons it can't be fixed in Python 2, where it is possible to encode and decode every codepoint to/from UTF-8.

See also http://bugs.python.org/issue8271#msg102209

I think this can be closed as wontfix.

----------
nosy: +ezio.melotti, haypo, lemburg
status: open -> pending
type:  -> behavior
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9133>
_______________________________________

From report at bugs.python.org  Wed Jun 30 22:20:26 2010
From: report at bugs.python.org (Conrad.Irwin)
Date: Wed, 30 Jun 2010 20:20:26 +0000
Subject: [issue5006] Duplicate UTF-16 BOM if a file is open in append mode
In-Reply-To: <1232407475.88.0.821271875363.issue5006@psf.upfronthosting.co.za>
Message-ID: <1277929226.42.0.360173034631.issue5006@psf.upfronthosting.co.za>


Conrad.Irwin <conrad.irwin at gmail.com> added the comment:

Shouldn't this fix be back-ported to the 2.6 branch too?

----------
nosy: +Conrad.Irwin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5006>
_______________________________________

From report at bugs.python.org  Wed Jun 30 22:21:41 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 30 Jun 2010 20:21:41 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za>
Message-ID: <1277929301.72.0.548881051648.issue8271@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The issue about invalid surrogates in UTF-8 has been raised in #9133.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8271>
_______________________________________

From report at bugs.python.org  Wed Jun 30 22:25:37 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 30 Jun 2010 20:25:37 +0000
Subject: [issue9133] Invalid UTF8 Byte sequence not raising exception/being
	substituted
In-Reply-To: <1277928174.53.0.503418777966.issue9133@psf.upfronthosting.co.za>
Message-ID: <1277929537.75.0.557063726273.issue9133@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
resolution:  -> wont fix
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9133>
_______________________________________

From report at bugs.python.org  Wed Jun 30 22:26:52 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 20:26:52 +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: <1277929612.68.0.596778960338.issue9131@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I agree that this looks a bit suspicious.

Adding Raymond to the nosy list, since it looks like this is his code (r60264).

----------
nosy: +mark.dickinson, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9131>
_______________________________________

From report at bugs.python.org  Wed Jun 30 22:38:30 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 30 Jun 2010 20:38:30 +0000
Subject: [issue9133] Invalid UTF8 Byte sequence not raising exception/being
	substituted
In-Reply-To: <1277928712.22.0.282819613157.issue9133@psf.upfronthosting.co.za>
Message-ID: <4C2BAB43.606@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> 
> I think this can be closed as wontfix.

Agreed. I've already closed the ticket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9133>
_______________________________________

From report at bugs.python.org  Wed Jun 30 22:58:00 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 30 Jun 2010 20:58:00 +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: <1277931480.1.0.946429223713.issue9131@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Yes, it's a fragile and crummy test.
Feel free to delete it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9131>
_______________________________________

From report at bugs.python.org  Wed Jun 30 23:18:58 2010
From: report at bugs.python.org (Armin Rigo)
Date: Wed, 30 Jun 2010 21:18:58 +0000
Subject: [issue9134] sre bug: lastmark_save/restore
In-Reply-To: <1277932738.21.0.537266945796.issue9134@psf.upfronthosting.co.za>
Message-ID: <1277932738.21.0.537266945796.issue9134@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

The re module is buggy is rare cases; see attached example script.

The bug is caused by the macros LASTMARK_SAVE and LASTMARK_RESTORE which are sometimes used without the extra code that does if (state->repeat) {mark_save()/mark_restore()}.

The bug appears by mis-reporting the position of groups within a repeated match (with * or +), notably the position of some groups that matched in older repetitions but (after some backtracking) not in newer ones.

----------
components: Extension Modules
files: x.py
messages: 109019
nosy: arigo
priority: normal
severity: normal
status: open
title: sre bug: lastmark_save/restore
versions: Python 2.7
Added file: http://bugs.python.org/file17822/x.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9134>
_______________________________________

From report at bugs.python.org  Wed Jun 30 23:32:35 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 30 Jun 2010 21:32:35 +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: <1277933555.47.0.353364241146.issue9131@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

After discussion on #python-dev, have decided to mark the test as implementation specific and add a comment about why the test is fragile.

----------
assignee: stutzbach -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9131>
_______________________________________

From report at bugs.python.org  Wed Jun 30 23:57:19 2010
From: report at bugs.python.org (Delaney Gillilan)
Date: Wed, 30 Jun 2010 21:57:19 +0000
Subject: [issue9135] XMLRPC documentation binary file example does not execute.
In-Reply-To: <1277935039.2.0.645963756108.issue9135@psf.upfronthosting.co.za>
Message-ID: <1277935039.2.0.645963756108.issue9135@psf.upfronthosting.co.za>


New submission from Delaney Gillilan <delaneygillilan at gmail.com>:

Documentation available at http://docs.python.org/release/3.0.1/library/xmlrpc.client.html#binary-objects produced incorrect results ...

Traceback (most recent call last):
  File "test_server.py", line 28, in <module>
    print(handle.read().format('utf-8'))
  File "C:\python31\lib\io.py", line 1728, in read
    decoder.decode(self.buffer.read(), final=True))
  File "C:\python31\lib\io.py", line 1299, in decode
    output = self.decoder.decode(input, final=final)
  File "C:\python31\lib\encodings\cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 252: character maps to <undefined>

However a quick change (new to Python3 so this may need work) gives desired results.

Server:
from xmlrpc.server import SimpleXMLRPCServer
import xmlrpc.client
def python_logo():
     handle = open("python_logo.jpg", "rb") <-- needed "rb"
     return xmlrpc.client.Binary(handle.read())
     handle.close()
server = SimpleXMLRPCServer(("localhost", 8000))
print("Listening on port 8000...")
server.register_function(python_logo, 'python_logo')
server.serve_forever()

Client:
import xmlrpc.client
proxy = xmlrpc.client.ServerProxy("http://localhost:8000/")
handle = open("fetched_python_logo.jpg", "wb") <-- needed "wb"
handle.write(proxy.python_logo().data)
handle.close()

Please update the documentation.  Thanks!

----------
components: Library (Lib)
messages: 109021
nosy: Delaney.Gillilan
priority: normal
severity: normal
status: open
title: XMLRPC documentation binary file example does not execute.
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9135>
_______________________________________

From report at bugs.python.org  Wed Jun 30 23:59:30 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 30 Jun 2010 21:59:30 +0000
Subject: [issue9135] XMLRPC documentation binary file example does not execute.
In-Reply-To: <1277935039.2.0.645963756108.issue9135@psf.upfronthosting.co.za>
Message-ID: <1277935170.59.0.0478937132301.issue9135@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is already fixed in the latest version of the doc: http://docs.python.org/py3k/library/xmlrpc.client.html#binary-objects

----------
nosy: +ezio.melotti
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9135>
_______________________________________