[issue14532] multiprocessing module performs a time-dependent hmac comparison

[Charles-François Natali]

Changes by Charles-François Natali :


--
nosy: +haypo
status: open -> 

___
Python tracker 

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

[issue14532] multiprocessing module performs a time-dependent hmac comparison

[Charles-François Natali]

Changes by Charles-François Natali :


--
status:  -> open

___
Python tracker 

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

[issue14532] multiprocessing module performs a time-dependent hmac comparison

[STINNER Victor]

STINNER Victor  added the comment:

if response == digest:
can be replaced by:
if sum(x^y for x, y in itertools.zip_longest(response, digest,
fillvalue=256)) == 0:

I hope that zip_longest() does not depend too much on response and digest.

--

___
Python tracker 

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

[issue8799] Hang in lib/test/test_threading.py

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

A few comments:
1)
   with cv:
   make_an_item_available()
+   cv.notify()

2) one of the benefits of wait_for() is that it automates the tricky 
timekeeping needed if one wants an somewhat accurate timeout, you may want to 
mention this specifically.

3) the offending part.  I see that you don't want to use the technical terms of 
spurious wakeups or stolen wakeups. That's ok, but the resulting explanation is 
somwhat bogus.  I suggest the following:

The ``while`` loop checking for the application's condition is necessary
because :meth:`~Condition.wait` can return after an arbitrary long time, and 
the condition which prompted the :meth:`~Condition.notify` call may not yet, or 
no longer, hold true.  This is an inherent property of multi-threaded 
programming and the use of this pattern is essential for the robust use of 
Condition objects.

--

___
Python tracker 

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

[issue14545] html module should not be available in Python 3.1

[Chris Jerdonek]

Chris Jerdonek  added the comment:

Ezio, I appreciate the suggestion/tip.  Thanks.

Regarding Georg's clarification that '"html" is a package,' I don't know if 
that was intended to correct my comment, Ezio's comment, the docs, or all of 
the above.  In any case, that point should also be corrected in the docs as the 
docs currently say about html, "This *module* defines utilities to manipulate 
HTML."

--

___
Python tracker 

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

[issue10484] http.server.is_cgi fails to handle CGI URLs containing PATH_INFO

[Glenn Linderman]

Glenn Linderman  added the comment:

I note that there is no test for tail_part == '.'.  I suggest adding a couple, 
such as the following which I added to my local copy for testing of the next 
item:

'/a/b/.': ('/a/b', ''),
'/a/b/c/../d/e/../../../../f/../.': ('/', ''),

Given your comment that you found bugs in my code, I figured out how to run the 
tests against my code, and found the bugs. Here is a slightly shorter, more 
efficient (it cuts 40% off the execution time, see time_test.py), and to me 
much clearer version of _url_collapse_path_split, and it passes all the tests:

def _url_collapse_path_split(path):
# Similar to os.path.split(os.path.normpath(path)) but specific to URL
# path semantics rather than local operating system semantics.
path_parts = path.split('/')
head_parts = []
for part in path_parts[:-1]:
if part == '..':
head_parts.pop() # IndexError if more '..' than prior parts
elif part and part != '.':
head_parts.append( part )
if path_parts:
tail_part = path_parts.pop()
if tail_part:
if tail_part == '..':
head_parts.pop()
tail_part = ''
elif tail_part == '.':
tail_part = ''
else:
tail_part = ''
return ('/' + '/'.join(head_parts), tail_part)

--
Added file: http://bugs.python.org/file25175/time_test.py

___
Python tracker 

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

[issue14545] html module should not be available in Python 3.1

[Georg Brandl]

Georg Brandl  added the comment:

The comment that "html" was a package was not meant as a correction, but as an 
explanation why it already exists previous to its status as an official 
"module" in 3.2. No correction to "package"is needed.

--

___
Python tracker 

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

[issue8799] Hang in lib/test/test_threading.py

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> A few comments:
> 1)
>with cv:
>make_an_item_available()
> +   cv.notify()

Did I forget this? Ow.

> 2) one of the benefits of wait_for() is that it automates the tricky
> timekeeping needed if one wants an somewhat accurate timeout, you may
> want to mention this specifically.

Ok.

> 3) the offending part.  I see that you don't want to use the technical
> terms of spurious wakeups or stolen wakeups. That's ok, but the
> resulting explanation is somwhat bogus.  I suggest the following:
> 
> The ``while`` loop checking for the application's condition is
> necessary
> because :meth:`~Condition.wait` can return after an arbitrary long
> time, and the condition which prompted the :meth:`~Condition.notify`
> call may not yet, or no longer, hold true.  This is an inherent
> property of multi-threaded programming and the use of this pattern is
> essential for the robust use of Condition objects.

But, once again, "the condition may not yet hold true" is false.
However, the rest of the suggestion looks good, thanks.

--

___
Python tracker 

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

[issue14387] Include\accu.h incompatible with Windows.h

[Roundup Robot]

Roundup Robot  added the comment:

New changeset f91ecbc8bafc by Kristján Valur Jónsson in branch '3.2':
Issue #14387 : undefine 'small' so that it doesn't clash with Windows headers.
http://hg.python.org/cpython/rev/f91ecbc8bafc

--

___
Python tracker 

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

[issue8799] Hang in lib/test/test_threading.py

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

> But, once again, "the condition may not yet hold true" is false.
In our current implementation, yes.  But it is intentionally left undefined in 
the specification of the condition variable protocol, for very good reasons.
While I'm fine with not mentioning it in the docs, I would be very much against 
us actually specifying the opposite (that early wakeups never occur) because 
this will unnecessarily limit our options.  Since the while() loop pattern is 
already recommended because of the "stolen wakeup" problem, leaving the 
"early/spurious" wakeup behaviour" undefined is wise, since there is nothing to 
be gained by actually guaranteeing that there will be no early wakeups.  This 
is just good software engineering practice.

This is also why we, IMHO, shouldn't rely on this behaviour in the unittests.  
One should never write tests that depend on unspecified behaviour, again, good 
engineering practice.

--

___
Python tracker 

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

[issue8799] Hang in lib/test/test_threading.py

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Le mercredi 11 avril 2012 à 10:50 +, Kristján Valur Jónsson a
écrit :
> > But, once again, "the condition may not yet hold true" is false.
> In our current implementation, yes.  But it is intentionally left
> undefined in the specification of the condition variable protocol, for
> very good reasons.

No, it is not "left undefined". If the documentation doesn't say
spurious wakeups may occur, then they are not supposed to occur.
Predictable behaviour is a good thing for users.

