[issue8858] socket.getaddrinfo returns wrong results for IPv6 addresses

[Marc Schlaich]

Marc Schlaich added the comment:

I get the same result from `getaddrinfo` if Python is compiled with 
`--disable-ipv6`. Is this the correct behaviour? I would expect no IP v6 
address at all.

Python 2.5.6 (r256:88840, Jan 22 2013, 08:41:04) 
[GCC 4.4.6 20120305 (Red Hat 4.4.6-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.has_ipv6
False
>>> socket.getaddrinfo(None, 9966, socket.AF_UNSPEC, socket.SOCK_STREAM, 0, 
>>> socket.AI_PASSIVE)
[(2, 1, 6, '', ('0.0.0.0', 9966)), (10, 1, 6, '', (10, 
'&\xee\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'))]

--
nosy: +schlamar

___
Python tracker 

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

[issue11379] Remove "lightweight" from minidom description

[Stefan Behnel]

Stefan Behnel added the comment:

I'm not sure if it's a good idea to keep bikeshedding about this for another 
two years. Personally, I would prefer having someone with commit rights fix 
this and be done with it.

Eric's last patch looks ok and parts of it went in already, so it's mostly just 
the heading that remains to be fixed.

--
versions: +Python 3.4

___
Python tracker 

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

[issue17011] ElementPath ignores different namespace mappings for the same path expression

[Stefan Behnel]

Stefan Behnel added the comment:

Here is a test case (for lxml):

https://github.com/lxml/lxml/commit/76f2ee991afd15d4f8c98cee3e095967bbf9937f

--

___
Python tracker 

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

[issue17011] ElementPath ignores different namespace mappings for the same path expression

[Stefan Behnel]

Changes by Stefan Behnel :


--
components: +XML

___
Python tracker 

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

[issue17011] ElementPath ignores different namespace mappings for the same path expression

[Stefan Behnel]

Changes by Stefan Behnel :


--
components: +Library (Lib) -XML

___
Python tracker 

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

[issue17011] ElementPath ignores different namespace mappings for the same path expression

[Stefan Behnel]

New submission from Stefan Behnel:

There's a bug originally report for lxml that also applies to ElementTree:

https://github.com/lxml/lxml/issues/95

Passing different namespace mappings into the Element.find*() methods will 
always reuse the first one due to incorrect caching based only on the literal 
path, not all parameters. My fix is here:

https://github.com/lxml/lxml/commit/8bafbdc13ffb4fb8436eda01594780aac4735528

The lookup performance regression when a namespace mapping is passed (sorting 
etc.) is acceptable as most use cases won't pass any namespaces anyway, so this 
is a problem that rarely shows in practice.

--
components: XML
messages: 180366
nosy: scoder
priority: normal
severity: normal
status: open
title: ElementPath ignores different namespace mappings for the same path 
expression
type: behavior
versions: Python 2.7, 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

[issue17001] Make uuid.UUID use functools.total_ordering

[Raymond Hettinger]

Changes by Raymond Hettinger :


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

[issue17009] "Thread Programming With Python" should be removed

[Guido van Rossum]

Guido van Rossum added the comment:

I'd like to keep the essay around as a permalink, but I don't object against 
putting some red text at the top warning people is is horribly out of date, and 
linking to a better tutorial.

--

___
Python tracker 

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

[issue17009] "Thread Programming With Python" should be removed

[Ned Deily]

Ned Deily added the comment:

It's included in a directory of Guido's essays 
(http://www.python.org/doc/essays/).  Guido, any thoughts about this and the 
others?

--
nosy: +gvanrossum, ned.deily

___
Python tracker 

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

[issue17009] "Thread Programming With Python" should be removed

[Ezio Melotti]

Ezio Melotti added the comment:

Given that the note at the top says that it's an unfinished draft, I think 
removing it would be fine.  It might be nice to see if there's anything still 
relevant that could be moved to the official docs, and possibly find out who 
wrote it and if he's ok with the removal.

--
type:  -> enhancement

___
Python tracker 

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

[issue17010] Windows launcher ignores active virtual environment

[Bryan G. Olson]

New submission from Bryan G. Olson:

Python 3.3 includes PEP 397, a Python launcher for Windows, and PEP 405, 
virtual environment support in core. Unfortunately the Windows launcher does 
not respect virtual environments. Even with with a virtual environment 
activated and the current directory at the virtual environment's root, the 
Windows launcher will start python with the system environment, not the active 
virtual environment.


To demo:

Install python 3.3 for windows.

Create a virtual environment:

  C:\>c:\Python33\Tools\Scripts\pyvenv.py c:\virtpy

Activate the virtual environment:

  C:\>virtpy\Scripts\activate.bat
  (virtpy) C:\>

Optionally cd to the virtual environment:

  (virtpy) C:\>cd virtpy
  (virtpy) C:\virtpy>

Start Python 3 with the new windows launcher:

  (virtpy) C:\virtpy>py -3
  Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit 
(Intel)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  >>>

Check sys.path

  >>> import sys
  >>>
  >>> sys.path
  ['', 'C:\\Windows\\system32\\python33.zip', 'C:\\bin\\Python33\\DLLs', 
'C:\\bin\\Python33\\lib', 'C:\\bin\\Python33', 
'C:\\bin\\Python33\\lib\\site-packages']
  >>>


The worst effect I've found is that installation of a package with windows 
launcher, "py -3 setup.py install", will ignore the active virtual environment 
and will change the system Python environment. That's bad because users 
frequently employ virtual environments to isolate changes that could damage a 
system configuration.

--
components: Installation, Windows
messages: 180362
nosy: bryangeneolson
priority: normal
severity: normal
status: open
title: Windows launcher ignores active virtual environment
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

[issue17007] logging documentation clarifications

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8de6f92c89e6 by Vinay Sajip in branch '2.7':
Issue #17007: Made minor changes to documentation wording.
http://hg.python.org/cpython/rev/8de6f92c89e6

New changeset c8614ec54a63 by Vinay Sajip in branch '3.2':
Issue #17007: Made minor changes to documentation wording.
http://hg.python.org/cpython/rev/c8614ec54a63

New changeset d0e9f64bd55c by Vinay Sajip in branch '3.3':
Issue #17007: Merged minor changes from 3.2.
http://hg.python.org/cpython/rev/d0e9f64bd55c

New changeset 6877957a5e91 by Vinay Sajip in branch 'default':
Issue #17007: Merged minor changes from 3.3.
http://hg.python.org/cpython/rev/6877957a5e91

--

___
Python tracker 

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

[issue16507] Patch selectmodule.c to support WSAPoll on Windows

[Charles-François Natali]

Charles-François Natali added the comment:

> I have created an iocp branch.

You could probably report the fixes for spurious notifications in the
default branch.

--

___
Python tracker 

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

[issue17007] logging documentation clarifications

[Chris Jerdonek]

Chris Jerdonek added the comment:

Great, that looks a lot better.  Thanks!

A couple comments though:

+   .. note:: If you attach a handler to several loggers, it may emit the same
+  record multiple times. In general, you should not need to attach a
+  handler to more than one logger - if you just attach it to the
+  appropriate logger which is highest in the logger hierarchy, then it
+  will see all events logged by all descendant loggers, provided that
+  their propagate setting is left set to ``True``. A common scenario is to
+  attach handlers only to the root logger, and let propagation take care of
+  the rest.

Would it be better to say something like, "If you attach a handler to a logger 
and one of its ancestors [and similar changes later]..."  The reason I ask is 
that it seems like there is a valid use case for attaching a handler to more 
than one logger (which I have used), which is if the loggers aren't in the same 
ancestry chain.  For example, if I want loggers "app1" and "app2" to log and 
nothing else, I could attach a StreamHandler to those two loggers and a 
NullHandler to the root logger.  It seems like the above would discourage that 
pattern.  Or is that not recommended?  (I suppose you could also do this using 
a custom filter by name on the root logger, though I don't know which technique 
is preferred.)

> it never makes sense to add more than one filter

Here I was referring to the restricted case of using default filters by name.  
For example, it seems like it would never make sense to filter by "A.B" and 
"A.C" because that is just an obfuscated way of filtering by the simpler and 
equivalent "A."  Does that make sense?  (I'm not suggesting any changes to the 
docs in this comment.)

--

___
Python tracker 

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

[issue16507] Patch selectmodule.c to support WSAPoll on Windows

[Richard Oudkerk]

Richard Oudkerk added the comment:

I have created an iocp branch.

--

___
Python tracker 

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

[issue16993] shutil.which() should preserve path case

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Test broken on Windows because PATHEXT contains uppercased extension ".EXT".

Proposed solutions:

1. Fix the test: expect uppercased extension, or do case-insensitive extension 
comparison, or get extension from PATHEXT.
2. Rollback the part of previous changes which preserve case of extensions from 
PATHEXT and always lowercase them.
3. Rollback the changes overall.
4. Use not used for now ntpath._getfinalpathname() to get a real file name (it 
resolves symlinks, though).

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

___
Python tracker 

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

[issue17009] "Thread Programming With Python" should be removed

[Antoine Pitrou]

Antoine Pitrou added the comment:

I think these files are outside of the CPython doc tree, they are probably 
static files on the server. 
That said, I agree it would be good to either add the "deprecated, kept only 
for historical purposes" note at the top of every file there, or simply remove 
them.

--
assignee:  -> docs@python
components: +Documentation -None
nosy: +docs@python, ezio.melotti, pitrou

___
Python tracker 

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

[issue17009] "Thread Programming With Python" should be removed

[Ned Batchelder]

New submission from Ned Batchelder:

Sorry if this is the wrong bug tracker for this issue.

Someone just asked in #python what they should do about the fact that Python 
has no threads on the Mac.  When asked why they thought that, they pointed to 
this:   http://www.python.org/doc/essays/threads.html

This essay is undated and unsigned, and is out of date.  It should be removed 
from the site, or significantly edited, or at least marked at the top as "For 
Historical Interest Only."

--
components: None
messages: 180355
nosy: nedbat
priority: normal
severity: normal
status: open
title: "Thread Programming With Python" should be removed

___
Python tracker 

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

[issue17007] logging documentation clarifications

[Vinay Sajip]

Vinay Sajip added the comment:

Your suggestions are good, and I implemented them more or less as you 
suggested. Additional comments:

> it never makes sense to add more than one filter

Except for readability. Although in theory one filter could do the work of 
several, it may be that different filters are added independently from 
configurations based on particular requirements.

> Clarify that a handler can log the same record multiple times

I've mentioned this as *emit* the same record multiple times.

> Incidentally, is there any case where you would want the same handler to 
> process the same record more than once?

I can't think why you'd ever want this - it would just duplicate information in 
the log output.

> Clarify in the LogRecord section that the "name" attribute refers to the name 
> of the logger used in the end-user's code

I think that part is clear enough by saying that it's the name of the logger 
used to log the event, but I've added a rider that this is so even when the 
event is emitted by a handler attached to an ancestor logger.

> Clarify the last part of this sentence: "Note that filters attached to 
> handlers are consulted ..."

Done, this should now be clearer.

--

___
Python tracker 

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

[issue16507] Patch selectmodule.c to support WSAPoll on Windows

[Richard Oudkerk]

Richard Oudkerk added the comment:

On 21/01/2013 7:00pm, Guido van Rossum wrote:
> Regarding your IOCP changes, that sounds pretty exciting. Richard,
> could you check those into the Tulip as a branch? (Maybe a new branch
> named 'iocp'.)

OK.  It may take me a while to rebase them.

--

___
Python tracker 

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

[issue17007] logging documentation clarifications

[Roundup Robot]

Roundup Robot added the comment:

New changeset 871519e1f146 by Vinay Sajip in branch '2.7':
Issue #17007: Improved logging documentation based on suggestions in the issue.
http://hg.python.org/cpython/rev/871519e1f146

New changeset 029785354dbc by Vinay Sajip in branch '3.2':
Issue #17007: Improved logging documentation based on suggestions in the issue.
http://hg.python.org/cpython/rev/029785354dbc

New changeset 1902e86dbb88 by Vinay Sajip in branch '3.3':
Issue #17007: Merged doc update from 3.2.
http://hg.python.org/cpython/rev/1902e86dbb88

New changeset 6110ed94f86d by Vinay Sajip in branch 'default':
Closes #17007: Merged doc update from 3.3.
http://hg.python.org/cpython/rev/6110ed94f86d

--
nosy: +python-dev
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

[issue17008] Descriptor __get__() invoke is bypassed in the class context

[Benjamin Peterson]

Benjamin Peterson added the comment:

If you want to emulate classmethod, calling __get__() on the function is the 
wrong thing to do. f.__get__(None, X) -> f You need to create a bound yourself 
instead.

--
nosy: +benjamin.peterson
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

[issue16507] Patch selectmodule.c to support WSAPoll on Windows

[Guido van Rossum]

Guido van Rossum added the comment:

Thanks -- I am now close to rejecting the WSAPoll() patch, and even
closer to rejecting its use for Tulip on Windows. That would in turn
mean that we should kill add/remove_connector() and also the
EVENT_CONNECT flag in selector.py. Anyone not in favor please speak
up!

Regarding your IOCP changes, that sounds pretty exciting. Richard,
could you check those into the Tulip as a branch? (Maybe a new branch
named 'iocp'.)

--

___
Python tracker 

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

[issue16507] Patch selectmodule.c to support WSAPoll on Windows

[Richard Oudkerk]

Richard Oudkerk added the comment:

On 21/01/2013 5:38pm, Guido van Rossum wrote:
> This is a very good question to which I have no good answer.
> If it weren't for this, we could probably do away with the distinction
> between add_writer and add_connector, and a lot of code could be
> simpler.  (Or is that distinction also needed for IOCP?)

The distinction is not needed by IOCP.  I am also not too sure that 
running tulip on WSAPoll() is a good idea, even if the select module 
provides it.

OFF-TOPIC: Although it is not the optimal way of running tulip with 
IOCP, I have managed to implement IocpSelector and IocpSocket classes 
well enough to pass tulip's unittests (except for the ssl one).

I did have to make some changes to the tests: selectors have a 
wrap_socket() method which prepares a socket for use with the selector. 
  On Unix it just returns the socket unchanged, whereas for IocpSelector 
it returns an IocpSocket wrapper.

I also had to make the unittests behave gracefully if there is a 
"spurious wakeup", i.e. the socket is reported as readable, but trying 
to read fails with BlockingIOError.  (Spurious wakeups are possible but 
very rare with select() etc.)

It would be possible to make IocpSelector deal with pipe handles too.

--

___
Python tracker 

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

[issue16335] Integer overflow in unicode-escape decoder

[Roundup Robot]

Roundup Robot added the comment:

New changeset ec3a35ab3659 by Serhiy Storchaka in branch '2.7':
Add bigmemtest decorator to test of issue #16335.
http://hg.python.org/cpython/rev/ec3a35ab3659

New changeset 6e0c3e4136b1 by Serhiy Storchaka in branch '3.2':
Add bigmemtest decorator to test of issue #16335.
http://hg.python.org/cpython/rev/6e0c3e4136b1

New changeset 0e622d2cbcf8 by Serhiy Storchaka in branch '3.3':
Use bigmemtest decorator for test of issue #16335.
http://hg.python.org/cpython/rev/0e622d2cbcf8

New changeset cdd1e60d31e5 by Serhiy Storchaka in branch 'default':
Use bigmemtest decorator for test of issue #16335.
http://hg.python.org/cpython/rev/cdd1e60d31e5

--

___
Python tracker 

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

[issue17004] Expand zipimport to include other compression methods

[Brett Cannon]

Brett Cannon added the comment:

So this seems like a confluence of both supporting compressed files for loading 
source code as well as supporting new archive formats (e.g. xz vs. tar); zip 
just happens to do both implicitly. And there is also the question of if you 
explicitly plan to do this in C code or in pure Python as I plan to introduce a 
pure Python version of zipimport into importlib for 3.4 so that it can use 
zipfile directly and thus all of its full support of zipfile abilities.

And there doesn't have to be any performance cost in trying to write bytecode 
files; it's very simple to have a loader which simply skips that step entirely.

--
nosy: +brett.cannon

___
Python tracker 

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

[issue17008] Descriptor __get__() invoke is bypassed in the class context

[stuart]

New submission from stuart:

I emulated a real classmethod using python:

class cm(object):
def __init__(self, o):
self.o = o
def __get__(self, obj, type=None):
return self.o.__get__(obj, type)

then I check whether it is workable in the interactive mode and it is working:

Python 2.7.3 (default, Sep 26 2012, 21:53:58) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo(cls):
... print cls
... 
>>> cm = cm(foo)
>>> cm.__get__(int, type)
>

then I tried it in the real class but it failed:

>>> class C(object):
... @cm
... def foo(cls):
... print cls
... 
>>> C.foo


--
components: None
messages: 180346
nosy: Stuart
priority: normal
severity: normal
status: open
title: Descriptor __get__() invoke is bypassed in the class context
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

[issue16507] Patch selectmodule.c to support WSAPoll on Windows

[Guido van Rossum]

Guido van Rossum added the comment:

This is a very good question to which I have no good answer.  If it weren't for 
this, we could probably do away with the distinction between add_writer and 
add_connector, and a lot of code could be simpler.  (Or is that distinction 
also needed for IOCP?)

--

___
Python tracker 

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

[issue17007] logging documentation clarifications

[Chris Jerdonek]

New submission from Chris Jerdonek:

Here are some suggestions of things to clarify in the logging documentation 
after consulting it as an end-user:

1. Clarify in Logger.filter(), Handler.filter(), and probably also in the 
Filter section that the case of more than filter behaves as follows: filters 
are applied until a filter says the record should not be processed.  In 
particular, a record gets processed only if all filters say it should be 
processed rather than at least one.

This is especially worth clarifying because with the above behavior combined 
with the Filter class's default behavior, it never makes sense to add more than 
one filter (because you can replace a group of filters with their lowest common 
ancestor).  It's only needed with custom filters.

2. Clarify that a handler can log the same record multiple times if it is 
attached to an ancestor logger.  This clarification perhaps best goes in the 
Logger.propagate section.  Currently, it's not clear whether loggers/handlers 
are "smart" in the sense that they keep track of whether a given message has 
already been passed to a given handler (independent of what loggers it is 
attached to): "Logger.propagate: If this evaluates to true, logging messages 
are passed by this logger and by its child loggers to the handlers of higher 
level (ancestor) loggers."

Incidentally, is there any case where you would want the same handler to 
process the same record more than once?

3. Clarify in the LogRecord section that the "name" attribute refers to the 
name of the logger used in the end-user's code rather than the name of the 
logger handling the message.  In particular, a record logged by a logger and an 
ancestor logger will have the same "name" field for both.

4. Clarify the last part of this sentence: "Note that filters attached to 
handlers are consulted whenever an event is emitted by the handler, whereas 
filters attached to loggers are consulted whenever an event is logged to the 
handler (using debug(), info(), etc.)"

It should say something like, "whereas filters attached to loggers are 
consulted prior to sending an event to its handlers."  In particular, there can 
be more than one handler, and it happens before rather than after being logged 
to the handlers ("whenever" is somewhat ambiguous).

--
assignee: docs@python
components: Documentation
keywords: easy
messages: 180344
nosy: chris.jerdonek, docs@python, vinay.sajip
priority: normal
severity: normal
status: open
title: logging documentation clarifications
type: enhancement

___
Python tracker 

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

[issue16998] Lost updates with multiprocessing.Value

[Jens Lechtenboerger]

Jens Lechtenboerger added the comment:

> It only says that accesses are synchronized.  The problem is that you were 
> assuming that "+=" involves a single access -- but that is not how python 
> works.

Yes, I understand that by now (actually since your first comment).

> Where in the examples is there "non-process-safe" access?  (Note that waiting 
> for the only process which modifies a value to terminate using join() will 
> prevent races.)

In section "The multiprocessing.sharedctypes module" the assignments in the 
first example (function modify()) are unsafe.  None of them is protected by a 
lock as suggested in your first comment.  Strictly speaking, no lock is 
necessary in the example as there are no race conditions (the processes work in 
an alternating fashion without concurrency).

I certainly did not see that the example (for a *shared* memory data structure) 
is based on the implicit assumption of a single writer.  In contrast, I assumed 
that some "magic" should offer process-safe usage of "+=", which made me file 
this bug.  That assumption has turned out to be wrong.  To prevent others from 
being mislead in the same way I suggest to either protect those operations with 
locks (and comment on their effect) or to state the implicit assumption 
explicitly.

Maybe add the following after "Below is an example where a number of ctypes 
objects are modified by a child process:"
Note that assignments such n.value **= 2 are not executed atomically but 
involve two operations, a load followed by a store.  Each of these operations 
is protected by the Value's lock, which is dropped in between.  Thus, in 
scenarios with concurrent modifying processes you may want to explicitly 
acquire the Value's lock to ensure atomic execution (avoiding race conditions 
and lost updates), e.g.:
with n.get_lock():
n.value **= 2

--

___
Python tracker 

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

[issue16699] Mountain Lion buildbot lacks disk space

[Ramchandra Apte]

Ramchandra Apte added the comment:

Invalid.

--
nosy: +ramchandra.apte

___
Python tracker 

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

[issue17006] Warn users about hashing secrets?

[Andrew Svetlov]

Changes by Andrew Svetlov :


--
nosy: +asvetlov

___
Python tracker 

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

[issue17006] Warn users about hashing secrets?

[Ramchandra Apte]

Ramchandra Apte added the comment:

+1
"Better to be safe than sorry"

--
nosy: +ramchandra.apte

___
Python tracker 

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

[issue17001] Make uuid.UUID use functools.total_ordering

[Ramchandra Apte]

Ramchandra Apte added the comment:

On 21 January 2013 02:42, Raymond Hettinger  wrote:

> NotImplemented

Can you please elaborate on "it doesn't handle the NotImplemented logic
very well".
AFAIK both will give NotImplemented for the same values.

--

___
Python tracker 

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

[issue17001] Make uuid.UUID use functools.total_ordering

[Ramchandra Apte]

Ramchandra Apte added the comment:

Performance info using the attached program:
~2.5 sec, original
~3.5 sec, patched
(patched version is 40% slower)
Is anybody doing the comparison in performance-critical cases?

--

___
Python tracker 

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

[issue16993] shutil.which() should preserve path case

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue16993] shutil.which() should preserve path case

[Roundup Robot]

Roundup Robot added the comment:

New changeset d2db601a53b3 by Serhiy Storchaka in branch '3.3':
Issue #16993: shutil.which() now preserves the case of the path and extension
http://hg.python.org/cpython/rev/d2db601a53b3

New changeset 5faae2bdf1e0 by Serhiy Storchaka in branch 'default':
Issue #16993: shutil.which() now preserves the case of the path and extension
http://hg.python.org/cpython/rev/5faae2bdf1e0

--
nosy: +python-dev

___
Python tracker 

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

[issue16993] shutil.which() should preserve path case

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka

___
Python tracker 

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

[issue16822] execv (et al.) should invoke atexit handlers before executing new code

[Antoine Pitrou]

Antoine Pitrou added the comment:

I agree with Charles-François, this is a too risky change.
However, we could definitely have a separate "atexec" handler, like the 
"atfork" handlers which are proposed in issue16500.

--

___
Python tracker 

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

[issue16041] poplib: unlimited readline() from connection

[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

[issue16040] nntplib: unlimited readline() from connection

[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

[issue16039] imaplib: unlimited readline() from connection

[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

[issue16042] smtplib: unlimited readline() from connection

[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

[issue16038] ftplib: unlimited readline() from connection

[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

[issue17006] Warn users about hashing secrets?

[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

[issue16335] Integer overflow in unicode-escape decoder

[Roundup Robot]

Roundup Robot added the comment:

New changeset f84a6c89ccbc by Serhiy Storchaka in branch '3.2':
Fix memory error in test_ucn.
http://hg.python.org/cpython/rev/f84a6c89ccbc

New changeset 7c2aae472b27 by Serhiy Storchaka in branch '3.3':
Fix memory error in test_ucn.
http://hg.python.org/cpython/rev/7c2aae472b27

New changeset f90d6ce49772 by Serhiy Storchaka in branch 'default':
Fix memory error in test_ucn.
http://hg.python.org/cpython/rev/f90d6ce49772

New changeset 38a10d0778d2 by Serhiy Storchaka in branch '2.7':
Fix memory error in test_ucn.
http://hg.python.org/cpython/rev/38a10d0778d2

--

___
Python tracker 

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

[issue16957] shutil.which() shouldn't look in working directory on unix-y systems

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

LGTM.

--

___
Python tracker 

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

[issue16335] Integer overflow in unicode-escape decoder

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I rewrote the test in EAFP style.

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

[issue16335] Integer overflow in unicode-escape decoder

[Roundup Robot]

Roundup Robot added the comment:

New changeset f4d30d1a529e by Serhiy Storchaka in branch '2.7':
Issue #16335: Fix integer overflow in unicode-escape decoder.
http://hg.python.org/cpython/rev/f4d30d1a529e

--

___
Python tracker 

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

[issue16335] Integer overflow in unicode-escape decoder

[Roundup Robot]

Roundup Robot added the comment:

New changeset 7625866f8127 by Serhiy Storchaka in branch '3.2':
Issue #16335: Fix integer overflow in unicode-escape decoder.
http://hg.python.org/cpython/rev/7625866f8127

New changeset 494d341e9143 by Serhiy Storchaka in branch '3.3':
Issue #16335: Fix integer overflow in unicode-escape decoder.
http://hg.python.org/cpython/rev/494d341e9143

New changeset 8488febf7d79 by Serhiy Storchaka in branch 'default':
Issue #16335: Fix integer overflow in unicode-escape decoder.
http://hg.python.org/cpython/rev/8488febf7d79

--
nosy: +python-dev

___
Python tracker 

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

[issue17006] Warn users about hashing secrets?

[Ezio Melotti]

Changes by Ezio Melotti :


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

___
Python tracker 

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

[issue17006] Warn users about hashing secrets?

[Hynek Schlawack]

Hynek Schlawack added the comment:

I think since we ship cryptographic functions, we should take responsibility 
and warn against the most common mistakes people do.

--
nosy: +hynek

___
Python tracker 

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

[issue17006] Warn users about hashing secrets?

[Christian Heimes]

New submission from Christian Heimes:

Lot's of people still think that something like sha512(secret + message), 
sha1(password + salt) or even sha1(password) is secure. Except it isn't. Most 
crypto hash functions like md5, sha1, sha2 family (sha256, sha384, sha512) use 
a Merkle–Damgård construction [1]. The construction is vulnerable to several 
attack vectors like length extension attacks. Passwords needs special care, too.

I propose we add a warning to the documentation of hashlib. It's not the right 
place to teach cryptographics but it's a good place to raise attention. The 
warning should explain that you shouldn't solely hash secrets or messages 
containing a secret. For messages a MAC algorithm like HMAC should be used. For 
passwords a key stretching and key derivation function like PBKDF2, bcrypt or 
scrypt is much more secure.

[1] http://en.wikipedia.org/wiki/Merkle%E2%80%93Damg%C3%A5rd_construction

--
assignee: docs@python
components: Documentation
messages: 180330
nosy: christian.heimes, docs@python
priority: normal
severity: normal
status: open
title: Warn users about hashing secrets?
type: enhancement
versions: Python 2.7, 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