[issue13737] bugs.python.org's Django settings file DEBUG=True

[Bithin A]

New submission from Bithin A :

I am getting an Django error when I was trying to review a patch. This error 
has occurred in the site as the DEBUG mode in the Django settings file is set 
to True. It is a security issue and should be set to false. I am attaching the 
screen shot of the error which I have come across.

--
components: None
files: Screenshot at 2012-01-08 13:11:43.png
messages: 150852
nosy: Bithin.A
priority: normal
severity: normal
status: open
title: bugs.python.org's Django settings file DEBUG=True
type: security
Added file: http://bugs.python.org/file24174/Screenshot at 2012-01-08 
13:11:43.png

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12364] Deadlock in test_concurrent_futures

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 26389e9efa9c by Ross Lagerwall in branch '3.2':
Issue #12364: Fix a hang in concurrent.futures.ProcessPoolExecutor.
http://hg.python.org/cpython/rev/26389e9efa9c

New changeset 25f879011102 by Ross Lagerwall in branch 'default':
Merge with 3.2 for #12364.
http://hg.python.org/cpython/rev/25f879011102

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13736] urllib.request.urlopen leaks exceptions from socket and httplib.client

[Jyotirmoy Bhattacharya]

Jyotirmoy Bhattacharya  added the comment:

A patch to fix this issue. Catches exceptions from underlying libraries and 
reraises them as URLError.

I put the class name of the underlying exception in the reason to make it more 
descriptive.

--
keywords: +patch
type:  -> behavior
Added file: http://bugs.python.org/file24173/urllib_exception_leak.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13736] urllib.request.urlopen leaks exceptions from socket and httplib.client

[Jyotirmoy Bhattacharya]

New submission from Jyotirmoy Bhattacharya :

The documentation for urlopen says that it raises URLError on error. 
But there exist error conditions such as a socket timeout or a bad HTTP status 
line under which the exception from the underlying library leaks through 
urllib, thus breaking the promise in the documentation.

I am attaching a test program that demonstrates this bug.

--
components: Library (Lib)
files: test_urllib_except.py
messages: 150849
nosy: jmoy, orsenthil
priority: normal
severity: normal
status: open
title: urllib.request.urlopen leaks exceptions from socket and httplib.client
versions: Python 3.3
Added file: http://bugs.python.org/file24172/test_urllib_except.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4489] shutil.rmtree is vulnerable to a symlink attack

[Ross Lagerwall]

Changes by Ross Lagerwall :


--
dependencies: +Add a generic directory walker method to avoid symlink attacks

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13703] Hash collision security issue

[Glenn Linderman]

Glenn Linderman  added the comment:

I don't find a way to delete my prior comment, so I'll add one more 
(only). The prior comment was intended to go to one person, but I didn't 
notice the From, having one person's name, actually went back to the 
ticket (the email address not being for that individual), now I do, so 
I've learned that.

My prior comment was a request for further explanation of things I still 
don't understand, not intended to be an attack.  If someone can delete 
both this and my prior comment from the issue, or tell me how, feel free.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13703] Hash collision security issue

[Christian Heimes]

Christian Heimes  added the comment:

Glenn, you have reached a point where you stop bike-shedding and start to troll 
by attacking people. Please calm down. I'm sure that you are just worried about 
the future of Python and all the bad things, that might be introduced by a fix 
for the issue.

Please trust us! Paul, Victor, Antoine and several more involved developers are 
professional Python devs and have been for years. Most of them do Python 
development for a living. We won't kill the snake that pays our bills. ;) 
Ultimately it's Guido's choice, too. 

Martin:
Ouch, the startup impact is large! Have we reached a point where "one size fits 
all" doesn't work any longer? It's getting harder to have just one executable 
for 500ms scripts and server processes that last for weeks.

Marc-Andre:
Have you profiled your suggestion? I'm interested in the speed implications. My 
gut feeling is that your idea could be slower, since you have added more 
instructions to a tight loop, that is execute on every lookup, insert, update 
and deletion of a dict key. The hash modification could have a smaller impact, 
since the hash is cached. I'm merely speculating here until we have some 
numbers to compare.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13703] Hash collision security issue

[Glenn Linderman]

Glenn Linderman  added the comment:

[offlist]
Paul, thanks for the enumeration and response.  Some folks have more 
experience, but the rest of us need to learn.  Having the proposal in 
the ticket, with an explanation of its deficiencies is not all bad, 
however, others can learn, perhaps.  On the other hand, I'm willing to 
learn more, if you are willing to address my concerns below.

I had read the whole thread and issue, but it still seemed like a leap 
of faith to conclude that the only, or at least best, solution is 
changing the hash.  Yet, changing the hash still doesn't seem like a 
sufficient solution, due to long-lived processes.

On 1/7/2012 6:40 PM, Paul McMillan wrote:
> Paul McMillan  added the comment:
>
>> Alex, I agree the issue has to do with the origin of the data, but the 
>> modules listed are the ones that deal with the data supplied by this 
>> particular attack.
> They deal directly with the data. Do any of them pass the data
> further, or does the data stop with them?

For web forms and requests, which is the claimed vulnerability, I would 
expect that most of them do not pass the data further, without 
validation or selection, and it is unlikely that the form is actually 
expecting data with colliding strings, so it seems very unlikely that 
they would be passed on. At least that is how I code my web apps: just 
select the data I expect from my form.  At present I do not reject data 
I do not expect, but I'll have to consider either using SafeDict (which 
I can start using ASAP, not waiting for a new release of Perl to be 
installed on my Web Server (currently running Perl 2.4), or rejecting 
data I do not expect prior to putting it in a dict.  That might require 
tweaking urllib.parse a bit, or cgi, or both.

> A short and very incomplete
> list of vulnerable standard lib modules includes: every single parsing
> library (json, xml, html, plus all the third party libraries that do
> that), all of numpy (because it processes data which probably came
> from a user [yes, integers can trigger the vulnerability]), difflib,
> the math module, most database adaptors, anything that parses metadata
> (including commonly used third party libs like PIL), the tarfile lib
> along with other compressed format handlers, the csv module,
> robotparser, plistlib, argparse, pretty much everything under the
> heading of "18. Internet Data Handling" (email, mailbox, mimetypes,
> etc.), "19. Structured Markup Processing Tools", "20. Internet
> Protocols and Support", "21. Multimedia Services", "22.
> Internationalization", TKinter, and all the os calls that handle
> filenames. The list is impossibly large, even if we completely ignore
> user code. This MUST be fixed at a language level.
>
> I challenge you to find me 15 standard lib components that are certain
> to never handle user-controlled input.