> While I'm fine with not mentioning it in the docs, I would be very
> much against us actually specifying the opposite (that early wakeups
> never occur) because this will unnecessarily limit our options.

Which options?

> This is also why we, IMHO, shouldn't rely on this behaviour in the
> unittests.

Disagreed. Unit tests should definitely protect against the introduction
of bugs (willingly or not). And unpredictable behaviour is usually
considered a bug.

If you think the condition variable specification should be changed, you
can always ask for approval on python-dev. But I don't even see the
point: you are not demonstrating any *practical* advantage in doing so.

--

___
Python tracker 

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

[issue8536] Support new features of ZLIB 1.2.4

[Martin v . Löwis]

Changes by Martin v. Löwis :


--
keywords:  -easy

___
Python tracker 

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

[issue1522400] irda socket support

[Martin v . Löwis]

Changes by Martin v. Löwis :


--
stage: needs patch -> patch review

___
Python tracker 

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

[issue14532] multiprocessing module performs a time-dependent hmac comparison

[Charles-François Natali]

Charles-François Natali  added the comment:

> if response == digest:
> can be replaced by:
>    if sum(x^y for x, y in itertools.zip_longest(response, digest,
> fillvalue=256)) == 0:

Yeah, sure, but is it useful at all?
The digest changes at every connection attempt, so this should not be
exploitable.

--

___
Python tracker 

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

[issue8799] Hang in lib/test/test_threading.py

[Charles-François Natali]

Charles-François Natali  added the comment:

[...]
> Disagreed. Unit tests should definitely protect against the introduction
> of bugs (willingly or not). And unpredictable behaviour is usually
> considered a bug.
>
> If you think the condition variable specification should be changed, you
> can always ask for approval on python-dev. But I don't even see the
> point: you are not demonstrating any *practical* advantage in doing so.

One can imagine, for example, that another implementation (or maybe
CPython in a later version) exposes native condition variables on
POSIX, instead of emulating them (e.g. what happended for TLS
implementation).
In that case, we could get spurious wakeups, and code not designed to
cope with them would break.

--

___
Python tracker 

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

[issue8799] Hang in lib/test/test_threading.py

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Le mercredi 11 avril 2012 à 11:32 +, Charles-François Natali a
écrit :
> One can imagine, for example, that another implementation (or maybe
> CPython in a later version) exposes native condition variables on
> POSIX, instead of emulating them (e.g. what happended for TLS
> implementation).

That's right, but spurious wakeups would be a good argument against
accepting such an implementation. Or that implementation should be fixed
to avoid them.

That said, we couldn't use the POSIX implementation anyway, since our
API allows the user to choose the type of lock, while POSIX AFAICT would
only accept a POSIX mutex (which doesn't have the same semantics as an
arbitrary Python lock).

--

___
Python tracker 

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

[issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express

[Yap Sok Ann]

Yap Sok Ann  added the comment:

On 64-bit Windows with Visual Studio 2008 Professional, I also need to apply 
vcvars4.diff to avoid getting the ValueError. Is this something to be expected?

--
nosy: +sayap

___
Python tracker 

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

[issue14432] Bug in generator if the generator in created in a C thread

[Mark Shannon]

Mark Shannon  added the comment:

Rather than ensuring that f_tstate always points to the current frame,
just remove it altogether.

Patch attached

--
nosy: +Mark.Shannon
Added file: http://bugs.python.org/file25176/remove_f_tstate.patch

___
Python tracker 

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

[issue14542] reverse() doesn't reverse sort correctly

[Bill Jefferson]

Bill Jefferson  added the comment:

Eric.
Thanks for answering, but I don't understand the difference between "reversing 
a list" and "reversing it's current values". If I have a list containing 
elements: A, B, C, D and reverse the list's current values, I get: D, C, B, A, 
which is the same as reversing the list. Please explain in more detail. Perhaps 
you can recommend good reference material. Since sort() sorts a list ascending 
(and works correctly), shouldn't reverse() sort the list descending? Am I using 
the wrong function?  I have attached my program:
Bill.

#EX38.PY Get listing of all files in a directory
#http://stackoverflow.com/questions/237079/how-to-get-file-creation-modification-date-times-in-python
# Answer 37
import os, datetime
topDir = "C:/BrcmCDs"
dateFirst = True # put dates before file names
# DateFirst = False # put file names before dates

def modDate(fileN): # returns a 10-place date string
    t = os.path.getmtime(directory+"/"+fileN)
    return str(datetime.datetime.fromtimestamp(t))[0:10]
    
for directory, dirnames, filenames in os.walk(topDir):
    outList = []
    print "Directory: ", directory
    print

    for fileA in filenames:
    if (fileA[0:10] == "B57IBMCD_T" and
    fileA[-4:] == ".zip"):

    dateString = modDate(fileA)
    if dateFirst:
   fileString = dateString + " " + fileA
    else:
   fileString = fileA + " " + dateString
    
    outList.append(fileString)
    
outList.sort() # sort the file list, ascending
# outList.reverse() # reverse the file list, desending
    
print outList #show all files

# now save list to a file:
# https://bbs.archlinux.org/viewtopic.php?id=75839
f = open("fileList.TXT", "w")
f.write("\n".join(map(lambda x: str(x), outList))) 
f.close()

 
Regards from:
William Jefferson Photography
514 Daniels St., #211
Raleigh, NC 27605
Cell Phone: (919) 931-6681
EMail: shagge...@yahoo.com
Brides & Weddings: http://www.WilliamJeffersonPhotography.com
Special Events: http://www.DancingLight.org


 From: Eric V. Smith 
To: shagge...@yahoo.com 
Sent: Tuesday, April 10, 2012 5:45 PM
Subject: [issue14542] reverse() doesn't reverse sort correctly

Eric V. Smith  added the comment:

list.reverse() does not reverse a list, it reverses its current values.

Help on built-in function reverse:

reverse(...)
    L.reverse() -- reverse *IN PLACE*

>>>

--
nosy: +eric.smith
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___

--

___
Python tracker 

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

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

[Mark Shannon]

Mark Shannon  added the comment:

According to PEP 384 (Defining a Stable ABI) the thread state object is opaque, 
so we should be free to add or remove fields.

Nevertheless, I have added a new patch that simply moves the f_exc... fields 
from the frame object to the generator. It is not as efficient as the first 
patch, but at least it moves fields relevant only to generators into the 
generator object.

--
Added file: http://bugs.python.org/file25177/exc_info2.patch

___
Python tracker 

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

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> According to PEP 384 (Defining a Stable ABI) the thread state object
> is opaque, so we should be free to add or remove fields.

Mmh, be aware the stable ABI is only a restricted part of the official
API. There are APIs which are not part of the stable ABI, but are still
public and officially supported.

That said, I agree the thread state *structure* shouldn't be part of the
official API. If necessary, we can provide accessors for some of its
members.

--

___
Python tracker 

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

[issue14542] reverse() doesn't reverse sort correctly

[Mark Dickinson]

Mark Dickinson  added the comment:

Bill,

list.reverse doesn't do any *sorting* at all;  it merely *reverses* the list 
contents.

>>> x = [1, 3, 4, 2]
>>> x.reverse()
>>> x
[2, 4, 3, 1]

If you want to do a reverse sort, you can either first sort normally and then 
reverse the result, or (easier) use the 'reverse' keyword argument to the 
list.sort method, as follows:

>>> x = [1, 3, 4, 2]
>>> x.sort(reverse=True)
>>> x
[4, 3, 2, 1]

I suspect Eric meant to write "does not reverse sort" instead of "does not 
reverse".

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue14452] SysLogHandler sends invalid messages when using unicode