I do appreciate your enumeration, but I'll decline the challenge.  While 
all of them can be interesting exploits of naïve applications (written 
by programmers who may be quite experienced in some things, but can 
naïvely overlook other things), most of them probably do not apply to 
the documented vulnerability. Many I had thought of, but rejected for 
this context; some I had not.  So while there are many possible 
situations where happily stuffing things into a dict may be an easy 
solution, there are many possible cases where it should be prechecked on 
the way in.  And there is another restriction: if the user-controlled 
input enters a user-run program, it is unlikely to be attacked in the 
same manner than web servers are attacked.  A user, for example, is 
unlikely to contrive colliding file names for the purpose of making his 
file listing program run slow.

So it is really system services and web services that need to be 
particularly careful. Randomizing the hash seed might reduce the problem 
from any system/web services to only long-running system/web services, 
but doesn't really solve the complete problem, as far as I can tell... 
only proper care in writing the application (and the stdlib code) will 
solve the complete problem.  Sadly, beefing up the stdlib code will 
probably reduce performance for things that will not be exploited to be 
careful enough in the cases that could be exploited.

>> Note that changing the hash algorithm for a persistent process, even though 
>> each process may have a different seed or randomized source, allows attacks 
>> for the life of that process, if an attack vector can be created during its 
>> lifetime. This is not a problem for systems where each request is handled by 
>> a different process, but is a problem for systems where processes are 
>> long-running and handle many requests.
> This point has been made many times now. I urge you to read the entire
> thread on the mailing list. Your implementation is impractical because
> your "safe" implementation completely ignores all hash caching (each
> entry must be re-hashed for that dict). Your imple

[issue13734] Add a generic directory walker method to avoid symlink attacks

[Ross Lagerwall]

Ross Lagerwall  added the comment:

> Has there already been done any work? Ross mentioned he wanted to take a stab?

Unfortunately, I'm rather busy at the moment but when I get some free time and 
if no one else wants to work on it then I'll take a look.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12736] Request for python casemapping functions to use full not simple casemaps per Unicode's recommendation

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Here is a patch. I only dealt with case mappings and not titlecase. Doing 
titlecase properly requires word segmentation, which I think should be another 
patch/issue. This patch fixes swapcase(), capitalize(), upper(), and lower(). 
It does not include the changes to Objects/unicodetype_db.h because those are 
huge. Regenerate the database if you want to test it. Please review.

--
keywords: +patch
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file24171/full-casemapping.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13733] Change required to sysconfig.py for Python 2.7.2 on OS/2

[Paul Smedley]

Paul Smedley  added the comment:

I'm building OS/2 python here using configure, etc - without the changes 
attached, python would not complete the build.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13733] Change required to sysconfig.py for Python 2.7.2 on OS/2

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Paul, can you please elaborate on the patch? The original code looks better to 
me than the new code. Why do you think this change is right?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13735] The protocol > 0 of cPickle does not given stable dictionary values

[Kay Hayen]

New submission from Kay Hayen :

Hello,

I am implementing a Python compiler (Nuitka) that is testing if when it 
compiles itself, it gives the same output. 

I have been using "protocol = 0" ever since with "pickle" module for historic 
reasons (gcc bug with raw strings lead me to believe it's better) and lately, I 
have changed to "protocol = 2" and cPickle. But then I noticed that my compile 
itself test now fail to give same code from pickling of dictionary constants.

Imanaged and isolated the issue, and it's a Python2.7 regression, Python2.6 is 
fine:

Observe this output from "cPickle.dumps" for a constant dictionary with one 
element:

Protocol 0 :
Dumping read const const stream "(dp1\nS'modules'\np2\nNs."
Dumping load const const stream "(dp1\nS'modules'\np2\nNs."
Dumping load const const stream "(dp1\nS'modules'\np2\nNs."
Protocol 1 :
Dumping read const const stream '}q\x01U\x07modulesq\x02Ns.'
Dumping load const const stream '}q\x01U\x07modulesNs.'
Dumping load const const stream '}q\x01U\x07modulesNs.'
Protocol 2 :
Dumping read const const stream '\x80\x02}q\x01U\x07modulesq\x02Ns.'
Dumping load const const stream '\x80\x02}q\x01U\x07modulesNs.'
Dumping load const const stream '\x80\x02}q\x01U\x07modulesNs.'

It seems that cPickle as of CPython2.7 does give a better stream for 
dictionaries it itself emitted. With CPython2.6 I observe no difference.

My work-around is to "re-stream", "dumps" -> "loads" -> "dumps" with CPython2.7 
for the time being.

Can you either: Fix cPickle to treat the dictionaries the same, or enhance to 
core to produce the same dict as cPickle does? It appears at least some kind of 
efficiency might be missed out for marshall as well.

--
components: Interpreter Core, Library (Lib)
files: stream.py
messages: 150841
nosy: kayhayen
priority: normal
severity: normal
status: open
title: The protocol > 0 of cPickle does not given stable dictionary values
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24170/stream.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13703] Hash collision security issue

[Paul McMillan]

Paul McMillan  added the comment:

> Alex, I agree the issue has to do with the origin of the data, but the 
> modules listed are the ones that deal with the data supplied by this 
> particular attack.

They deal directly with the data. Do any of them pass the data
further, or does the data stop with them? A short and very incomplete
list of vulnerable standard lib modules includes: every single parsing
library (json, xml, html, plus all the third party libraries that do
that), all of numpy (because it processes data which probably came
from a user [yes, integers can trigger the vulnerability]), difflib,
the math module, most database adaptors, anything that parses metadata
(including commonly used third party libs like PIL), the tarfile lib
along with other compressed format handlers, the csv module,
robotparser, plistlib, argparse, pretty much everything under the
heading of "18. Internet Data Handling" (email, mailbox, mimetypes,
etc.), "19. Structured Markup Processing Tools", "20. Internet
Protocols and Support", "21. Multimedia Services", "22.
Internationalization", TKinter, and all the os calls that handle
filenames. The list is impossibly large, even if we completely ignore
user code. This MUST be fixed at a language level.

I challenge you to find me 15 standard lib components that are certain
to never handle user-controlled input.