[Vinay Sajip]

Vinay Sajip  added the comment:

I have a possible suggestion about how to resolve this issue:

The SysLogHandler will not do BOM insertion unless the message is Unicode. If 
it is Unicode, it will add the attribute 'UTF8BOM' to the LogRecord, with the 
value u'\ufeff'. The record will then be formatted; if the format string 
contains the UTF8BOM placeholder, it will be replaced with the value u'\ufeff', 
which, when encoded, results in the UTF-8 BOM value '\xef\xbb\xbf'. The user of 
the format string is responsible for ensuring that:

1. If there's no UTF8BOM placeholder in the format string, everything in the 
formatted result must always encode to plain ASCII when encoded using UTF-8.

2. If there is a UTF8BOM placeholder in the format string, everything in the 
formatted result prior to the placeholder must always encode to plain ASCII 
when encoded using UTF-8. The stuff following can, of course, be free of that 
restriction.

3. The end result of encoding should be a prefix which is bytes of pure ASCII, 
then the BOM (if the placeholder is present in the format string), then bytes 
of UTF-8 encoded Unicode.

In any case, a Unicode string will be encoded using UTF-8. If no UTF8BOM 
placeholder was present, no BOM will be; the message can be considered to just 
be a set of octets, which just happens to be UTF-8 encoded Unicode. If the 
placeholder was present, the BOM should appear at the appropriate place to 
comply with RFC 5424.

On 3.2, the message will always be Unicode, and the above processing will take 
place (whereas on 2.x it will be conditional on the type of the formatted 
message string being Unicode).

This seems to provide a resolution to the issue which can be solved without API 
changes, and with changes to the format string if BOM insertion is needed. With 
no UTF8BOM placeholder, the BOM will simply not be inserted. Can you comment on 
this suggestion?

--

___
Python tracker 

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

[issue14542] reverse() doesn't reverse sort correctly

[Eric V. Smith]

Eric V. Smith  added the comment:

Thanks, Mark.

Indeed, my answer as written is meaningless. I meant it doesn't sort in 
reverse, it just reverses.

--

___
Python tracker 

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

[issue1522400] irda socket support

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +neologix

___
Python tracker 

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

[issue14532] multiprocessing module performs a time-dependent hmac comparison

[Jon Oberheide]

Jon Oberheide  added the comment:

In fact, it'd probably be useful to have a time_independenct_comparison() 
helper function somewhere in general.

--

___
Python tracker 

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

[issue14532] multiprocessing module performs a time-dependent hmac comparison

[Jon Oberheide]

Jon Oberheide  added the comment:

Ah yeah, I suppose it's not be exploitable in this case due to the challenge 
nonce.

However, it might still be a good thing to fix for to set an example for other 
hmac module users (internal or external) that might not have the same situation.

--

___
Python tracker 

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

[issue14532] multiprocessing module performs a time-dependent hmac comparison

[Charles-François Natali]

Charles-François Natali  added the comment:

I don't see the point of obfuscating the code to avoid a vulnerability
to which the code is not even vulnerable, just so that it can be used
as example...
There are *thousands* of ways to introduce security flaws, and the
Python code base if not a security handbook ;-)

--

___
Python tracker 

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

[issue14532] multiprocessing module performs a time-dependent hmac comparison

[Jon Oberheide]

Jon Oberheide  added the comment:

You call it obfuscating, I call it security correctness and developer 
education. Tomayto, tomahto. ;-)

Anywho, your call of course, feel free to close.

--

___
Python tracker 

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

[issue14546] lll.py can't handle multiple parameters correctly

[Carton He]

New submission from Carton He :

Space errors in calling of lll(arg) of main() cause it only applies to the last 
parameter instead of all parameters.

Patch attached for Python 3.1

--
components: Demos and Tools
files: lll.py.patch
keywords: patch
messages: 158036
nosy: carton
priority: normal
severity: normal
status: open
title: lll.py can't handle multiple parameters correctly
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file25178/lll.py.patch

___
Python tracker 

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

[issue14546] lll.py can't handle multiple parameters correctly

[R. David Murray]

R. David Murray  added the comment:

Thanks for the patch.

Do you have any interest in writing a test for this?  Tests for tools go in 
Lib/test/test_tools.py.

--
nosy: +r.david.murray
stage:  -> test needed
type:  -> behavior
versions: +Python 3.2, Python 3.3 -Python 3.4

___
Python tracker 

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

[issue14547] Python symlink to script behaves unexpectedly

[Johannes Buchner]

New submission from Johannes Buchner :

If I have a script 
foo/bar.py
  import baz

and create a symlink to it, called barhere.py
ln -s foo/bar.py barhere.py

when I run it, it behaves unexpectedly, specifically it behaves differently 
than if I had copied it here. It prefers to import baz from foo/baz, not from 
the current folder.

Apparently Python (2.7.2-r3) handles symlinks differently than just looking at 
the content (everything is a file philosophy in UNIX).

--
messages: 158039
nosy: j13r
priority: normal
severity: normal
status: open
title: Python symlink to script behaves unexpectedly

___
Python tracker 

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

[issue14532] multiprocessing module performs a time-dependent hmac comparison

[Charles-François Natali]

Charles-François Natali  added the comment:

> You call it obfuscating, I call it security correctness and developer 
> education. Tomayto, tomahto. ;-)