> Note that changing the hash algorithm for a persistent process, even though 
> each process may have a different seed or randomized source, allows attacks 
> for the life of that process, if an attack vector can be created during its 
> lifetime. This is not a problem for systems where each request is handled by 
> a different process, but is a problem for systems where processes are 
> long-running and handle many requests.

This point has been made many times now. I urge you to read the entire
thread on the mailing list. Your implementation is impractical because
your "safe" implementation completely ignores all hash caching (each
entry must be re-hashed for that dict). Your implementation is still
vulnerable in exactly the way you mentioned if you ever have any kind
of long-lived dict in your program thread.

> You have entered the class of people that claim lots of vulnerabilities, 
> without enumeration.

I have enumerated. Stop making this argument.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13733] Change required to sysconfig.py for Python 2.7.2 on OS/2

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I think OS/2 portability fixes should probably target 3.3 instead.

--
nosy: +eric.araujo, loewis, pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13734] Add a generic directory walker method to avoid symlink attacks

[Nick Coghlan]

Nick Coghlan  added the comment:

I'm working on a library of general directory walking tools that will hopefully 
make their way back into the stdlib at some point 
(http://walkdir.readthedocs.org).

They're designed to filter and transform the output of os.walk (and similar 
iterators) in various ways.

It may provide a good environment for prototyping a general purpose "tree_map" 
for applying an operation to a filesystem tree without being vulnerable to 
symlink attacks.

--
nosy: +ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13703] Hash collision security issue

[Glenn Linderman]

Glenn Linderman  added the comment:

Alex, I agree the issue has to do with the origin of the data, but the modules 
listed are the ones that deal with the data supplied by this particular attack.

Note that changing the hash algorithm for a persistent process, even though 
each process may have a different seed or randomized source, allows attacks for 
the life of that process, if an attack vector can be created during its 
lifetime. This is not a problem for systems where each request is handled by a 
different process, but is a problem for systems where processes are 
long-running and handle many requests.

Regarding vulnerable user code, supplying SafeDict (or something similar) in 
the stdlib or as sample code for use in such cases allows user code to be fixed 
also.

You have entered the class of people that claim lots of vulnerabilities, 
without enumeration.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13703] Hash collision security issue

[Alex Gaynor]

Alex Gaynor  added the comment:

You're seriously underestimating the number of vulnerable dicts.  It has 
nothing to do with the module, and everything to do with the origin of the 
data.  There's tons of user code that's vulnerable too.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13703] Hash collision security issue

[Glenn Linderman]

Glenn Linderman  added the comment:

Given Martin's comment (msg150832) I guess I should add my suggestion to this 
issue, at least for the record.

Rather than change hash functions, randomization could be added to those dicts 
that are subject to attack by wanting to store user-supplied key values.  The 
list so far seems to be   urllib.parse, cgi, json  Some have claimed there are 
many more, but without enumeration.  These three are clearly related to the 
documented issue.

The technique would be to wrap dict and add a short random prefix to each key 
value, preventing the attacker from supplier keys that are known to collide... 
and even if he successfully stumbles on a set that does collide on one request, 
it is unlikely to collide on a subsequent request with a different prefix 
string.

The technique is fully backward compatible with all applications except those 
that contain potential vulnerabilities as described by the researchers. The 
technique adds no startup or runtime overhead to any application that doesn't 
contain the potential vulnerabilities.  Due to the per-request randomization, 
the complexity of creating a sequence of sets of keys that may collide is 
enormous, and requires that such a set of keys happen to arrive on a request in 
the right sequence where the predicted prefix randomization would be used to 
cause the collisions to occur.  This might be possible on a lightly loaded 
system, but is less likely on a system with heavy load, which are more 
interesting to attack.

Serhiy Storchaka provided a sample implementation on the python-dev, copied 
below, and attached as a file (but is not a patch).

# -*- coding: utf-8 -*-
from collections import MutableMapping
import random


class SafeDict(dict, MutableMapping):

def __init__(self, *args, **kwds):
dict.__init__(self)
self._prefix = str(random.getrandbits(64))
self.update(*args, **kwds)

def clear(self):
dict.clear(self)
self._prefix = str(random.getrandbits(64))

def _safe_key(self, key):
return self._prefix + repr(key), key

def __getitem__(self, key):
try:
return dict.__getitem__(self, self._safe_key(key))
except KeyError as e:
e.args = (key,)
raise e

def __setitem__(self, key, value):
dict.__setitem__(self, self._safe_key(key), value)

def __delitem__(self, key):
try:
dict.__delitem__(self, self._safe_key(key))
except KeyError as e:
e.args = (key,)
raise e

def __iter__(self):
for skey, key in dict.__iter__(self):
yield key

def __contains__(self, key):
return dict.__contains__(self, self._safe_key(key))

setdefault = MutableMapping.setdefault
update = MutableMapping.update
pop = MutableMapping.pop
popitem = MutableMapping.popitem
keys = MutableMapping.keys
values = MutableMapping.values
items = MutableMapping.items

def __repr__(self):
return '{%s}' % ', '.join('%s: %s' % (repr(k), repr(v))
for k, v in self.items())

def copy(self):
return self.__class__(self)

@classmethod
def fromkeys(cls, iterable, value=None):
d = cls()
for key in iterable:
d[key] = value
return d

def __eq__(self, other):
return all(k in other and other[k] == v for k, v in self.items()) and \
all(k in self and self[k] == v for k, v in other.items())

def __ne__(self, other):
return not self == other

--
Added file: http://bugs.python.org/file24169/SafeDict.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13734] Add a generic directory walker method to avoid symlink attacks

[Hynek Schlawack]

New submission from Hynek Schlawack :

This is an offspring of #4489 (which is a security bug). The method is AFAIU 
intended to be private. 

As shown in the discussion of the mentioned #4489, there is a whole family of 
attacks that exploit the time window between gathering path names and executing 
a function on them. A general description of this problem can be found in: 
https://www.securecoding.cert.org/confluence/display/seccode/POS35-C.+Avoid+race+conditions+while+checking+for+the+existence+of+a+symbolic+link

While the consequences in rmtree() are probably most dramatic, other recursive 
functions could benefit too (chmodtree() and chowntree() were mentioned) so 
Charles-François suggested to write a "generic walker method that would take as 
argument the methods to call on a directory and on a file (or link)".

Some (probably) necessary helper functions has been already implemented in 
#4761 (*at()) and #10755 (fdlistdir()).

Has there already been done any work? Ross mentioned he wanted to take a stab?