Well, I'd be prompt to changing to a more robust digest check
algorithm if the current one had a flaw, but AFAICT, it's not the case
(but I'm no security expert).

> Anywho, your call of course, feel free to close.

Being a core Python developer doesn't mean I'm right ;-)

I just don't think that "set an example for other hmac module users"
is a good reason on its own to complicate the code, which is currently
readable and - AFICT - safe (complexity usually introduces bugs).
Furthermore, I somehow doubt that hmac users will go and have a look
at the multiprocessing connection challenge code when looking for an
example.

One thing that could definitely be interesting is to look through the
code base and example to see if a similar - but vulnerable - pattern
is used, and fix such occurrences.

--

___
Python tracker 

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

[issue14532] multiprocessing module performs a time-dependent hmac comparison

[sbt]

sbt  added the comment:

I think it would be reasonable to add a safe comparison function to hmac.
Its documentation could explain briefly when it would be preferable to "==".

--

___
Python tracker 

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

[issue14542] reverse() doesn't reverse sort correctly

[Bill Jefferson]

Bill Jefferson  added the comment:

Mark and Eric..
Wonderful! I got it now.  I used x.sort(reverse=True) and  
x.sort(reverse=False) and it works just fine. Thanks for your help.
Bill..

 
Regards from:
William Jefferson Photography
514 Daniels St., #211
Raleigh, NC 27605
Cell Phone: (919) 931-6681
EMail: shagge...@yahoo.com
Brides & Weddings: http://www.WilliamJeffersonPhotography.com
Special Events: http://www.DancingLight.org


 From: Mark Dickinson 
To: shagge...@yahoo.com 
Sent: Wednesday, April 11, 2012 8:28 AM
Subject: [issue14542] reverse() doesn't reverse sort correctly

Mark Dickinson  added the comment:

Bill,

list.reverse doesn't do any *sorting* at all;  it merely *reverses* the list 
contents.

[2, 4, 3, 1]

If you want to do a reverse sort, you can either first sort normally and then 
reverse the result, or (easier) use the 'reverse' keyword argument to the 
list.sort method, as follows:

[4, 3, 2, 1]

I suspect Eric meant to write "does not reverse sort" instead of "does not 
reverse".

--
nosy: +mark.dickinson

___
Python tracker 

___

--

___
Python tracker 

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

[issue14341] sporadic (?) test_urllib2 failures

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 751c7b81f6ee by Senthil Kumaran in branch 'default':
use assertWarns instead of check_warnings - Issue14341
http://hg.python.org/cpython/rev/751c7b81f6ee

--
nosy: +python-dev

___
Python tracker 

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

[issue14341] sporadic (?) test_urllib2 failures

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Hi Antoine, 

I saw that check_warnings was commonly used ( and perhaps I had used to earlier 
without any problems) and overlooked assertWarns. But I think, it is good to 
remove support.check_warnings dependency here and just use assertWarnings.  Let 
me see if this squashes that sporadic failures in builldbots.

I think, the test_http_cookiejar and test_urllib2 dependency (if any) should 
also be looked at irrespective of this. I shall check that.

Thanks,
Senthil

Thanks.

--

___
Python tracker 

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

[issue14532] multiprocessing module performs a time-dependent hmac comparison

[R. David Murray]

R. David Murray  added the comment:

It would also be reasonable to add a comment to the code mentioning why this 
particular (security) comparison is *not* vulnerable to a timing attack, which 
would serve the education purpose if someone does look at the code.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue14532] multiprocessing module performs a time-dependent hmac comparison

[Jon Oberheide]

Jon Oberheide  added the comment:

> One thing that could definitely be interesting is to look through the
> code base and example to see if a similar - but vulnerable - pattern
> is used, and fix such occurrences.

Based on some quick greps, I didn't see many internal users of hmac and the 
current users don't seem to use it in a scenario that would be at risk (eg. 
attacker supplied digest compared against an expected digest).

Given that this issue has affected a lot of security-sensitive third-party code 
(keyczar, openid providers, almost every python web service that implements 
"secure cookies" [1] or other HMAC-based REST API signatures), I do like the 
idea of adding a warning in the relevant documentation as sbt proposed.

The only reason I'd recommend _not_ putting a time_independent_comparison() 
function in the hmac module is that it's not really HMAC-specific. In practice, 
any fixed-length secrets should be compared in a time-independent manner. It 
just happens that HMAC verification is a pretty common case for this vulnerable 
construct. :-)

[1] https://github.com/facebook/tornado/blob/master/tornado/web.py#L1981

--

___
Python tracker 

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

[issue14452] SysLogHandler sends invalid messages when using unicode

[Guido van Rossum]

Guido van Rossum  added the comment:

But why on earth would one want a BOM in UTF-8-encoded data?  It is byte-order 
independent!

--
nosy: +gvanrossum

___
Python tracker 

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

[issue14452] SysLogHandler sends invalid messages when using unicode

[Tim Golden]

Tim Golden  added the comment:

It's used by some systems (Windows Notepad does this
if you save as UTF8) to indicate that the byte stream
*is* UTF8-encoded. It's not so much a BOM as a magic cookie.

I can't speak for syslog, I'm afraid

TJG

--
nosy: +tim.golden

___
Python tracker 

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

[issue14452] SysLogHandler sends invalid messages when using unicode

[Vinay Sajip]

Vinay Sajip  added the comment:

> But why on earth would one want a BOM in UTF-8-encoded data?  It is 
> byte-order independent!

Lord only knows, but the RFC does call for it - msg157572 has an actual excerpt 
from RFC 5424.

--

___
Python tracker 

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

[issue14548] garbage collection just after multiprocessing's fork causes exceptions

[sbt]

New submission from sbt :

When running test_multiprocessing on Linux I occasionally see a stream of 
errors caused by ignored weakref callbacks:

  Exception AssertionError: AssertionError() in  ignored

These do not cause the unittests to fail.

Finalizers from the parent process are supposed to be cleared after the fork.  
But if a garbage collection before that then Finalizer callbacks can be run in 
the "wrong" process.

Disabling gc during fork seems to prevent the errors.  Or maybe the Finalizer 
should record the pid of the process which created it and only invoke the 
callback if it matches the current pid.

(Compare Issure 1336 conscerning subprocess.)

--
messages: 158049
nosy: sbt
priority: normal
severity: normal
status: open
title: garbage collection just after multiprocessing's fork causes exceptions

___
Python tracker 

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

[issue14545] html module should not be available in Python 3.1

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 2776ccf003cc by Georg Brandl in branch '3.2':
Closes #14545: make clearer what was added.
http://hg.python.org/cpython/rev/2776ccf003cc

New changeset f5f8a7fd881c by Georg Brandl in branch 'default':
#14545: merge 3.2
http://hg.python.org/cpython/rev/f5f8a7fd881c

--
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

[issue13903] New shared-keys dictionary implementation

[Mark Shannon]

Mark Shannon  added the comment:

I don't really understand your objection to changing the method-cache size. As 
I said, I can remove the change, but that will cause the performance regression 
that Antoine noticed.

--

___
Python tracker 

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

[issue14548] garbage collection just after multiprocessing's fork causes exceptions

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Disabling gc during fork seems to prevent the errors.

Sounds reasonable to me.

--
components: +Library (Lib)
nosy: +neologix, pitrou
type:  -> behavior
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

[issue14549] Recursive inclusion of packages

[Éric Araujo]

New submission from Éric Araujo :

For projects with more than a few packages, it is tedious to list all 
subpackages manually in setup.cfg.  There was once a find_packages in 
distutils2.util (copied from distribute), but when we moved away from setup.py 
it was removed (I don’t remember all the details).

A new field would be best if we could find a good name, or we could have 
special syntax in the existing packages field (like “packages = distutils2.*”).

--
assignee: eric.araujo
components: Distutils2
messages: 158053
nosy: alexis, eric.araujo, erik.bray, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Recursive inclusion of packages
type: enhancement
versions: 3rd party, Python 3.3

___
Python tracker 

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

[issue14548] garbage collection just after multiprocessing's fork causes exceptions

[Nadeem Vawda]

Changes by Nadeem Vawda :


--
nosy: +nadeem.vawda

___
Python tracker 

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

[issue14549] Recursive inclusion of packages

[Erik Bray]

Erik Bray  added the comment:

+1 for the wildcard syntax.

--

___
Python tracker 

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

[issue14549] Recursive inclusion of packages

[Erik Bray]

Erik Bray  added the comment:

Potential downside:

Say I have foo, foo.bar, and foo.tests.  I want to install foo and foo.bar, but 
not foo.tests.  Then I have to manually list all the packages I do want:

packages =
foo
foo.bar

That's fine, but one nice thing about find_packages is that it had an optional 
exclude argument. So maybe in addition to the wildcard syntax it couldn't hurt 
to add an exclude-packages option?  I don't think that would be too complicated.

Something similar for extension module sources would also be desirable.

--

___
Python tracker 

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

[issue14550] os.path.abspath() returns physical path, not logical path.

[Craig Sawyer]

New submission from Craig Sawyer :

we have os.path.abspath() and os.path.realpath().  the difference according to 
the documentation is realpath() returns the physical path (i.e. no symlinks in 
the path).  while abspath() uses getcwd() but because of POSIX.1-2008 (IEEE Std 
1003.1-2008) says os.getcwd() returns without symbolic links as well, so 
os.path.abspath() == os.path.realpath() near as I can tell.

I think os.path.abspath() should return a logical path(i.e. one with symlinks). 
 The only solution I know of is to getenv('PWD') except that is not guaranteed 
to be around in POSIX (some BSD's don't offer PWD I understand).  The other 
option is to ask /bin/pwd which is part of the POSIX standard.

Anyways, I couldn't find a previous bug around this issue, but I think there 
should be a way in the standard library to get a logical path, as well as a 
realpath().

--
components: None
messages: 158056
nosy: csawyer-yumaed
priority: normal
severity: normal
status: open
title: os.path.abspath() returns physical path, not logical path.
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

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

[issue14547] Python symlink to script behaves unexpectedly

[R. David Murray]

R. David Murray  added the comment:

The content of a symbolic symlink is a symbolic reference to another location 
in the file system.  If you had used a hard link it would certainly work as you 
expected.

The behavior with respect to symbolic links ought to be documented here:

  http://docs.python.org/using/cmdline.html

but doesn't seem to be.

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

___
Python tracker 

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

[issue14550] os.path.abspath() returns physical path, not logical path.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> while abspath() uses getcwd() but because of POSIX.1-2008 (IEEE Std
> 1003.1-2008) says os.getcwd() returns without symbolic links as well,
> so os.path.abspath() == os.path.realpath() near as I can tell.

Just because getcwd() doesn't contain any symbolic links doesn't mean the rest 
of the path is stripped of all symlinks.

> I think there should be a way in the standard library to get a logical 
> path, as well as a realpath().

This doesn't make sense. There could be an arbitrary number of "logical" paths 
pointing to a single physical one. Which one should Python choose?

--
nosy: +pitrou

___
Python tracker 

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

[issue14549] Recursive inclusion of packages

[Éric Araujo]

Éric Araujo  added the comment:

IMO the best behavior would be to always recurse and have an option to exclude 
specific submodules.  When the Django devs want to package their code, they 
think about a Python package named django, docs and scripts, not about django, 
django.views, django.http, etc.  I proposed glob syntax or a new key to be 
conservative, but now I’ll add a third proposal:

packages = foo
packages-exclude = foo.spam

For a package foo with subpackages ham and spam, this would get foo and foo.ham.
Note that this was discussed on the fellowship ML two years ago but I don’t 
have the time to re-read the thread now.

(Why is it not named exclude-packages? 1) you can exclude single-file modules 
too with this option 2) it makes it clear that it’s a “sub-option” of packages)

About extension modules sources: good idea, but it should be its own feature 
request.

--

___
Python tracker 

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

[issue14550] os.path.abspath() returns physical path, not logical path.

[Craig Sawyer]

Craig Sawyer  added the comment:

Antoine,

I see your point about getcwd() not having symlinks, doesn't mean any path 
outside of getcwd() might have symlinks, and I agree this is true.  I apologize.