--
components: Library (Lib)
messages: 150833
nosy: hynek.schlawack, neologix, pitrou, rosslagerwall, tarek
priority: normal
severity: normal
status: open
title: Add a generic directory walker method to avoid symlink attacks
type: security
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4489] shutil.rmtree is vulnerable to a symlink attack

[Hynek Schlawack]

Hynek Schlawack  added the comment:

> > What's the current state here? Anyone working on a solution or are we
> > waiting how http://hg.python.org/features/pathlib/ will work out?
>  
> Well, I am not working on that one, so waiting for it to work out might
> be optimistic :)
> I don't know what to do with it (the pathlib): is such a feature
> desireable enough?

Independently from this bug, I'd say it would be a good thing.

Proof: 
http://twistedmatrix.com/documents/current/api/twisted.python.filepath.html – 
Twisted already implemented something similar for themselves.

> > If the consensus is to add a generic walker method, wouldn't be
> > appropriate to open a new bug and add it as dependency?
>  
> Agreed.

See #13734

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13703] Hash collision security issue

[Martin]

Martin  added the comment:

I built random-2.patch on my windows xp box (updating the project and fixing 
some compile errors in random.c required), and initialising crypto has a 
noticeable impact on startup time. The numbers vary a fair bit naturally, two 
representative runs are as follows:

changeset 52796:1ea8b7233fd7 on default branch:

>timeit %PY3K% -c "import sys;print(sys.version)"
3.3.0a0 (default, Jan  7 2012, 00:12:45) [MSC v.1500 32 bit (Intel)]

Version Number:   Windows NT 5.1 (Build 2600)
Exit Time:0:16 am, Saturday, January 7 2012
Elapsed Time: 0:00:00.218
Process Time: 0:00:00.187
System Calls: 4193
Context Switches: 445
Page Faults:  1886
Bytes Read:   642542
Bytes Written:272
Bytes Other:  31896

with random-2.patch and fixes applied:

>timeit %PY3K% -c "import sys;print(sys.version)"
3.3.0a0 (default, Jan  7 2012, 00:58:32) [MSC v.1500 32 bit (Intel)]

Version Number:   Windows NT 5.1 (Build 2600)
Exit Time:0:59 am, Saturday, January 7 2012
Elapsed Time: 0:00:00.296
Process Time: 0:00:00.234
System Calls: 4712
Context Switches: 642
Page Faults:  2049
Bytes Read:   1059381
Bytes Written:272
Bytes Other:  34544

This is with hot caches, cold will likely be worse, but a smaller percentage 
change. On a faster box, or with an SSD, or win 7, the delta will likely be 
smaller too.

A 50-100ms slow down is consistent with the difference on Python 2.7 between 
calling `os.urandom(1)` or not. However, the baseline is faster with Python 2, 
frequently dipping under 100ms, so there this change could double the runtime 
of trivial scripts.

--
nosy: +gz

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13733] Change required to sysconfig.py for Python 2.7.2 on OS/2

[Paul Smedley]

New submission from Paul Smedley :

Python 2.7.2 fails during compilation on OS/2  with:
 File "./setup.py", line 1154, in detect_modules
   for arg in sysconfig.get_config_var("CONFIG_ARGS").split()]
AttributeError: 'NoneType' object has no attribute 'split'
make: *** [sharedmods] Error 1

Attached diff for sysconfig.py corrects the problem

--
components: Build
files: sysconfig.py.diff
keywords: patch
messages: 150831
nosy: Paul.Smedley
priority: normal
severity: normal
status: open
title: Change required to sysconfig.py for Python 2.7.2 on OS/2
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file24168/sysconfig.py.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13732] test_logging failure on Windows buildbots

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 870f8fdfbada by Vinay Sajip in branch 'default':
Closes #13732: now use os.linesep instead of a literal newline.
http://hg.python.org/cpython/rev/870f8fdfbada

--
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13703] Hash collision security issue

[Tim Peters]

Tim Peters  added the comment:

[Marc-Andre]
> BTW: I wonder how long it's going to take before
> someone figures out that our merge sort based
> list.sort() is vulnerable as well... its worst-
> case performance is O(n log n), making attacks
> somewhat harder.

I wouldn't worry about that, because nobody could stir up anguish
about it by writing a paper ;-)

1. O(n log n) is enormously more forgiving than O(n**2).

2. An attacker need not be clever at all:  O(n log n) is not only
sort()'s worst case, it's also its _expected_ case when fed randomly
ordered data.

3. It's provable that no comparison-based sorting algorithm can have
better worst-case asymptotic behavior when fed randomly ordered data.

So if anyone whines about this, tell 'em to go do something useful instead :-)

--
nosy: +tim_one

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13050] RLock support the context manager protocol but this is not documented

[Raymond Hettinger]

Raymond Hettinger  added the comment:

This edit looks reasonable.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13731] Awkward phrasing in Decimal documentation

[Raymond Hettinger]

Raymond Hettinger  added the comment:

No problem.  Thanks for showing an interest in the quality of the documentation.

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13731] Awkward phrasing in Decimal documentation

[Aaron Maenpaa]

Aaron Maenpaa  added the comment:

I can understand what was meant. You're welcome to close the issue.

Sorry for the nitpick.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13731] Awkward phrasing in Decimal documentation

[Raymond Hettinger]

Raymond Hettinger  added the comment:

If you can't ascertain the meaning of the sentence, I'll consider making a 
change.  Itherwise, this appears to have degenerated into trivial 
micro-wordsmithing and I'll close this as not being worth consuming any more of 
my time.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13050] RLock support the context manager protocol but this is not documented

[Aaron Maenpaa]

Aaron Maenpaa  added the comment:

Here is a patch that adds an note about using Locks, RLocks, Conditions, and 
Semaphores as context managers to each of their descriptions as well as a link 
to the "Using locks, conditions, and semaphores in the with statement" section.

--
keywords: +patch
nosy: +zacherates
versions: +Python 3.3
Added file: http://bugs.python.org/file24167/issue13050.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13731] Awkward phrasing in Decimal documentation

[Aaron Maenpaa]

Aaron Maenpaa  added the comment:

That's fine. I'm not particularly attached to that phrasing.

The one thing I would push for is to add a comma to "... decimal is preferred 
in accounting applications which have strict equality invariants."

... since, as far as I can tell, "which have strict equality invariants" is 
supposed to be a parenthetical statement explaining why accounting applications 
prefer to use decimal arithmetic, rather than a constraints on the preference 
for decimal arithmetic to only those accounting applications that have "strict 
equality invariants".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13728] Description of -m and -c cli options wrong?