As for which one to choose, it should choose based on PWD (i.e. the current 
working directory's parent directories).  I'd love to see something like 
os.path.abspath(path, logical=True) which would use PWD instead of getcwd() to 
get the current working directories path.  i.e. symlinks are honored within the 
current path. From a language perspective this probably means needing 
os.getpwd() or something similar, that would return the pwd information.

I know pwd isn't always guaranteed to be around, so the failsafe should be to 
return getcwd() in that case, just like os.path.abspath() does now.

--

___
Python tracker 

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

[issue14550] os.path.abspath() should have an option to use PWD

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ok, reformulating the title a bit.

--
components: +Library (Lib) -None
title: os.path.abspath() returns physical path, not logical path. -> 
os.path.abspath() should have an option to use PWD
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

___
Python tracker 

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

[issue8799] Hang in lib/test/test_threading.py

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ok, doc improved in 9d4109af8f3b.

--

___
Python tracker 

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

[issue14515] tempfile.TemporaryDirectory documented as returning object but returns name

[R. David Murray]

R. David Murray  added the comment:

I misread the docs.  They aren't wrong, but it is still the case that they 
don't mention that the directory name is what you get on entry to the context, 
which is what led to my confusion.  

Here's a patch.

--
keywords: +patch
nosy: +ncoghlan
Added file: http://bugs.python.org/file25179/tempdir-doc.patch

___
Python tracker 

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

[issue14548] garbage collection just after multiprocessing's fork causes exceptions

[sbt]

sbt  added the comment:

Patch to disable gc.

--
keywords: +patch
Added file: http://bugs.python.org/file25180/mp_disable_gc.patch

___
Python tracker 

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

[issue4892] Sending Connection-objects over multiprocessing connections fails

[sbt]

sbt  added the comment:

The last patch did not work on Unix.

Here is a new version where the reduction functions are automatically 
registered, so allow_connection_pickling() is redundant.

--
Added file: http://bugs.python.org/file25181/mp_pickle_conn.patch

___
Python tracker 

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

[issue14551] imp.load_source docs removed from python3 docs...is this correct?

[R. David Murray]

New submission from R. David Murray :

This was removed in 2cf7bb2bbfb8 along with a bunch of other functions.  Yet in 
issue 13959 Brett mentions needing to implement it.  I don't see any 
replacement for its functionality in importlib, so I would think it would be a 
function we would want to keep.  It certainly still exists, and I'm sure many 
people are using it.

--
messages: 158066
nosy: brett.cannon, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: imp.load_source docs removed from python3 docs...is this correct?
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

[issue10484] http.server.is_cgi fails to handle CGI URLs containing PATH_INFO

[Roundup Robot]

Roundup Robot  added the comment:

New changeset c67efb8ffca4 by Senthil Kumaran in branch '2.7':
Issue 10484 - Incorporate improvements to CGI module - Suggested by Glenn 
Linderman. Refactor code and tests
http://hg.python.org/cpython/rev/c67efb8ffca4

New changeset fc001124a3ee by Senthil Kumaran in branch '3.2':
3.2 - Issue 10484 - Incorporate improvements to CGI module - Suggested by Glenn 
Linderman. Refactor code and tests
http://hg.python.org/cpython/rev/fc001124a3ee

New changeset 23f648d7053b by Senthil Kumaran in branch 'default':
merge to default - Issue 10484 - Incorporate improvements to CGI module - 
Suggested by Glenn Linderman. Refactor code and tests
http://hg.python.org/cpython/rev/23f648d7053b

--

___
Python tracker 

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

[issue10484] http.server.is_cgi fails to handle CGI URLs containing PATH_INFO

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Hello Glenn, 

Your suggestions were valid. I have made those changes in the code. Thanks! I 
think, we can close this bug now and move over to others.

Thanks,
Senthil

--
status: open -> closed

___
Python tracker 

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

[issue14508] gprof2html is broken

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 4d603d6782db by R David Murray in branch '3.2':
#14508: make gprof2html script runnable under python3
http://hg.python.org/cpython/rev/4d603d6782db

New changeset 73fba223c0a5 by R David Murray in branch 'default':
#14508: make gprof2html script runnable under python3
http://hg.python.org/cpython/rev/73fba223c0a5

--
nosy: +python-dev

___
Python tracker 

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

[issue14508] gprof2html is broken

[R. David Murray]

R. David Murray  added the comment:

Thanks for the patch.  I don't think you ran the test though, since it didn't 
pass, and there was a mistake in your patch :)

I had to change the test considerably, and only applied the test part on 3.3 
since I used mock.

--
resolution:  -> fixed
stage:  -> 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

[issue14548] garbage collection just after multiprocessing's fork causes exceptions

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Shouldn't there be a try..finally, in case os.fork() fails?

--

___
Python tracker 

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

[issue14551] imp.load_source docs removed from python3 docs...is this correct?

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Hmm, yes, I don't remember exactly why, but it seems they were deprecated 
("obsolete"), so it sounds reasonable to un-document them.

--

___
Python tracker 

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

[issue14444] Virtualenv not portable from Python 2.7.2 to 2.7.3 (os.urandom missing)

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Closing, now that we've released finals.

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

___
Python tracker 

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

[issue14551] imp.load_source docs removed from python3 docs...is this correct?

[R. David Murray]

R. David Murray  added the comment:

OK, the text at the start of the section, that I didn't notice in the 2.7 docs, 
says they are obsolete and replaced by find_module and import_module.  But 
load_source is much more convenient, so I for one am not going to remove my use 
of it in the tests I just checked in.  Someone who wants to actually remove 
load_source can fix them :)

--
resolution:  -> invalid
stage:  -> 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

[issue14532] multiprocessing module performs a time-dependent hmac comparison

[Charles-François Natali]

Charles-François Natali  added the comment:

> Given that this issue has affected a lot of security-sensitive third-party 
> code (keyczar, openid providers, almost every python web service that 
> implements "secure cookies" [1] or other HMAC-based REST API signatures), I 
> do like the idea of adding a warning in the relevant documentation as sbt 
> proposed.

This does sound reasonable, along with the addition of a comparison
function immune to timing attacks to the hmac module (as noted, it's
not specific to hmac, but it looks like a resonable place to add it).
Would you like to submit a patch (new comparison function with
documentation and test)?

--

___
Python tracker 

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

[issue8799] Hang in lib/test/test_threading.py

[Charles-François Natali]

Charles-François Natali  added the comment:

> Ok, doc improved in 9d4109af8f3b.

LGTM.

Kristján, how about updating your patch to only fix the original
problem you spotted (notify() called before wait()), then we can see
the remaining parts?

--

___
Python tracker 

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

[issue14540] Crash in Modules/_ctypes/libffi/src/dlmalloc.c on ia64-hp-hpux11.31

[Charles-François Natali]

Charles-François Natali  added the comment:

> I think it's bundled with our copy of libffi.

i'm not familiar - at all - with libffi.
But does it really need a bundled malloc() implementation?

> I'd be more than happy to use my own installation of libffi instead, but it 
> seems the --with-system-ffi configure flag doesn't work.  I've also opened a 
> different bug for that.

So, is the stack trace complete?
Is it really generated by the python executable?

--

___
Python tracker 

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

[issue14540] Crash in Modules/_ctypes/libffi/src/dlmalloc.c on ia64-hp-hpux11.31

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> > I think it's bundled with our copy of libffi.
> 
> i'm not familiar - at all - with libffi.
> But does it really need a bundled malloc() implementation?

Well, the upstream libffi includes dlmalloc.c, so I guess it somehow
needs it (perhaps only on certain platforms). Don't ask me why :-)

--

___
Python tracker 

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

[issue14552] test module: remove repetition

[Tshepang Lekhonkhobe]

Changes by Tshepang Lekhonkhobe :


--
assignee: docs@python
components: Documentation
files: repetition.diff
keywords: patch
nosy: docs@python, tshepang
priority: normal
severity: normal
status: open
title: test module: remove repetition
Added file: http://bugs.python.org/file25182/repetition.diff

___
Python tracker 

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

[issue14553] http.server module: grammar fix

[Tshepang Lekhonkhobe]

Changes by Tshepang Lekhonkhobe :


--
assignee: docs@python
components: Documentation
files: grammar.diff
keywords: patch
nosy: docs@python, tshepang
priority: normal
severity: normal
status: open
title: http.server module: grammar fix
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25183/grammar.diff

___
Python tracker 

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

[issue11501] distutils.archive_util should handle absence of zlib module

[Éric Araujo]

Éric Araujo  added the comment:

Reopening for 2.7.4.

--
assignee: tarek -> eric.araujo
resolution: fixed -> 
stage: committed/rejected -> commit review
status: closed -> open
versions: +Python 2.7

___
Python tracker 

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

[issue14548] garbage collection just after multiprocessing's fork causes exceptions

[Charles-François Natali]

Charles-François Natali  added the comment:

Hmm...
I don't really like disabling GC, because it has a process-wide side
effect, and hence isn't thread-safe: if another thread forks() or
creates a subprocess right at the wrong time, it could end up with the
GC disabled for good...

--

___
Python tracker 

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

[issue14548] garbage collection just after multiprocessing's fork causes exceptions

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Hmm...
> I don't really like disabling GC, because it has a process-wide side
> effect, and hence isn't thread-safe: if another thread forks() or
> creates a subprocess right at the wrong time, it could end up with the
> GC disabled for good...

That's a problem indeed. Perhaps we need a global "fork lock" shared
between subprocess and multiprocessing?

--

___
Python tracker 

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

[issue14554] test module: correction

[Tshepang Lekhonkhobe]

New submission from Tshepang Lekhonkhobe :

add missing '\n'

--
assignee: docs@python
components: Documentation
messages: 158082
nosy: docs@python, tshepang
priority: normal
severity: normal
status: open
title: test module: correction
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

[issue14532] multiprocessing module performs a time-dependent hmac comparison

[Jon Oberheide]

Jon Oberheide  added the comment:

Will do!

--

___
Python tracker 

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

[issue14555] clock_gettime/settime/getres: Add more clock identifiers

[STINNER Victor]

New submission from STINNER Victor :

Python 3.3 supports the following clock identifiers:

 * CLOCK_REALTIME
 * CLOCK_MONOTONIC
 * CLOCK_MONOTONIC_RAW
 * CLOCK_HIGHRES
 * CLOCK_PROCESS_CPUTIME_ID
 * CLOCK_THREAD_CPUTIME_ID

Linux has more clocks:

 * CLOCK_BOOTTIME
 * CLOCK_REALTIME_COARSE
 * CLOCK_MONOTONIC_COARSE
 * CLOCK_BOOTTIME_ALARM
 * CLOCK_REALTIME_ALARM

FreeBSD has more clocks:

 * CLOCK_VIRTUAL
 * CLOCK_UPTIME, CLOCK_UPTIME_FAST, CLOCK_UPTIME_PRECISE
 * CLOCK_MONOTONIC_FAST, CLOCK_MONOTONIC_PRECISE
 * CLOCK_REALTIME_FAST, CLOCK_REALTIME_PRECISE
 * CLOCK_SECOND
 * CLOCK_PROF

CLOCK_BOOTTIME is useful is you would like to handle system suspend for example.

--
components: Library (Lib)
messages: 158084
nosy: haypo
priority: normal
severity: normal
status: open
title: clock_gettime/settime/getres: Add more clock identifiers
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

[issue14555] clock_gettime/settime/getres: Add more clock identifiers

[STINNER Victor]

STINNER Victor  added the comment:

Extract of FreeBSD manpage of clock_gettime:

 The clock_id argument can be one of the following values: CLOCK_REALTIME,
 CLOCK_REALTIME_PRECISE, CLOCK_REALTIME_FAST for time that increments as a
 wall clock should; CLOCK_MONOTONIC, CLOCK_MONOTONIC_PRECISE,
 CLOCK_MONOTONIC_FAST which increments in SI seconds; CLOCK_UPTIME,
 CLOCK_UPTIME_PRECISE, CLOCK_UPTIME_FAST which starts at zero when the
 kernel boots and increments monotonically in SI seconds while the machine
 is running; CLOCK_VIRTUAL for time that increments only when the CPU is
 running in user mode on behalf of the calling process; CLOCK_PROF for
 time that increments when the CPU is running in user or kernel mode; or
 CLOCK_SECOND which returns the current second without performing a full
 time counter query, using in-kernel cached value of current second.

 The clock IDs CLOCK_REALTIME_FAST, CLOCK_MONOTONIC_FAST,
 CLOCK_UPTIME_FAST are analogs of corresponding IDs without _FAST suffix
 but do not perform a full time counter query, so their accuracy is one
 timer tick.  Similarly, CLOCK_REALTIME_PRECISE, CLOCK_MONOTONIC_PRECISE,
 CLOCK_UPTIME_PRECISE are used to get the most exact value as possible, at
 the expense of execution time.

--

___
Python tracker 

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

[issue14551] imp.load_source docs removed from python3 docs...is this correct?

[Brett Cannon]

Brett Cannon  added the comment:

Once importlib bootstrapping lands and I expose the rest of the API you can 
replace imp.load_source() w/ importlib.SourceFileLoader(name, 
path).load_module(name) and get the same result.

--

___
Python tracker 

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

[issue14548] garbage collection just after multiprocessing's fork causes exceptions

[sbt]

sbt  added the comment:

> That's a problem indeed. Perhaps we need a global "fork lock" shared
> between subprocess and multiprocessing?

I did an atfork patch which included a (recursive) fork lock.  See

http://bugs.python.org/review/6721/show