[Eric Snow]

Eric Snow  added the comment:

see http://docs.python.org/library/sys.html#sys.path

"As initialized upon program startup, the first item of this list, path[0], is 
the directory containing the script that was used to invoke the Python 
interpreter. If the script directory is not available (e.g. if the interpreter 
is invoked interactively or if the script is read from standard input), path[0] 
is the empty string, which directs Python to search modules in the current 
directory first."

So the empty string here is the current working directory (at the time the 
script is run?).

--
nosy: +eric.snow

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9253] argparse: optional subparsers

[Benjamin West]

Benjamin West  added the comment:

Ok, here's a rough attempt at stubbing this out against a python checkout.  
Will try to look at adding tests.

(BTW, subsequent GETs should not modify the bug tracker... this seems like a 
bug since GET should be idempotent, but SFTN from the double posting.)

--
hgrepos: +100

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9253] argparse: optional subparsers

[Benjamin West]

Benjamin West  added the comment:

Ok, here's a rough attempt at stubbing this out against a python checkout.  
Will try to look at adding tests.

(BTW, subsequent GETs should not modify the bug tracker... this seems like a 
bug since GET should be idempotent, but SFTN from the double posting.)

--
hgrepos: +101

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13731] Awkward phrasing in Decimal documentation

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I'm sorry but I think the current wording is better that your proposed revision.

When I get a chance, I'll revisit it to see if I can find another way to 
improve the text.

--
priority: normal -> low

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13731] Awkward phrasing in Decimal documentation

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee: docs@python -> rhettinger
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13587] Correcting the typos error in Doc/howto/urllib2.rst

[Aaron Maenpaa]

Aaron Maenpaa  added the comment:

Here's a patch that makes the WWW-Authenticate headers in howto/urllib2 agree 
with rfc2617.

--
keywords: +patch
nosy: +zacherates
Added file: http://bugs.python.org/file24166/issue13587.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13732] test_logging failure on Windows buildbots

[Charles-François Natali]

New submission from Charles-François Natali :

Commit 57295c4d81ac879dd2d804190b38b2e91f934acd broke Windows buildbots:

"""
==
ERROR: test_rotator (test.test_logging.RotatingFileHandlerTest)
--
Traceback (most recent call last):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py",
 line 3543, in tearDown
os.unlink(fn)
PermissionError: [Error 32] The process cannot access the file because it is 
being used by another process: 
'c:\\users\\db3l\\appdata\\local\\temp\\test_logging-2-9ozjk9.log'

==
FAIL: test_rotator (test.test_logging.RotatingFileHandlerTest)
--
Traceback (most recent call last):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py",
 line 3631, in test_rotator
self.assertEqual(data.decode("ascii"), m1.msg + "\n")
AssertionError: '1\r\n' != '1\n'
- 1
?  -
+ 1


==
FAIL: test_should_not_rollover (test.test_logging.RotatingFileHandlerTest)
--
Traceback (most recent call last):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py",
 line 3536, in setUp
BaseTest.setUp(self)
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py",
 line 114, in setUp
raise AssertionError('Unexpected handlers: %s' % hlist)
AssertionError: Unexpected handlers: []
"""

See 
http://python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/4180/steps/test/logs/stdio
 and 
http://python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/5780/steps/test/logs/stdio

--
assignee: vinay.sajip
components: Tests
messages: 150817
nosy: neologix, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: test_logging failure on Windows buildbots
type: behavior
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9253] argparse: optional subparsers

[Benjamin West]

Benjamin West  added the comment:

Thanks Eric.  I was thrown by this document: http://wiki.python.org/moin/Git 
which describes fetching the sources from SVN using git.  I'm comfortable doing 
either, but it doesn't resolve my confusion.

The version of argparse in the python checkout is 1.1: 
http://hg.python.org/cpython/file/default/Lib/argparse.py
64 __version__ = '1.1' but differs from the SVN version.

whereas the argparse version available via google code is 1.2.  The diffs 
indicate several changes not related to the change I'm attempting to make, 
which prevent my patch from applying cleanly.  Looks like the HG version 
includes the 1.2 code... but I'm not sure why it would differ from SVN's trunk.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9253] argparse: optional subparsers

[Benjamin West]

Benjamin West  added the comment:

Thanks Eric.  I was thrown by this document: http://wiki.python.org/moin/Git 
which describes fetching the sources from SVN using git.  I'm comfortable doing 
either, but it doesn't resolve my confusion.

The version of argparse in the python checkout is 1.1: 
http://hg.python.org/cpython/file/default/Lib/argparse.py
64 __version__ = '1.1' but differs from the SVN version.

whereas the argparse version available via google code is 1.2.  The diffs 
indicate several changes not related to the change I'm attempting to make, 
which prevent my patch from applying cleanly.  Looks like the HG version 
includes the 1.2 code... but I'm not sure why it would differ from SVN's trunk.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13502] Documentation for Event.wait return value is either wrong or incomplete

[Charles-François Natali]

Changes by Charles-François Natali :


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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13731] Awkward phrasing in Decimal documentation

[Aaron Maenpaa]

New submission from Aaron Maenpaa :

The paragraph: "The exactness carries over into arithmetic. In decimal floating 
point, 0.1 + 0.1 + 0.1 - 0.3 is exactly equal to zero. In binary floating 
point, the result is 5.5511151231257827e-017. While near to zero, the 
differences prevent reliable equality testing and differences can accumulate. 
For this reason, decimal is preferred in accounting applications which have 
strict equality invariants."

... has some awkward phrasing to my ear. I've attached a patch with a proposed 
alternative.

--
assignee: docs@python
components: Documentation
files: rephrase.diff
keywords: patch
messages: 150814
nosy: docs@python, zacherates
priority: normal
severity: normal
status: open
title: Awkward phrasing in Decimal documentation
versions: Python 3.3
Added file: http://bugs.python.org/file24165/rephrase.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13730] Grammar mistake in Decimal documentation

[Aaron Maenpaa]

New submission from Aaron Maenpaa :

In the sentance: "In contrast, numbers like 1.1 and 2.2 do not have an exact 
representations in binary floating point." there is a mismatch in number 
between "an" and "representations". I suggest removing "an" to make the whole 
thing plural.

A patch is attached.