The patch included changes to multiprocessing and subprocess.  (Being able to 
acquire the lock when doing fd manipulation is quite useful.  For instance, the 
creation of Process.sentinel currently has a race which can mean than another 
process inherits the write end of the pipe.  That would cause Process.join() to 
wait till both processes terminate.)

Actually, for Finalizers I think it would be easier to just record and check 
the pid.

--

___
Python tracker 

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

[issue14554] test module: correction

[Georg Brandl]

Georg Brandl  added the comment:

I think a patch is missing :)

--
nosy: +georg.brandl

___
Python tracker 

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

[issue14555] clock_gettime/settime/getres: Add more clock identifiers

[R. David Murray]

Changes by R. David Murray :


--
type:  -> enhancement

___
Python tracker 

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

[issue14553] http.server module: grammar fix

[R. David Murray]

R. David Murray  added the comment:

Thanks.

--
nosy: +r.david.murray
resolution:  -> fixed
status: open -> closed
type:  -> behavior

___
Python tracker 

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

[issue14553] http.server module: grammar fix

[Roundup Robot]

New submission from Roundup Robot :

New changeset ed5788424c34 by R David Murray in branch '3.2':
#14553: fix word order.
http://hg.python.org/cpython/rev/ed5788424c34

New changeset bd353f12c007 by R David Murray in branch 'default':
Merge doc fixes #14553 and #14552.
http://hg.python.org/cpython/rev/bd353f12c007

--
nosy: +python-dev

___
Python tracker 

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

[issue14552] test module: remove repetition

[R. David Murray]

New submission from R. David Murray :

2.7 d60ef141e090
3.2 f25fb7e1d076
3.3 bd353f12c007

Thanks.

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

___
Python tracker 

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

[issue14540] Crash in Modules/_ctypes/libffi/src/dlmalloc.c on ia64-hp-hpux11.31

[Paul A.]

Paul A.  added the comment:

Yes indeed, sorry for not answering that question the first time.
The trace is complete, and is from python... although most of it is really in 
the shared lib rather than the executable.

--

___
Python tracker 

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

[issue14399] zipfile and creat/update comment

[R. David Murray]

R. David Murray  added the comment:

Serhiy: this looks good.  I get some test errors when I apply it on 2.7 though. 
 Would you be interested in doing a 2.7 version as well?

(Minor comment: the test method would be better as two test methods, and it 
would be nice to have a third test method that checked for the TypeError for 
non-binary comments...that won't apply to 2.7, obviously).

--
stage: test needed -> patch review

___
Python tracker 

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

[issue14399] zipfile and creat/update comment

[R. David Murray]

R. David Murray  added the comment:

Serhiy: this looks good.  I get some test errors when I apply it on 2.7 though. 
 Would you be interested in doing a 2.7 version as well?

(Minor comment: the test method would be better as two test methods, and it 
would be nice to have a third test method that checked for the TypeError for 
non-binary comments...that won't apply to 2.7, obviously).

--

___
Python tracker 

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

[issue14399] zipfile and creat/update comment

[R. David Murray]

Changes by R. David Murray :


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

___
Python tracker 

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

[issue14556] telnetlib Telnet.expect fails with timeout=0

[Joel Lovinger]

New submission from Joel Lovinger :

In Python 2.4.3 a Telnet.expect with timeout=0 would always make at least one 
call to Telnet.fill_rawq if a match couldn't be found and the connection was 
open.

In Python 2.7.1/2.7.3 Telnet.expect with timeout=0 breaks before any call to 
Telnet.fill_rawq if a match isn't found in already read raw/cooked data. 
Expected behavior is that on timeout=0 at least one non-blocking attempt should 
be made to read from the connection when necessary to fulfill a match.

>From code inspection (including Python 2.7.3) timeout behavior was modified to 
>provide an overall elapsed timeout instead of passing unmodified timeout to 
>each select resulting in the failure.


Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from telnetlib import Telnet
>>> import time
>>> tn = Telnet("scn.org", 23)
>>> time.sleep(5) # short wait for data to be available
>>> tn.expect(['.{16}'], 0)
(-1, None, '')
>>>

Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from telnetlib import Telnet
>>> import time
>>> tn = Telnet("scn.org", 23)
>>> time.sleep(5) # short wait for data to be available
>>> tn.expect(['.{16}'], 0)
(0, <_sre.SRE_Match object at 0x01752410>, '\r\nSeattle Communit')
>>>

--
components: Library (Lib)
messages: 158096
nosy: Joel.Lovinger
priority: normal
severity: normal
status: open
title: telnetlib Telnet.expect fails with timeout=0
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue14547] Python symlink to script behaves unexpectedly

[Nick Coghlan]

Nick Coghlan  added the comment:

Specifically, we end up calling os.realpath() (or the C level equivalent) when 
initialising __main__.__file__ and sys.path[0].

Agreed this behaviour should be documented (and tested!) explicitly.

--
assignee:  -> docs@python
components: +Documentation, Tests
nosy: +docs@python
stage:  -> needs patch
type:  -> enhancement
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

[issue14556] telnetlib Telnet.expect fails with timeout=0

[R. David Murray]

R. David Murray  added the comment:

Can you point to the changes you think are at issue?  That might help us track 
down why the change was made.  This isn't necessarily a bug, but even if it 
isn't, the behavior should probably be explicitly documented.

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

___
Python tracker 

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

[issue9175] ctypes doesn't build on hp-ux

[Adi Roiban]

Changes by Adi Roiban :


--
nosy: +adiroiban

___
Python tracker 

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

[issue14557] HP-UX libraries not included

[Adi Roiban]

New submission from Adi Roiban :

Hi,

I am trying to build Python on HP-UXiv3.

HP-UX also keeps libs in /usr/lib/hpux64 and /usr/lib/hpux32.

I have attached a patch for searching these folders.



The patch is against the latest version of cpython.

I have tests the change on Python 2.5.6.

Cheers,
Adi

--
files: hpux-libs.diff
keywords: patch
messages: 158099
nosy: adiroiban
priority: normal
severity: normal
status: open
title: HP-UX libraries not included
Added file: http://bugs.python.org/file25184/hpux-libs.diff

___
Python tracker 

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

[issue5113] 2.5.4.3 / test_posix failing on HPUX systems

[Adi Roiban]

Changes by Adi Roiban :


--
nosy: +adiroiban

___
Python tracker 

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

[issue14515] tempfile.TemporaryDirectory documented as returning object but returns name

[Nick Coghlan]

Nick Coghlan  added the comment:

Change looks fine to me - go ahead and commit it :)

--

___
Python tracker 

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