--
assignee: docs@python
components: Documentation
files: plural.diff
keywords: patch
messages: 150813
nosy: docs@python, zacherates
priority: normal
severity: normal
status: open
title: Grammar mistake in Decimal documentation
versions: Python 3.3
Added file: http://bugs.python.org/file24164/plural.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8184] multiprocessing.managers will not fail if listening ocket already in use

[Charles-François Natali]

Charles-François Natali  added the comment:

I noticed that if bind() fails (in this case with EADDRINUSE), the
socket isn't closed (FD leak).
Here's a patch.

--
keywords: +patch
Added file: http://bugs.python.org/file24163/connection_error.diff

___
Python tracker 

___diff --git a/Lib/multiprocessing/connection.py 
b/Lib/multiprocessing/connection.py
--- a/Lib/multiprocessing/connection.py
+++ b/Lib/multiprocessing/connection.py
@@ -575,10 +575,14 @@
 '''
 def __init__(self, address, family, backlog=1):
 self._socket = socket.socket(getattr(socket, family))
-self._socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
-self._socket.bind(address)
-self._socket.listen(backlog)
-self._address = self._socket.getsockname()
+try:
+self._socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
+self._socket.bind(address)
+self._socket.listen(backlog)
+self._address = self._socket.getsockname()
+except OSError:
+self._socket.close()
+raise
 self._family = family
 self._last_accepted = None
 
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12005] modulo result of Decimal differs from float/int

[Aaron Maenpaa]

Aaron Maenpaa  added the comment:

Here is a patch that adds an explination for the difference in the behaviour to 
the FAQ section of the Decimal documentation.

--
keywords: +patch
nosy: +zacherates
Added file: http://bugs.python.org/file24162/issue12005.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4489] shutil.rmtree is vulnerable to a symlink attack

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> What's the current state here? Anyone working on a solution or are we
> waiting how http://hg.python.org/features/pathlib/ will work out?

Well, I am not working on that one, so waiting for it to work out might
be optimistic :)
I don't know what to do with it (the pathlib): is such a feature
desireable enough?

> If the consensus is to add a generic walker method, wouldn't be
> appropriate to open a new bug and add it as dependency?

Agreed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13502] Documentation for Event.wait return value is either wrong or incomplete

[Roundup Robot]

Roundup Robot  added the comment:

New changeset eb39d862a250 by Charles-François Natali in branch '3.2':
Issue #13502: threading: Fix a race condition in Event.wait() that made it
http://hg.python.org/cpython/rev/eb39d862a250

New changeset 0fe63bb20e74 by Charles-François Natali in branch 'default':
Issue #13502: threading: Fix a race condition in Event.wait() that made it
http://hg.python.org/cpython/rev/0fe63bb20e74

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13666] datetime documentation typos

[Stephen Kelly]

Stephen Kelly  added the comment:

Patch looks good to me.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13666] datetime documentation typos

[Aaron Maenpaa]

Aaron Maenpaa  added the comment:

Looks like the issue of the first line of utcoffsect was also raised in issue 
8810.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13666] datetime documentation typos

[Aaron Maenpaa]

Aaron Maenpaa  added the comment:

This patch fixes the rzinfo typo as well as the GMT2 issue (GMT +2 should 
behave exactly the same as GMT +1 with regards to DST, it's base offset should 
simply be +2 hours instead of +1).

This does not; however, address the comment about the first line of the 
tzinfo.utcoffset(). The fact that tzinfo.utcoffset() should return a timedelta 
or None is addressed later in the same paragraph, as such I'm not sure the 
proposed change is an improvement.

--
keywords: +patch
nosy: +zacherates
Added file: http://bugs.python.org/file24161/issue13666.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13609] Add "os.get_terminal_size()" function

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13550] Rewrite logging hack of the threading module

[Éric Araujo]

Éric Araujo  added the comment:

haypo’s threading_note_global looks good to me.  The only thing I’m not sure 
about is the signature change from X(verbose, *args, **kwargs) to X(*args, 
**kwargs): is it okay?

(BTW you probably want to delete the obsolete reference to ihooks in a comment 
before committing.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13729] Evaluation order for dics key/value

[Sandro Tosi]

New submission from Sandro Tosi :

Hello, following up 
http://mail.python.org/pipermail/docs/2011-December/006782.html , I'm opening 
this issue to have others confirmation of what's happening:

echo -e "def ev(r):\nprint(r)\nreturn r\n\n{ev(1): ev(2), ev(3): 
ev(4)}" | ./python 
2
1
4
3

(this applies for 2.7/3.2/default) so it seems the value expressions are 
evaluated before the key expressions, so the

{expr1: expr2, expr3: expr4}

in http://docs.python.org/reference/expressions.html#evaluation-order has to be 
updated in

{expr2: expr1, expr4: expr3}

Is that correct/can someone confirm this is the expected behavior?

--
assignee: docs@python
components: Documentation
messages: 150804
nosy: docs@python, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: Evaluation order for dics key/value
versions: Python 2.7, Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13550] Rewrite logging hack of the threading module

[Charles-François Natali]

Charles-François Natali  added the comment:

Alright, Nick agreed on python-dev to remove the logging hack.

--
nosy: +ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13692] 2to3 mangles from . import frobnitz

[Benjamin Peterson]

Changes by Benjamin Peterson :


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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12989] Consistently handle path separator in Py_GetPath on Windows

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13728] Description of -m and -c cli options wrong?

[Sandro Tosi]

New submission from Sandro Tosi :

Hi,
looking at http://mail.python.org/pipermail/docs/2011-December/006672.html I 
tried to replicate what the user said, and *it seems* that -c and -m doesn't 
add the current directory to the start of sys.path:

$ echo -e "import sys\nprint (sys.path)" > dummy.py ; ./python -mdummy
['', '/usr/local/lib/python27.zip', '/home/morph/cpython/py27/Lib', 
'/home/morph/cpython/py27/Lib/plat-linux2', 
'/home/morph/cpython/py27/Lib/lib-tk', '/home/morph/cpython/py27/Lib/lib-old', 
'/home/morph/cpython/py27/build/lib.linux-x86_64-2.7-pydebug', 
'/usr/local/lib/python2.7/site-packages']

and 

$ ./python -c "import dummy"
['', '/usr/local/lib/python27.zip', '/home/morph/cpython/py27/Lib', 
'/home/morph/cpython/py27/Lib/plat-linux2', 
'/home/morph/cpython/py27/Lib/lib-tk', '/home/morph/cpython/py27/Lib/lib-old', 
'/home/morph/cpython/py27/build/lib.linux-x86_64-2.7-pydebug', 
'/usr/local/lib/python2.7/site-packages']

the same sys.path as from the interactive shell:

$ ./python 
Python 2.7.2+ (2.7:f0666e56a552, Jan  7 2012, 16:31:06) 
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
[38650 refs]
>>> sys.path
['', '/usr/local/lib/python27.zip', '/home/morph/cpython/py27/Lib', 
'/home/morph/cpython/py27/Lib/plat-linux2', 
'/home/morph/cpython/py27/Lib/lib-tk', '/home/morph/cpython/py27/Lib/lib-old', 
'/home/morph/cpython/py27/build/lib.linux-x86_64-2.7-pydebug', 
'/usr/local/lib/python2.7/site-packages']
[38657 refs]

So, is http://docs.python.org/using/cmdline.html#interface-options correct in 
saying "he current directory will be added to the start of sys.path (allowing 
modules in that directory to be imported as top level modules)."? (and so forth 
for -m option?) am I confused?

--
assignee: docs@python
components: Documentation
messages: 150802
nosy: docs@python, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: Description of -m and -c cli options wrong?
versions: Python 2.7, Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13716] distutils doc contains lots of XXX

[Florent Xicluna]

Florent Xicluna  added the comment:

The proposed solution is ok.

It sounds like unfinished documentation when you hit an "XXX".
For the "/dev/" documentation, it's OK, but for the released version, we should 
avoid it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13716] distutils doc contains lots of XXX

[Georg Brandl]

Georg Brandl  added the comment:

Agreed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13691] pydoc help (or help('help')) claims to run a help utility; does nothing

[Éric Araujo]

Éric Araujo  added the comment:

I’m interested in this, so I’m taking assignment.  If a contributor is 
interested in making a patch I’ll review it, otherwise I’ll say when I start on 
a patch.

--
assignee:  -> eric.araujo
keywords: +easy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13716] distutils doc contains lots of XXX

[Éric Araujo]

Éric Araujo  added the comment:

These are the XXX:

  XXX true? does ANSI say anything about this?
  XXX defaults to what?
  XXX see also.
  XXX see also.
  XXX see also.
  XXX see also.
  XXX see also.

The first two are questions that can be answered, and when I research them for 
the packaging docs I could also backport the changes to the distutils docs; 
what to do for the other instances is less clear, so just deleting may be 
better than turning them into comments that will never get solved.

--
assignee: docs@python -> eric.araujo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13692] 2to3 mangles from . import frobnitz

[Éric Araujo]

Éric Araujo  added the comment:

Thanks for the report, but 3.1 does not get bug fixes any more.  Maybe Benjamin 
would like to add a regression test for this, so I’m leaving the decision to 
close this report to him.

--
nosy: +benjamin.peterson, eric.araujo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13727] Accessor macros for PyDateTime_Delta members

[Amaury Forgeot d'Arc]

New submission from Amaury Forgeot d'Arc :

All objects of the datetime module have macros to access their properties, 
except timedelta.
This simple patch adds the macros PyDateTime_DELTA_GET_DAYS, 
PyDateTime_DELTA_GET_SECONDS, PyDateTime_DELTA_GET_MICROSECONDS; module 
developers are encouraged to use these instead of obj->seconds for example.

Motivation:
PyPy cannot easily expose PyDateTime_Delta fields because datetime is 
implemented as a pure Python module and it's difficult to rebuild a C structure 
from a heap type.
In PyPy these macros are actually functions, which do something similar to 
PyLong_AsLong(PyObject_GetAttrString(obj, "seconds")):
https://bitbucket.org/pypy/pypy/src/b67e65d709e1/pypy/module/cpyext/cdatetime.py#cl-235

--
files: timedelta_macros.patch
keywords: patch
messages: 150796
nosy: amaury.forgeotdarc
priority: normal
severity: normal
stage: patch review
status: open
title: Accessor macros for PyDateTime_Delta members
versions: Python 3.3
Added file: http://bugs.python.org/file24160/timedelta_macros.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13703] Hash collision security issue

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Paul McMillan wrote:
> 
>> I'll upload a patch that demonstrates the collisions counting
>> strategy to show that detecting the problem is easy. Whether
>> just raising an exception is a good idea, is another issue.
> 
> I'm in cautious agreement that collision counting is a better
> strategy. The dict implementation performance would suffer from
> randomization.
> 
>> The dict implementation could then alter the hash parameter
>> and recreate the dict table in case the number of collisions
>> exceeds a certain limit, thereby actively taking action
>> instead of just relying on randomness solving the issue in
>> most cases.
> 
> This is clever. You basically neuter the attack as you notice it but
> everything else is business as usual. I'm concerned that this may end
> up being costly in some edge cases (e.g. look up how many collisions
> it takes to force the recreation, and then aim for just that many
> collisions many times). Unfortunately, each dict object has to
> discover for itself that it's full of offending hashes. Another
> approach would be to neuter the offending object by changing its hash,
> but this would require either returning multiple values, or fixing up
> existing dictionaries, neither of which seems feasible.

I ran some experiments with the collision counting patch and
could not trigger it in normal applications, not even in cases
that are documented in the dict implementation to have a poor
collision resolution behavior (integers with zeros the the low bits).
The probability of having to deal with dictionaries that create
over a thousand collisions for one of the key objects in a
real life application appears to be very very low.

Still, it may cause problems with existing applications for the
Python dot releases, so it's probably safer to add it in a
disabled-per-default form there (using an environment variable
to adjust the setting). For 3.3 it could be enabled per default
and it would also make sense to allow customizing the limit
using a sys module setting.

The idea with adding a parameter to the hash method/slot in order
to have objects provide a hash family function instead of a fixed
unparametrized hash function would probably have to be implemented
as additional hash method, e.g. .__uhash__() and tp_uhash ("u"
for universal).

The builtin types should then grow such methods
in order to make hashing safe against such attacks. For objects
defined in 3rd party extensions, we would need to encourage
implementing the slot/method as well. If it's not implemented,
the dict implementation would have to fallback to raising an
exception.

Please note that I'm just sketching things here. I don't have
time to work on a full-blown patch, just wanted to show what
I meant with the collision counting idea and demonstrate that
it actually works as intended.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4489] shutil.rmtree is vulnerable to a symlink attack

[Hynek Schlawack]

Hynek Schlawack  added the comment:

What's the current state here? Anyone working on a solution or are we waiting 
how http://hg.python.org/features/pathlib/ will work out?

If the consensus is to add a generic walker method, wouldn't be appropriate to 
open a new bug and add it as dependency? Or is there one I've missed?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13716] distutils doc contains lots of XXX

[Georg Brandl]

Georg Brandl  added the comment:

I would make comments out of the XXX, and if a whole section is just that XXX, 
remove the section as well.

--
nosy: +georg.brandl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13726] regrtest ambiguous -S flag

[Erno Tukia]

New submission from Erno Tukia :

./python -m test --help
-S/--slow   -- print the slowest 10 tests

-S is used to continue running tests after an aborted run.  It will
maintain the order a standard run (ie, this assumes -r is not used).
This is useful after the tests have prematurely stopped for some external
reason and you want to start running from where you left off rather
than starting from the beginning.

in Lib/test/regrtest.py

opts, args = getopt.getopt(sys.argv[1:], '...S...',
[..., 'slow', ... , 'start=', ...])

for o, a in opts:
elif o in ('-S', '--start'):
start = a
elif o in ('-S', '--slow'):
print_slow = True

At the moment -S (no args) and --slow (no args) are the same, not what the 
documentation says and not how the code executes (-S goes with --start). Help 
says nothing about --start.

--slow or --start needs a new short opt, and corrected documentation.

--
assignee: docs@python
components: Documentation, Tests
messages: 150792
nosy: docs@python, etukia
priority: normal
severity: normal
status: open
title: regrtest ambiguous -S flag
type: behavior
versions: Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13033] Add shutil.chowntree

[Nick Coghlan]

Nick Coghlan  added the comment:

I believe the current "check_chown" could be passed by a no-op (since the file 
will be owned by the current user even *before* the call to chowntree). Testing 
this properly is actually rather difficult (since the only uid and gid we can 
rely on are those of the current process).

More significantly, I don't agree with the proposed error handling (i.e. 
attempting to roll back to the original state). Instead, I think it would be 
more appropriate to follow the rmtree ignore_errors/onerror style so that uses 
can either unconditionally ignore errors (including dir listing errors) or else 
tailor the error handling themselves. Any custom error handling should also 
cover the actual chown operation, not just directory listing errors inside 
os.walk.

I think, like walkdir itself, there's enough under the hood here that the idea 
requires some baking time outside the standard library. How do you feel about 
migrating this discussion over to the walkdir issue tracker as a higher level 
API proposal there? (https://bitbucket.org/ncoghlan/walkdir/issues).

I had a couple of other minor comments, although they're largely irrelevant 
given the more significant comments above:

There's a gratuitous inconsistency in the type-checking for uid/gid (one uses 
"isinstance(uid, str)", the other "not isinstance(gid, int)". Neither is a 
particular good check for the "None, integer or string" case anyway. It would 
be better to just try the following in order:

- "is None"
- operator.index
- _get_uid/gid (as appropriate)

The dict initialisation and error handler definition may as well move inside 
the if statement.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13725] regrtest does not recognize -d flag

[Erno Tukia]

New submission from Erno Tukia :

./python -m test --help
-d/--debug  -- print traceback for failed tests

./python -m test -d test_imaplib
option -d not recognized
Use --help for usage

Patch included.

--
components: Tests
files: regrtest-debug.patch
keywords: patch
messages: 150790
nosy: etukia
priority: normal
severity: normal
status: open
title: regrtest does not recognize -d flag
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24159/regrtest-debug.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13720] argparse print_help() fails if COLUMNS is set to a low value

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Now I get error, even with Window actually about 100 columns wide.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13724] socket.create_connection and multiple IP addresses

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
nosy: +giampaolo.rodola

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13511] Specifying multiple lib and include directories on linux

[Ronald Oussoren]

Ronald Oussoren  added the comment:

He's probably referring to this fragment in setup.py:


if platform == 'darwin':
# This should work on any unixy platform ;-)
# If the user has bothered specifying additional -I and -L flags
# in OPT and LDFLAGS we might as well use them here.
#   NOTE: using shlex.split would technically be more correct, but
# also gives a bootstrap problem. Let's hope nobody uses directories
# with whitespace in the name to store libraries.
cflags, ldflags = sysconfig.get_config_vars(
'CFLAGS', 'LDFLAGS')
for item in cflags.split():
if item.startswith('-I'):
inc_dirs.append(item[2:])
for item in ldflags.split():
if item.startswith('-L'):
lib_dirs.append(item[2:])


The entire block was added when I worked on the Mac port with Jack Jansen.  It 
ensures that additional include and lib directories specified through the 'OPT' 
and 'LDFLAGS' shell variables get added to the search path used by distutils.

As the comment says this should be safe all unity platforms, not just OSX.  
IIRC the platform test is there because we couldn't easily test on other 
platforms and didn't want to accidentally break stuff (this was before we had a 
good buildbot setup).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13720] argparse print_help() fails if COLUMNS is set to a low value

[Zbyszek Szmek]

Zbyszek Szmek  added the comment:

> I am not setting columns, so that might be the important difference.
Yeah, the whole example with IDLE is moot: argparse only checks
$COLUMNS and defaults to 80, so if COLUMNS is not set, you are only
checking if the code works with 80 columns.

Please try my commandline example or set os.environ['COLUMNS'] = 15.
I get the exception in IDLE too.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13720] argparse print_help() fails if COLUMNS is set to a low value

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I am not setting columns, so that might be the important difference.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13720] argparse print_help() fails if COLUMNS is set to a low value

[Zbyszek Szmek]

Zbyszek Szmek  added the comment:

> What system and version are you running? 
Linux (debian amd64), Python is compiled from hg (1ea8b7233fd7).

> The error directly comes from textwrap. In the other hand, 
> textwrap.wrap works with widths down to 1 (on 3.2.2), which suggests 
> that argparse is calling it wrong. Except that it is not on my system. 
That's really surprising, because it is all pure Python code and don't
really see how it _could_ be right: take $COLUMNS, subtract, subtract,
and sooner or later _width will go below 0.

> Could you add 'print(width)' before the call to textwrap
> return _textwrap.wrap(text, width)
> to see if -1 is being passed?
Prints -1.

> The code works fine on 3.2.2, Win7, IDLE, narrowest window possible (about 14 
> chars), which actually wraps to the window width. 
Oh, I just tried it in IDLE and it prints:
  64
  64
  64
  64
  usage: ...
in a very small window (30 cells wide). So IDLE is just doesn't allow you to
go below a certain size.

See also #13107.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com