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

[Ezio Melotti]

Changes by Ezio Melotti :


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

___
Python tracker 

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

[issue9253] argparse: optional subparsers

[Éric Araujo]

Éric Araujo  added the comment:

You should work in the 3.3 standard library, i.e. on Lib/argparse.py in the 
default branch of the CPython Mercurial repository.  See the devguide for more 
info.  Thanks!

--

___
Python tracker 

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

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

[Devin Jeanpierre]

Devin Jeanpierre  added the comment:

> IMO, help('help') should document the help function, not start an interactive 
> help session (that’d be help()).

Ahhh, that explains it. help('help') isn't ever meant to be called; it's 
supposed to be:

>>> help()
...
help> help
...

the call to "help" at the help> prompt is equivalent to help('help').


help('help') should do something different, such as say how to use the help 
function, as you say. Whereas "help> help" makes sense.

--

___
Python tracker 

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

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

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The code works fine on 3.2.2, Win7, IDLE, narrowest window possible (about 14 
chars), which actually wraps to the window width. (In command window, lines are 
fixed length and scroll bar is added if window is narrowed.) What system and 
version are you running? 

The error directly comes from textwrap. In the other hand, textwrap.wrap works 
with widths down to 1 (on 3.2.2), which suggests that argparse is calling it 
wrong. Except that it is not on my system. 

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

--
nosy: +bethard, georg.brandl, terry.reedy

___
Python tracker 

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

[issue13724] socket.create_connection and multiple IP addresses

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> http://docs.python.org/release/2.7.2/library/socket#socket.create_connection 
> doesn't describe how it loops over all IP addresses. That seems to be the 
> functions main advantage (and a gotcha) compared to creating the socket and 
> connecting directly.

Well the main advantage is that it makes it much easier to write clients
supporting both IPv4 and IPv6.

--

___
Python tracker 

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

[issue13721] ssl.wrap_socket on a connected but failed connection succeeds and .peer_certificate gives AttributeError

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I hope the proper fix will ensure that an exception always is raised
> if the ssl handshake fails - and that a successful wrap_socket means
> that the ssl negotiation did succeed with the given constraints. It
> might however only be feasible to fix that for 3.x.

Actually, the handshake is not even attempted because getpeername()
returns ENOTCONN, which is interpreted as meaning "the socket hasn't
been connected yet". Any idea how to improve that?

(I find it strange that ENOTCONN is returned rather than say ECONNRESET)

--

___
Python tracker 

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

[issue13692] 2to3 mangles from . import frobnitz

[Terry J. Reedy]

Terry J. Reedy  added the comment:

If this is fixed in 3.2, can this be closed?

--
nosy: +terry.reedy

___
Python tracker 

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

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

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I agree. It should explain the three options:
help(object): help on object or class of object, except
help('name'): help on object/module named 'name'
help(): run utility, which starts with utility help

help(help) prints unhelpful
"Help on _Helper in module site object:

class _Helper(builtins.object)
 |  Define the builtin 'help'.
 |  This is a wrapper around pydoc.help (with a twist).
 |  
 |  Methods defined here:
...
"
which says not at all how to use help().

I have the feeling that there is a related issue on the tracker, but searching 
for 'help', 'help()', or 'help(help)' all return 620 hits.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue13686] Some notes on the docs of multiprocessing

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
nosy: +jnoller

___
Python tracker 

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

[issue13685] argparse does not sanitize help strings for % signs

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
nosy: +bethard

___
Python tracker 

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

[issue13722] "distributions can disable the encodings package"

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Agreed.  This behavior probably comes from the times when unicode was an 
optional feature.

--

___
Python tracker 

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

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

[Zbyszek Szmek]

Zbyszek Szmek  added the comment:

>> - fd argument is retained, because we might want to test terminals
>>  opened with openpty.
>
> You mean a terminal different than the one used for stdin, stdout and 
> stderr?

For example, let's see what is the size of my two xterms:

>>> os.get_terminal_size_raw()
os.terminal_size(columns=125, rows=39)
>>> fd = os.open('/proc/22736/fd/1', os.O_RDONLY)
>>> fd
6
>>> os.get_terminal_size_raw(6)
os.terminal_size(columns=95, rows=33)

I'm not saying that this serves a clear purpose, but it is possible
and it is good not the restrain the API. I'm sure somebody could find
a use for it.

>> - two functions: still there. I think that get_terminal_size() should
>>  provide an easy-to-use, even trivial-to-use, way to get a sensible
>>  value without writing a wrapper. In the _majority_ of cases the
>>  wrapper would be something like get_terminal_size() currently.
>
> get_terminal_size() looks like [less?] reliable than raw_get_terminal_size()
> because environment variables are not updated when the terminal is
> resized.
Please look at my comment above: http://bugs.python.org/issue13609#msg149620
$COLUMNS is only used for overriding -- it normally _isn't_ set.

--

___
Python tracker 

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

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

[STINNER Victor]

STINNER Victor  added the comment:

> - fd argument is retained, because we might want to test terminals
>  opened with openpty.

You mean a terminal different than the one used for stdin, stdout and stderr?

> - two functions: still there. I think that get_terminal_size() should
>  provide an easy-to-use, even trivial-to-use, way to get a sensible
>  value without writing a wrapper. In the _majority_ of cases the
>  wrapper would be something like get_terminal_size() currently.

get_terminal_size() looks like reliable than raw_get_terminal_size()
because environment variables are not updated when the terminal is
resized.

--

___
Python tracker 

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

[issue13511] Specifying multiple lib and include directories on linux

[Martin v . Löwis]

Martin v. Löwis  added the comment:

No, I only read the original message. I find it too tedious to read the entire 
set of messages just to find out what the issue may be. If an issue has 
sufficiently deviated from the original report, it is better closed, and a new 
issue is opened.

Even after scanning the messages, I still cannot figure out what the issue is. 
Your last message is particularly mysterious to me.

So if you think there still is an issue, please report a new one. Make sure to 
include reproducable test cases, and a clear statement of what you expected to 
happen (in addition to reporting what actually happened).

--

___
Python tracker 

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

[issue13721] ssl.wrap_socket on a connected but failed connection succeeds and .peer_certificate gives AttributeError

[Mads Kiilerich]

Mads Kiilerich  added the comment:

I think it would be confusing if getpeercert returned None both for valid 
connections without certificates and also for invalid connections. I would 
almost prefer the current behaviour (AttributeError) if just it was documented 
and there was a documented way to check if the connection actually was alive. 
Do you agree that checking .cipher() is the recommended way to do that in a way 
that is compatible with past and future 2.x versions?

I hope the proper fix will ensure that an exception always is raised if the ssl 
handshake fails - and that a successful wrap_socket means that the ssl 
negotiation did succeed with the given constraints. It might however only be 
feasible to fix that for 3.x.

I filed Issue13724 for the create_socket documentation.

--

___
Python tracker 

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

[issue13724] socket.create_connection and multiple IP addresses

[Mads Kiilerich]

New submission from Mads Kiilerich :

Forked from issue13721 where I was too lazy to report it separately:

http://docs.python.org/release/2.7.2/library/socket#socket.create_connection 
doesn't describe how it loops over all IP addresses. That seems to be the 
functions main advantage (and a gotcha) compared to creating the socket and 
connecting directly.

I propose to warn that it might "hang" up to n*timeout before anything happens 
with something like this in documentation and docstring:

... and return the socket object.
If the host resolves to multiple IP addresses then they will all be tried in 
turn until one of them succeeds.
Passing the optional timeout parameter will set the timeout on the socket 
instance before each attempt to connect.
If no ...

--
assignee: docs@python
components: Documentation
messages: 150772
nosy: docs@python, kiilerix, pitrou
priority: normal
severity: normal
status: open
title: socket.create_connection and multiple IP addresses
type: enhancement
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

[issue13703] Hash collision security issue

[Stefan Krah]

Changes by Stefan Krah :


--
nosy: +skrah

___
Python tracker 

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

[issue13703] Hash collision security issue

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I'm in cautious agreement that collision counting is a better
> strategy.

Disagreed. Raising randomly is unacceptable (false positives), especially in a 
bugfix release.

> The dict implementation performance would suffer from
> randomization.

Benchmarks please. http://hg.python.org/benchmarks/ for example.

--

___
Python tracker 

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

[issue13723] Regular expressions: (?:X|\s+)*$ takes a long time

[Alex Gaynor]

Changes by Alex Gaynor :


--
nosy: +alex

___
Python tracker 

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

[issue13723] Regular expressions: (?:X|\s+)*$ takes a long time

[Eric Promislow]

New submission from Eric Promislow :

This regular expression takes a few seconds to be evaluated
against any text:

(.*?)((?:X|\s+)*)$

This reg ex is much faster:

(.*?)((?:X|\s)*)$

To be fair, Ruby's performance with the first regex is the same as Python's. 
PHP and JavaScript both fail to match the first regex
at all.  Only Perl evaluates both regexes nearly instantly.

--
messages: 150770
nosy: ericp
priority: normal
severity: normal
status: open
title: Regular expressions: (?:X|\s+)*$ takes a long time
type: performance
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

[issue13703] Hash collision security issue

[Paul McMillan]

Paul McMillan  added the comment:

> An attack can be based on trying to find many objects with the same
> hash value, or trying to find many objects that, as they get inserted
> into a dictionary, very often cause collisions due to the collision
> resolution algorithm not finding a free slot.

Yep. Allowing an attacker to produce very large dictionaries is also bad.

> if the application
> puts too much trust into large blobs of input data - which is
> the actual security issues we're trying to work around here...

To be very clear the issue is ANY large blob of data anywhere in the
application, not just on input. An attack could happen after whatever
transform your application runs on the data before returning it.

> I'll upload a patch that demonstrates the collisions counting
> strategy to show that detecting the problem is easy. Whether
> just raising an exception is a good idea, is another issue.

I'm in cautious agreement that collision counting is a better
strategy. The dict implementation performance would suffer from
randomization.

> The dict implementation could then alter the hash parameter
> and recreate the dict table in case the number of collisions
> exceeds a certain limit, thereby actively taking action
> instead of just relying on randomness solving the issue in
> most cases.

This is clever. You basically neuter the attack as you notice it but
everything else is business as usual. I'm concerned that this may end
up being costly in some edge cases (e.g. look up how many collisions
it takes to force the recreation, and then aim for just that many
collisions many times). Unfortunately, each dict object has to
discover for itself that it's full of offending hashes. Another
approach would be to neuter the offending object by changing its hash,
but this would require either returning multiple values, or fixing up
existing dictionaries, neither of which seems feasible.

--

___
Python tracker 

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

[issue13703] Hash collision security issue

[Terry J. Reedy]

Terry J. Reedy  added the comment:

"You're suggesting that in order for a Python application to be secure,
it's a requirement that we randomly kill and restart processes from
time to time?"

No, that is not what I said.

--

___
Python tracker 

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

[issue13703] Hash collision security issue

[Pavel Labushev]

Changes by Pavel Labushev :


--
nosy: +Arach

___
Python tracker 

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

[issue13722] "distributions can disable the encodings package"

[Antoine Pitrou]

New submission from Antoine Pitrou :

In _PyCodecRegistry_Init() (in Python/codecs.c), it is attempted to import the 
encodings module (so that the default search function gets registered) and 
failures get ignored following the same reasoning:

/* Ignore ImportErrors... this is done so that
   distributions can disable the encodings package. Note
   that other errors are not masked, e.g. SystemErrors
   raised to inform the user of an error in the Python
   configuration are still reported back to the user. */

However, it is unlikely for Python 3 to start up at all without an encodings 
package (we needs some codecs to initialize stdio). Also, I'm not sure what the 
point would be. Distributions can simply distribute a dummy encodings module if 
they really want to disable the default encodings.
Not silencing the error would probably make it easier to diagnose early import 
issues.

--
components: Interpreter Core
messages: 150767
nosy: amaury.forgeotdarc, loewis, pitrou
priority: low
severity: normal
status: open
title: "distributions can disable the encodings package"
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

[issue13703] Hash collision security issue

[Paul McMillan]

Paul McMillan  added the comment:

> Those who use or advocate a simple randomized starting hash (Perl, Ruby, 
> perhaps MS, and the CCC presenters) are presuming that the randomized hash 
> values are kept private. Indeed, they should be (and the docs could note 
> this) unless an attacker has direct access to the interpreter.

Except that this is patently untrue. Anytime any programmer iterates
over a dictionary and returns the ordered result to the user in some
form, they're leaking information about the hash value. I hope you're
not suggesting that any programmer who is concerned about security
will make sure to sort the results of every iteration before making it
public in some fashion.

> I do not think we, as Python developers, should be concerned about esoteric 
> timing attacks.

Timing attacks are less esoteric than you think they are. This issue
gets worse, not better, as the internet moves (for better or worse)
towards virtualized computing.

> And if hashing were randomized per process, and probes were randomly 
> distributed among processes, and processes were periodically killed and 
> restarted with new seeds, could such an attack get anywhere...

You're suggesting that in order for a Python application to be secure,
it's a requirement that we randomly kill and restart processes from
time to time? I thought we were going for a good solution here, not a
hacky workaround.

> We could also consider, for 3.3, making the output of hash() be different 
> from the internal values used for dicts, perhaps by switching random seeds in 
> hash(). So even if someone does return hash(x) values to potential attackers, 
> they are not the values used in dicts. (This would require a slight change in 
> the doc.)

This isn't a bad idea, but I'd be fine documenting that the output of
hash() shouldn't be made public.

--

___
Python tracker 

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

[issue13555] cPickle MemoryError when loading large file (while pickle works)

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Le vendredi 06 janvier 2012 à 19:17 +, Charles-François Natali a
écrit :
> Charles-François Natali  added the comment:
> 
> Antoine, could you test the last version (test_pickle and if possible
> with the OP testcase)?
> I can't test it myself (32-bit machine with 1 GB).

Well, first, there are compilation warnings on a 64-bit box:

gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes 
-I. -IInclude -I./Include -I/usr/local/include 
-I/home/antoine/cpython/27/Include -I/home/antoine/cpython/27 -c 
/home/antoine/cpython/27/Modules/cPickle.c -o 
build/temp.linux-x86_64-2.7-pydebug/home/antoine/cpython/27/Modules/cPickle.o
/home/antoine/cpython/27/Modules/cPickle.c: In function ‘put2’:
/home/antoine/cpython/27/Modules/cPickle.c:810:9: attention : format ‘%d’ 
expects type ‘int’, but argument 4 has type ‘Py_ssize_t’
/home/antoine/cpython/27/Modules/cPickle.c: In function ‘load_mark’:
/home/antoine/cpython/27/Modules/cPickle.c:4610:21: attention : assignment from 
incompatible pointer type
gcc -pthread -shared 
build/temp.linux-x86_64-2.7-pydebug/home/antoine/cpython/27/Modules/cPickle.o 
-L/usr/local/lib -o build/lib.linux-x86_64-2.7-pydebug/cPickle.so

Second, I can't seem to get the test to work with 8GB RAM (approximately
6.5GB free according to "free"). The MemoryError is quite expectable for
test_pickle, though, since the code there doesn't try to conserve memory
at all:

test test_pickle failed -- Traceback (most recent call last):
  File "/home/antoine/cpython/27/Lib/test/test_support.py", line 983, in wrapper
return f(self, maxsize)
  File "/home/antoine/cpython/27/Lib/test/pickletester.py", line 1298, in 
test_huge_str_32b
pickled = self.dumps(data, proto)
  File "/home/antoine/cpython/27/Lib/test/test_pickle.py", line 74, in dumps
return pickle.dumps(arg, proto)
  File "/home/antoine/cpython/27/Lib/pickle.py", line 1374, in dumps
Pickler(file, protocol).dump(obj)
  File "/home/antoine/cpython/27/Lib/pickle.py", line 224, in dump
self.save(obj)
  File "/home/antoine/cpython/27/Lib/pickle.py", line 286, in save
f(self, obj) # Call unbound method with explicit self
  File "/home/antoine/cpython/27/Lib/pickle.py", line 488, in save_string
self.write(STRING + repr(obj) + '\n')
MemoryError

I would therefore suggest to enable the test only for cPickle.
For test_cpickle the behaviour is different:
- for protocol 0, I get a MemoryError (which may be expected, if the
test truly needs more than 6.5GB, for example because of suboptimal
buffer management)
- for protocol 1 and 2, I get "SystemError: error return without
exception set"

--

___
Python tracker 

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

[issue9993] shutil.move fails on symlink source

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Patch now committed to 3.3. Thank you Jonathan and Hynek!

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

[issue9993] shutil.move fails on symlink source

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 1ea8b7233fd7 by Antoine Pitrou in branch 'default':
Issue #9993: When the source and destination are on different filesystems,
http://hg.python.org/cpython/rev/1ea8b7233fd7

--
nosy: +python-dev

___
Python tracker 

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

[issue13555] cPickle MemoryError when loading large file (while pickle works)

[Charles-François Natali]

Charles-François Natali  added the comment:

Antoine, could you test the last version (test_pickle and if possible
with the OP testcase)?
I can't test it myself (32-bit machine with 1 GB).

--

___
Python tracker 

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

[issue1521950] shlex.split() does not tokenize like the shell

[Vinay Sajip]

Changes by Vinay Sajip :


Added file: http://bugs.python.org/file24158/9e12275eec25.diff

___
Python tracker 

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

[issue1521950] shlex.split() does not tokenize like the shell

[Vinay Sajip]

Vinay Sajip  added the comment:

I've made a patch which implements this functionality, together with docs and 
tests. Please review.

--
hgrepos: +99
nosy: +vinay.sajip
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

[issue13562] Notes about module load path

[Nam Nguyen]

Nam Nguyen  added the comment:

Please do keep the warning though. It is best to warn in both Python-C 
Py_Initialize() document and the Embedding tutorial.

--

___
Python tracker 

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

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

[Zbyszek Szmek]

Zbyszek Szmek  added the comment:

> Some remarks on the Windows implementation in termsize.diff.4:

> - On Windows, the C runtime always sets fileno(stdout) to 1, so
> hardcoded values are OK.
> But on Unix, I'm quite sure that embedded interpreters (mod_python?) 
> sometimes close the standard descriptor, so fd=1 can refer to 
> something entirely different.
> Does it makes sense to initialize fd=fileno(stdout) (this is C code) 
> instead?
OK, I agree that fd=fileno(stdout) is better. Now it matches the docstring 
which says "defaults to stdout" better.

> - When GetStdHandle() returns INVALID_HANDLE_VALUE, 
> PyErr_SetFromWindowsErr(0) should be used.
OK.
> And it's not necessary to use GetLastError(), 0 is enough.
OK, good no know.

> - GetStdHandle will return NULL in a non-console application (try 
> with pythonw.exe or IDLE), I think a specific error message should be 
> raised in this case.
OK. I tried and I see that the GetStdHandle documentation says so, but
I couldn't get it to return NULL. Nevertheless, I added a check:
+if (handle == NULL)
+return PyErr_Format(PyExc_OSError, "stdout not connected");

Thanks for the review!

Updated: termsize.diff.5

--
Added file: http://bugs.python.org/file24157/termsize.diff.5

___
Python tracker 

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

[issue13719] bdist_msi upload fails

[Brian Curtin]

Changes by Brian Curtin :


--
components: +Windows
nosy: +brian.curtin
type:  -> behavior

___
Python tracker 

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

[issue13562] Notes about module load path

[Eric Snow]

Changes by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue9253] argparse: optional subparsers

[Benjamin West]

Benjamin West  added the comment:

Ok, Steven, that sounds reasonable.

I checked out git-svn python and started comparing diffs... I'm a little 
confused.  What version of argparse should be patched to provide this feature?

My HG version from https://code.google.com/p/argparse/ seems to contain a 
version of argparse 1.2 while, my git-svn checkout of python seems to contain 
an argparse 1.1.  Should I attempt to bring cpython's version up to date as 
well, or attempt to strip out the version bump changes?

--

___
Python tracker 

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

[issue9253] argparse: optional subparsers

[Benjamin West]

Benjamin West  added the comment:

Ok, Steven, that sounds reasonable.

I checked out git-svn python and started comparing diffs... I'm a little 
confused.  What version of argparse should be patched to provide this feature?

My HG version from https://code.google.com/p/argparse/ seems to contain a 
version of argparse 1.2 while, my git-svn checkout of python seems to contain 
an argparse 1.1.  Should I attempt to bring cpython's version up to date as 
well, or attempt to strip out the version bump changes?

--

___
Python tracker 

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

[issue13703] Hash collision security issue

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Here's an example of hash-attack.patch finding an on-purpose
programming error (hashing all objects to the same value):

http://stackoverflow.com/questions/4865325/counting-collisions-in-a-python-dictionary
(see the second example on the page for @Winston Ewert's solution)

With the patch you get:

Traceback (most recent call last):
  File "testcollisons.py", line 20, in 
d[o] = 1
KeyError: 'too many hash collisions'

--

___
Python tracker 

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

[issue13721] ssl.wrap_socket on a connected but failed connection succeeds and .peer_certificate gives AttributeError

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Alternatively all SSLSocket methods should take care not to dereference 
> self._sslobj and they should respond properly - preferably with a
> socket/ssl exception.

In getpeercert()'s case, I think None would be the right thing to return (as 
cipher() and compression() already do).
But, yes, this deserves fixing.

> One good(?) reason to wrap connected sockets is to be able to use
> socket.create_connection which tries all IP adresses of a fqdn before
> it fails. (Btw: That isn't described in the documentation! That
> confused me while debugging this.)

Which documentation? create_connection's? Feel free to propose an improved 
wording.

--
nosy: +pitrou
stage:  -> needs patch
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

[issue13721] ssl.wrap_socket on a connected but failed connection succeeds and .peer_certificate gives AttributeError

[Mads Kiilerich]

New submission from Mads Kiilerich :

According to http://docs.python.org/release/2.7.2/library/ssl wrap_socket can 
be used either on connected sockets or on un-connected sockets which then can 
be .connect'ed.

In the latter case SSLSocket.connect() will (AFAIK) always raise a nice 
exception if the connection fails before the ssl negotiation has completed.

But when an existing connected but failing socket is wrapped then 
SSLSocket.__init__ will create an instance with self._sslobj = None without 
negotiating ssl and without raising any exception. Many SSLSocket methods (such 
as .cipher) checks for self._sslobj, but for example .getpeercert doesn't and 
will derefence None. That can lead to spurious crashes in applications.

This problem showed up with Mercurial and connections from China to 
code.google.com being blocked by the Chinese firewall - see for example 
https://bugzilla.redhat.com/show_bug.cgi?id=771691 .

In that case

  import socket, ssl, time
  s = socket.create_connection(('code.google.com', 443))
  time.sleep(1)
  ssl_sock = ssl.wrap_socket(s)
  ssl_sock.getpeercert(True)

would fail with
  ...
  ssl_sock.getpeercert(True)
File "/usr/lib64/python2.7/ssl.py", line 172, in getpeercert
  return self._sslobj.peer_certificate(binary_form)
  AttributeError: 'NoneType' object has no attribute 'peer_certificate'

The problem occurs in the case where The Chinese Wall responds correctly to the 
SYN with SYN+ACK but soon after sends a RST. The sleep is necessary to 
reproduce it consistently; that makes sure the RST has been received and 
getpeername fails. Otherwise getpeername succeeds and the connection reset is 
only seen later on while negotiation ssl, and socket errors there are handled 
'correctly'.

The problem can be reproduced on Linux with
  iptables -t filter -A FORWARD -p tcp --dport 443 ! --tcp-flags SYN SYN -j 
REJECT --reject-with tcp-reset

I would expect that wrap_socket / SSLSocket.__init__ raised an exception if the 
wrapped socket has been connected but failed. Calling getpeername is 
insufficient to detect that (and it is too racy to be reliable).

Alternatively all SSLSocket methods should take care not to dereference 
self._sslobj and they should respond properly - preferably with a socket/ssl 
exception.

Alternatively the documentation should describe how all applications that wraps 
connected sockets has to verify that it actually was connected. Checking 
.cipher() is apparently currently the least ugly way to do that?

One good(?) reason to wrap connected sockets is to be able to use 
socket.create_connection which tries all IP adresses of a fqdn before it fails. 
(Btw: That isn't described in the documentation! That confused me while 
debugging this.)

I guess applications (like Mercurial) that for that reason wants to use 
create_connection with 2.7.2 and older should check .cipher() as a workaround?

--
components: Library (Lib)
messages: 150754
nosy: kiilerix
priority: normal
severity: normal
status: open
title: ssl.wrap_socket on a connected but failed connection succeeds and 
.peer_certificate gives AttributeError
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

[issue11473] upload command no longer accepts repository by section name

[Jason R. Coombs]

Jason R. Coombs  added the comment:

Windows symlinks, much like Unix symlinks, should dereference naturally when 
open is called, although there is a bug in later versions of the c runtime 
calling stat on a symlink. See issue6727 for details.

--
title: upload command no longer accepts repository by section name -> upload 
command no longer accepts repository by sectionname
Added file: http://bugs.python.org/file24156/smime.p7m

___
Python tracker 

___Content-Type: multipart/signed; micalg=sha1;
boundary="Apple-Mail-65462CE5-42F6-47A8-8F19-8E32853CCBD1";
protocol="application/pkcs7-signature"

--Apple-Mail-65462CE5-42F6-47A8-8F19-8E32853CCBD1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii

Windows symlinks, much like Unix symlinks, should dereference naturally when=
 open is called, although there is a bug in later versions of the c runtime c=
alling stat on a symlink. See issue6727 for details.=

--Apple-Mail-65462CE5-42F6-47A8-8F19-8E32853CCBD1
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVrjCCBjQw
ggQcoAMCAQICASIwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDMzM1oX
DTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeLZOVfItiuP1aRHL530E7QUc9icCwL33+P
H+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72jtzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+
PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBf
W/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBot
ehAX6DbDOuYoJtVxmGof6GuVGcPo98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcC
y3T8LvSs3DLl8zAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAABznBL1seNF
AhfG5hdukfQLzqsDJ452dB9CVqgUeTobh4x55PngizYKZ6+ieVlDtPd2MB7U2ck6L7tyMxMpvRoa
74Sokhl5ZgwTQZb7xB9rKoUPxygFX2biNm+r+l04+COmJGb02iLSPR9OFgqhk5qNK83IpT8QJD5V
XP7heTH3TdHGFWXimRYGXBmuVOXEpXYaZjn7syQuXr7k4RZuFp32FOzfzTBrZWDgixjJB+OJkMfp
yu6GvEXeYWrks+ILjHt78VUj8DHxB2i6JTkmA51vR181KEiAYtZbiDK21UgncNxEIeU3b0vhpE4c
KT5kcZaXFK58fLRthoHae6br4lQsZIMEbHhScnzH9uAg3qL7AGBILDwu6iasejOhkoSp6opZDeUS
UfEPE0tHwKFur3Ts1K52EyXBAr1aA67ECgL9ka2yPt1YA/mj7frpI9li/F311dn7+pHT1C3lFPRR
zOc6i9gAXjBOWJq+Yl0dSubTn2xVdS+swwfjR0uLWqoSH9Hra4sXDHxslb/KaDXJw8g1EvBzgP0Z
UHolzyrDgvwL/WOuLWek6koXP89CRPuWtC0iC/vZ4IcCgGuhniwYV4XhrdAW9FKlKdRi8SEBGYpV
QiCPVhC5wF2oQvsEs6szAThCuamfAmZnFCUBdCcVTXQuX/OXoQe4Fl70ePaZhjS6MIIHpTCCBo2g
AwIBAgICALswDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
MTExMjQwODIzMjZaFw0xMzExMjUwMTQ2NDBaMIGfMSAwHgYDVQQNExc1NzQwMDMtZENER0JlOGhC
NVQ1UTVWcjELMAkGA1UEBhMCVVMxHTAbBgNVBAgTFERpc3RyaWN0IG9mIENvbHVtYmlhMRMwEQYD
VQQHEwpXYXNoaW5ndG9uMRgwFgYDVQQDEw9KYXNvbiBSLiBDb29tYnMxIDAeBgkqhkiG9w0BCQEW
EWphcmFjb0BqYXJhY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtIz2vssW
Ao03XQ0a/2nhvrtEXgzBiIorvVjpqug/KtFOCmfQUTf6Syvx3YVcALdVWoSPR9ZVJr9MlcatsqYi
5uEUX+k3x7fTYzcnK43GFIEnr16ahIfXO/Gm6WzxzRFvku+6fxzj9Eogutvk1nPd7GviModadzjO
jYxDcq9ZeFFc8QvUxp1gUwv8Bp8KQsWDTM25G6P/I8k+9p9mSnRVWcBpY9QkAOPK/wKFJcxle+sj
xcdbV6hwHZMRzMfzeouD6+OWyYfkDplII0RLFCrWgrOnAX5gufkQLcm+M0a/hedZLhkHP9/P/IVj
txcotoyqOTOJnJihfxOoASWpq0rb6QIDAQABo4ID+jCCA/YwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQHApdr6WTS4rXR9eil
zbBGH8yIpDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zBqBgNVHREEYzBhgRFqYXJh
Y29AamFyYWNvLmNvbYERamFyYWNvQGphcmFjby5jb22BEWphcmFjb0Bjcy5ubXQuZWR1gRBqYXJh
Y29AZ21haWwuY29tgRRqYXJhY29Ac3BlYWtlYXN5Lm5ldDCCAiEGA1UdIASCAhgwggIUMIICEAYL
KwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xp
Y3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAD
AgEBGo

[issue12415] Missing: How to checkout the Doc sources

[Éric Araujo]

Éric Araujo  added the comment:

> Indeed, I was thinking about getting a CPython checkout with the doc
Right.  I’ll edit my wording to mention Mercurial.

>> I don’t understand: "p"s?
>From "_Developpers's Guide: http://docs.python.org/devguide";
The curse of being French :)  I always want to write “developpers’ guide” when 
it’s “developer’s guide”.

--

___
Python tracker 

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

[issue12415] Missing: How to checkout the Doc sources

[Ezio Melotti]

Ezio Melotti  added the comment:

> Well, the doc makefile still uses Subversion. 
Indeed, I was thinking about getting a CPython checkout with the doc, not about 
the tools used to built it (maybe it could be clarified).

> I don’t understand: "p"s?
>From "_Developpers's Guide: http://docs.python.org/devguide";

--

___
Python tracker 

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

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

[Éric Araujo]

Éric Araujo  added the comment:

IMO, help('help') should document the help function, not start an interactive 
help session (that’d be help()).

--
nosy: +eric.araujo
versions: +Python 3.3 -Python 2.6

___
Python tracker 

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

[issue12415] Missing: How to checkout the Doc sources

[Ezio Melotti]

Ezio Melotti  added the comment:

http://docs.python.org/dev/documenting/building.html also needs to be updated 
(it still mentions Subversion and probably obsolete versions of Sphinx and 
other packages).  If you are going to add the text proposed in your second 
message, you might want to drop a couple of "p"s from there.

--
nosy: +ezio.melotti
type:  -> enhancement

___
Python tracker 

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

[issue12415] Missing: How to checkout the Doc sources

[Éric Araujo]

Éric Araujo  added the comment:

> http://docs.python.org/dev/documenting/building.html also needs to be updated 
> (it
> still mentions Subversion and probably obsolete versions of Sphinx and other
> packages).
Well, the doc makefile still uses Subversion.  As for the versions, if the ones 
listed in the doc don’t match the ones used in the makefile, I’ll sync them.

> If you are going to add the text proposed in your second message, you might 
> want
> to drop a couple of "p"s from there.
I don’t understand: "p"s?

--

___
Python tracker 

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

[issue13703] Hash collision security issue

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

STINNER Victor wrote:
> 
> STINNER Victor  added the comment:
> 
> hash-attack.patch does never decrement the collision counter.

Why should it ? It's only used as local variable in the lookup function.

Note that the limit only triggers on a per-key basis. It's not
a limit on the total number of collisions in the table, so you don't
need to keep the number of collisions stored on the object.

--

___
Python tracker 

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

[issue1040439] Missing documentation on how to link with libpython

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Attached patch adds the useful bits from the review I did; I hope you
> won’t think it’s pointless nitpicking.

Looks good to me.

--

___
Python tracker 

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

[issue13716] distutils doc contains lots of XXX

[Éric Araujo]

Éric Araujo  added the comment:

Tarek ruled that time spent improving the distutils docs was time lost and 
better spent on distutils2.  Accordingly, I only fix clear bugs in the doc but 
don’t improve them in any way.  I’m inclined to close this as wontfix, or I can 
remove the XXX if you’re strongly against them.  (For the packaging docs, I 
will fix them properly.)

--

___
Python tracker 

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

[issue12415] Missing: How to checkout the Doc sources

[Éric Araujo]

Éric Araujo  added the comment:

I merely forgot, thanks for the prod.  I’m taking your message as a +1 to the 
wording and will commit when the server I use for tunnels is back online.

--

___
Python tracker 

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

[issue11473] upload command no longer accepts repository by section name

[Éric Araujo]

Éric Araujo  added the comment:

[copy/paste failure in my previous message, please disregard]

> One possible factor is that my .pypirc is symlinked from ~/.pypirc to 
> config/python/.pypirc and
> it's conceivable that Python 3.2.0 has some issues with symlink resolution 
> that caused it to not
> process the .pypirc properly.

Are these Windows symlinks?  Are they supposed to be dereferenced transparently 
by the OS (i.e. during open) like unix symlinks?

> Sure enough. I just confirmed that with Python 3.2.0, if .pypirc is 
> symlinked, distutils behaves
> as if the .pypirc isn't present at all, but if that same .pypirc is copied, 
> it behaves as
> expected. If one deletes the .pypirc altogether, it produces the same error.

OK.  For distutils2, I think we’ll want better logging/error reporting.  The 
user should see “no /what/ever/.pypirc found”, not “section not found”.

> I suggest we mark this bug as resolved (as the primary cause was due to the 
> file not being read at
> all), but also apply your patch (which has some other good fixes) without the 
> CUSTOM_SERVER, or
> with a version of the CUSTOM_SERVER that works.

Agreed.  I’ll resume work on that patch to understand why it fails.

--

___
Python tracker 

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

[issue11473] upload command no longer accepts repository by section name

[Éric Araujo]

Changes by Éric Araujo :


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

___
Python tracker 

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

[issue13719] bdist_msi upload fails

[Éric Araujo]

Éric Araujo  added the comment:

Thanks!  Given the fragility of distutils, we try to add a test for every fix 
we commit, but I don’t remember if we already have a basic HTTP server to test 
the upload command.  If not, I think I’ll commit this after manual testing (my 
Windows VM crashes on boot, so it may take some time for me to get to this).

--
assignee: tarek -> eric.araujo
components: +Distutils2
nosy: +alexis
stage:  -> test needed
versions: +3rd party, Python 3.3 -Python 3.1

___
Python tracker 

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

[issue13562] Notes about module load path

[Éric Araujo]

Éric Araujo  added the comment:

I did the markup edits but then found out that the doc for Py_Initialize in 
c-api/init already mentions the module load path and the module table, so I’m 
going to make another patch with just a link to that.

--

___
Python tracker 

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

[issue1040439] Missing documentation on how to link with libpython

[Éric Araujo]

Éric Araujo  added the comment:

Attached patch adds the useful bits from the review I did; I hope you won’t 
think it’s pointless nitpicking.

--
Added file: http://bugs.python.org/file24155/docembed-edits.patch

___
Python tracker 

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

[issue13033] Add shutil.chowntree

[Éric Araujo]

Éric Araujo  added the comment:

Thanks for the patch.  Before you do any more work, do other core developers 
agree that this function is a good addition or is it obsoleted by the generic 
improved-walk-with-callback that Nick is working on?

Doc/library/shutil.rst:

I don’t think the note directives are needed.  The doc is not big, I assume 
people will read all of it and see the caveats.  (I’ll also want to group some 
small paragraphs.)

Lib/shutil.py:

+def chowntree(path, user=None, group=None, followlinks=False):
+ [...]
+The dictionary _modified_items, will keep track of the old ownership 
details,
What _modified_items dictionary?

Apart from a few stylistic violations which can be fixed by the committer, the 
function looks good.

Lib/test/test_shutil.py:

Looks good and needs more tests.  Currently it only calls chowntree on a 
directory without children, so it does not test that the chown is indeed 
recursive.

--
nosy: +giampaolo.rodola, haypo, ncoghlan, pitrou

___
Python tracker 

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

[issue13703] Hash collision security issue

[STINNER Victor]

STINNER Victor  added the comment:

hash-attack.patch does never decrement the collision counter.

--

___
Python tracker 

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

[issue13511] Specifying multiple lib and include directories on linux

[Ray]

Ray  added the comment:

Martin, did you read my last post? Did you read the updated topic? libdir and 
includedir are *not* the issue.

So it makes sense to allow configuring multiple directories for python 
installation for darwin but not linux? Why?

--

___
Python tracker 

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

[issue11473] upload command no longer accepts repository by section name

[Éric Araujo]

Éric Araujo  added the comment:

This is a strange bug.  I added a test using -r server2, using the 
already-existing PYPIRC_LONG_PASSWORD string as .pypirc contents.  The test 
passes.  To make sure changing one test would not affect another one, I created 
a new .pypirc file, PYPIRC_CUSTOM_SERVER, and then I got to see your bug!  I 
tried various combinations of keys (realm or not, user or not), changed the 
markup (: or = as delimiter, spaces or not) but could not easily find the root 
of the bug.

Can you publish a .pypirc file that works with 2.7 and not with 3.2?  That 
would be a good starting point.

msg144569 - (view)  Author: Jason R. Coombs (jason.coombs) * (Python 
committer) Date: 2011-09-28 18:09

I now seem to be unable to reproduce the issue. I do keep my .pypirc in a 
revision control system, so I have reasonable confidence that my .pypirc 
contained the content that I'm attaching now (passwords scrubbed of course).

> One possible factor is that my .pypirc is symlinked from ~/.pypirc to 
> config/python/.pypirc and
> it's conceivable that Python 3.2.0 has some issues with symlink resolution 
> that caused it to not
> process the .pypirc properly.

Are these Windows symlinks?  Are they supposed to be dereferenced transparently 
by the OS (i.e. during open) like unix symlinks?

> Sure enough. I just confirmed that with Python 3.2.0, if .pypirc is 
> symlinked, distutils behaves
> as if the .pypirc isn't present at all, but if that same .pypirc is copied, 
> it behaves as
> expected. If one deletes the .pypirc altogether, it produces the same error.

OK.  For distutils2, I think we’ll want better logging/error reporting.  The 
user should see “no /what/ever/.pypirc found”, not “section not found”.

> I suggest we mark this bug as resolved (as the primary cause was due to the 
> file not being read at
> all), but also apply your patch (which has some other good fixes) without the 
> CUSTOM_SERVER, or
> with a version of the CUSTOM_SERVER that works.

Agreed.  I’ll resume work on that patch to understand why it fails.

--

___
Python tracker 

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

[issue13615] setup.py register fails with -r argument

[Éric Araujo]

Éric Araujo  added the comment:

Maybe related to (or same as) #11473.

--
assignee: tarek -> eric.araujo
components: +Distutils2
nosy: +alexis
stage:  -> test needed
title: `setup.py register` fails with -r argument -> setup.py register fails 
with -r argument
versions: +3rd party, 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

[issue13718] Format Specification Mini-Language does not accept comma for percent value

[Eric V. Smith]

Changes by Eric V. Smith :


--
assignee:  -> eric.smith

___
Python tracker 

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

[issue13718] Format Specification Mini-Language does not accept comma for percent value

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +eric.smith, ezio.melotti

___
Python tracker 

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

[issue13642] urllib incorrectly quotes username and password in https basic auth

[Joonas Kuorilehto]

Joonas Kuorilehto  added the comment:

> It is better to do the explicitly above the b64 encoding step.
> Just as host has been unquoted.
> 
> user_passwd, host = splituser(host)
> host = unquote(host)

Ok. So it needs to be done on the line after import base64.

> Also, you have done this only for https_open, the same would need be
> replicated for http_open and also for proxy_passwd.

So four cases where this may need to be fixed and my test only covers one of 
them:

* http without proxy
* http with proxy
* https without proxy
* https with proxy

Copypasted code :(

Can the https and the proxy auth be tested with the same fake http connection, 
when the request is stored?

>  def sendall(self, str):
> -pass
> +FakeHTTPConnection.request += str
> 
> seems a bit odd to me

Agreed, not clean and needs to be fixed. Works here, but could cause the test 
code to become unreadable later on. Wrote it at 5 am, not getting sleep. Please 
provide a cleaner alternative. :)

One question: how come the fake http is given HTTP headers in some tests and 
payload only in others? Is it emulating the TCP stream or the payload stream 
handle? It can't do both, can it? Are the headers in some tests actually doing 
anything?

I would not mind if someone else finished the patch :)

--

___
Python tracker 

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

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

[Zbyszek Szmek]

New submission from Zbyszek Szmek :

% cat test_argparse_narrow.py
import argparse
argparse.ArgumentParser().print_help()

% COLUMNS=15 ./python test_argparse_narrow.py
Traceback (most recent call last):
  File "test_argparse_narrow.py", line 2, in 
argparse.ArgumentParser().print_help()
  File "/home/zbyszek/python/cpython/Lib/argparse.py", line 2347, in print_help
self._print_message(self.format_help(), file)
  File "/home/zbyszek/python/cpython/Lib/argparse.py", line 2321, in format_help
return formatter.format_help()
  File "/home/zbyszek/python/cpython/Lib/argparse.py", line 276, in format_help
help = self._root_section.format_help()
  File "/home/zbyszek/python/cpython/Lib/argparse.py", line 206, in format_help
func(*args)
  File "/home/zbyszek/python/cpython/Lib/argparse.py", line 206, in format_help
func(*args)
  File "/home/zbyszek/python/cpython/Lib/argparse.py", line 514, in 
_format_action
help_lines = self._split_lines(help_text, help_width)
  File "/home/zbyszek/python/cpython/Lib/argparse.py", line 615, in _split_lines
return _textwrap.wrap(text, width)
  File "/home/zbyszek/python/cpython/Lib/textwrap.py", line 316, in wrap
return w.wrap(text)
  File "/home/zbyszek/python/cpython/Lib/textwrap.py", line 291, in wrap
return self._wrap_chunks(chunks)
  File "/home/zbyszek/python/cpython/Lib/textwrap.py", line 220, in _wrap_chunks
raise ValueError("invalid width %r (must be > 0)" % self.width)
ValueError: invalid width -1 (must be > 0)

argparse should not fail if the user resizes the window to something very 
thin...

--
components: Library (Lib)
files: test_argparse_narrow.py
messages: 150733
nosy: zbysz
priority: normal
severity: normal
status: open
title: argparse print_help() fails if COLUMNS is set to a low value
versions: Python 3.3
Added file: http://bugs.python.org/file24154/test_argparse_narrow.py

___
Python tracker 

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

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

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Some remarks on the Windows implementation in termsize.diff.4:

- On Windows, the C runtime always sets fileno(stdout) to 1, so hardcoded 
values are OK.
But on Unix, I'm quite sure that embedded interpreters (mod_python?) sometimes 
close the standard descriptor, so fd=1 can refer to something entirely 
different.
Does it makes sense to initialize fd=fileno(stdout) (this is C code) instead?

- When GetStdHandle() returns INVALID_HANDLE_VALUE, PyErr_SetFromWindowsErr(0) 
should be used.
And it's not necessary to use GetLastError(), 0 is enough.

- GetStdHandle will return NULL in a non-console application (try with 
pythonw.exe or IDLE), I think a specific error message should be raised in this 
case.

--

___
Python tracker 

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

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

[Zbyszek Szmek]

Zbyszek Szmek  added the comment:

One more comment on $COLUMNS overriding the actual terminal size:

> Zbyszek, I just looked at [1] and I disagree that the environment
> variable should have higher precedence. In fact, I believe it should
> have lower precedence, and should be used as a fallback.

To fix issue #9553 "test_argparse.py: 80 failures if COLUMNS env var set to a 
value other than 80", sys.env['COLUMNS']=80 is set during tests.
If issue #13041 is fixed and a real terminal size is used, then
unless $COLUMNS have higher preference, the tests would break again.

--

___
Python tracker 

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

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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

(oops, hadn't seen Charles-François's answer before replying)

--

___
Python tracker 

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

[issue13719] bdist_msi upload fails

[Ralf Schmitt]

New submission from Ralf Schmitt :

Running setup.py bdist_msi upload fails with something like:

c:\Python27\python.exe setup.py bdist_msi upload
running bdist_msi
running build
running build_ext
installing to build\bdist.win-amd64\msi
running install_lib
creating build\bdist.win-amd64
creating build\bdist.win-amd64\msi
creating build\bdist.win-amd64\msi\Lib
creating build\bdist.win-amd64\msi\Lib\site-packages
copying build\lib.win-amd64-2.7\greenlet.pyd -> 
build\bdist.win-amd64\msi\Lib\site-packages
running install_headers
creating build\bdist.win-amd64\msi\Include
creating build\bdist.win-amd64\msi\Include\greenlet
copying greenlet.h -> build\bdist.win-amd64\msi\Include\greenlet
running install_egg_info
Writing 
build\bdist.win-amd64\msi\Lib\site-packages\greenlet-0.3.3-py2.7.egg-info
creating dist
removing 'build\bdist.win-amd64\msi' (and everything under it)
running upload
Linking c:\Users\ralf\home\greenlet\build\lib.win-amd64-2.7\greenlet.pyd to 
c:\Users\ralf\home\greenlet\greenlet.pyd
error: greenlet-0.3.3: No such file or directory

The attached patch fixes it.

--
assignee: tarek
components: Distutils
files: fix-bdist_msi-upload.patch
keywords: patch
messages: 150729
nosy: eric.araujo, loewis, schmir, tarek
priority: normal
severity: normal
status: open
title: bdist_msi upload fails
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file24153/fix-bdist_msi-upload.patch

___
Python tracker 

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

[issue13041] argparse: terminal width is not detected properly

[Zbyszek Szmek]

Zbyszek Szmek  added the comment:

New version to use after #13609 is implemented: patch2.diff

--
Added file: http://bugs.python.org/file24152/patch2.diff

___
Python tracker 

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

[issue13703] Hash collision security issue

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Stupid email interface again... here's the full text:

The hash-attack.patch solves the problem for the integer case
I posted earlier on and doesn't cause any problems with the
test suite.

>>> d = dict((x*(2**64 - 1), hash(x*(2**64 - 1))) for x in xrange(1, 100))
>>> d = dict((x*(2**64 - 1), hash(x*(2**64 - 1))) for x in xrange(1, 1000))
Traceback (most recent call last):
  File "", line 1, in 
KeyError: 'too many hash collisions'

It also doesn't change the hashing or dict repr in existing
applications.

--

___
Python tracker 

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

[issue13703] Hash collision security issue

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

The hash-attack.patch solves the problem for the integer case
I posted earlier on and doesn't cause any problems with the
test suite.

Traceback (most recent call last):
  File "", line 1, in 
KeyError: 'too many hash collisions'

It also doesn't change the hashing or dict repr in existing
applications.

--

___
Python tracker 

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

[issue13703] Hash collision security issue

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Demo patch implementing the collision limit idea for Python 2.7.

--
Added file: http://bugs.python.org/file24151/hash-attack.patch

___
Python tracker 

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

[issue13703] Hash collision security issue

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Before continuing down the road of adding randomness to hash
functions, please have a good read of the existing dictionary
implementation:

"""
Major subtleties ahead:  Most hash schemes depend on having a "good" hash
function, in the sense of simulating randomness.  Python doesn't:  its most
important hash functions (for strings and ints) are very regular in common
cases:

[0, 1, 2, 3]
>>> map(hash, ("namea", "nameb", "namec", "named"))
[-1658398457, -1658398460, -1658398459, -1658398462]
>>>

This isn't necessarily bad!  To the contrary, in a table of size 2**i, taking
the low-order i bits as the initial table index is extremely fast, and there
are no collisions at all for dicts indexed by a contiguous range of ints.
The same is approximately true when keys are "consecutive" strings.  So this
gives better-than-random behavior in common cases, and that's very desirable.
...
"""

There's also a file called dictnotes.txt which has more interesting
details about how the implementation is designed.

Please note that the term "collision" is used in a slightly different
way: it refers to trying to find an empty slot in the dictionary
table. Having a collision implies that the hash values of two distinct
objects are the same, but you also get collisions in case two distinct
objects with different hash values get mapped to the same table entry.

An attack can be based on trying to find many objects with the same
hash value, or trying to find many objects that, as they get inserted
into a dictionary, very often cause collisions due to the collision
resolution algorithm not finding a free slot.

In both cases, the (slow) object comparisons needed to find an
empty slot is what makes the attack practical, if the application
puts too much trust into large blobs of input data - which is
the actual security issues we're trying to work around here...

Given the dictionary implementation notes, I'm even less certain
that the randomization change is a good idea. It will likely
introduce a performance hit due to both the added complexity in
calculating the hash as well as the reduced cache locality of
the data in the dict table.

I'll upload a patch that demonstrates the collisions counting
strategy to show that detecting the problem is easy. Whether
just raising an exception is a good idea, is another issue.

It may be better to change the tp_hash slot in Python 3.3
to take an argument, so that the dict implementation can
use the hash function as universal hash family function
(see http://en.wikipedia.org/wiki/Universal_hash).

The dict implementation could then alter the hash parameter
and recreate the dict table in case the number of collisions
exceeds a certain limit, thereby actively taking action
instead of just relying on randomness solving the issue in
most cases.

--

___
Python tracker 

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

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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Le vendredi 06 janvier 2012 à 02:18 +, Phill a écrit :
> Phill  added the comment:
> 
> Rather than listening on a socket, listening on a named pipe
> 
> eg:
> address = (r'\\.\pipe\Test', 'AF_PIPE')
> listener = Listener(*address)
> conn = listener.accept()
> 
> It doesnt raise an exception when i run the script again a second time.

According to MSDN, this is normal:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365150%28v=vs.85%29.aspx

However, there's also a flag named FILE_FLAG_FIRST_PIPE_INSTANCE that we
could use in PipeListener, which would then raise an error if a listener
pipe was created a second time. It would probably make more sense,
although I don't know whether some programs may rely on creating a pipe
multiple times.

--

___
Python tracker 

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

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

[Zbyszek Szmek]

Zbyszek Szmek  added the comment:

Following comments by Martin and Victor, here is next version: termsize.diff.4

Changes:
- just check for defined(MS_WINDOWS) and rely on .
- rename query_terminal_size to get_terminal_size_raw
 This way it should be clearer that the second one is low-level,
 and should be less exposed. I don't want to call it
 _get_terminal_size() because it is not just an implementation
 detail and would sometimes be called directly.
- NotImplementedError is gone. get_terminal_size_raw() is not
  defined if not possible.

Non-changes:
- sys.__stdout__.fileno() is not changed to 1, because as Antoine
  pointed out, it is set at runtime.
- STDOUT_FILENO: not defined on windows, so just use 1 and add a comment
- fd argument is retained, because we might want to test terminals
  opened with openpty.
- two functions: still there. I think that get_terminal_size() should
  provide an easy-to-use, even trivial-to-use, way to get a sensible
  value without writing a wrapper. In the _majority_ of cases the
  wrapper would be something like get_terminal_size() currently.
- named tuple: like Antoine said, it gives nice syntax.
- testing for : in termios and other modules, setup.py
  first tests if we are on unix. But there might be unices without
  TIOCGWINSZ, and non-unix systems where TIOCGWINSZ _is_ defined,
  so it seems a functional test is simpler and more robust.

Tested on linux and windows XP.

--
Added file: http://bugs.python.org/file24150/termsize.diff.4

___
Python tracker 

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

[issue13718] Format Specification Mini-Language does not accept comma for percent value

[Michael Kesper]

New submission from Michael Kesper :

http://docs.python.org/library/string.html#format-specification-mini-language 
mentions:
Changed in version 2.7: Added the ',' option (see also PEP 378).

PEP 378 tells me:
The ',' option is defined as shown above for types 'd', 'e', 'f', 'g', 'E', 
'G', '%', 'F' and ''.

However:

Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> '{:.2,%}'.format(.537568)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: Invalid conversion specification
>>> '{:2,%}'.format(.537568)
'53.756800%'

--
messages: 150721
nosy: mkesper
priority: normal
severity: normal
status: open
title: Format Specification Mini-Language does not accept comma for percent 
value
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

[issue13642] urllib incorrectly quotes username and password in https basic auth

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Some review comments. Instead of doing the inline unquote like this -

-auth = base64.b64encode(user_passwd).strip()
+auth = base64.b64encode(unquote(user_passwd)).strip()

It is better to do the explicitly above the b64 encoding step.
Just as host has been unquoted.

user_passwd, host = splituser(host)
host = unquote(host)

Also, you have done this only for https_open, the same would need be replicated 
for http_open and also for proxy_passwd.  Also on tests, Modifying sendall with

 def sendall(self, str):
-pass
+FakeHTTPConnection.request += str

seems a bit odd to me, you are using a class level object and adding a str. I 
think, there should be better way to do. (I shall provide an example). Also str 
term can replaced, even if it was coming from old code.

--
assignee:  -> orsenthil
stage:  -> patch review

___
Python tracker 

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

[issue13703] Hash collision security issue

[Mark Shannon]

Mark Shannon  added the comment:

Without the context, that last message didn't make much sense.

I agree with Terry that we should copy Perl and Ruby (for strings).
I'm -1 on hash() returning a different value than dict uses internally.

--

___
Python tracker 

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

[issue13703] Hash collision security issue

[Mark Shannon]

Mark Shannon  added the comment:

I agree.

+1 for strings. -0 for numbers.

This might cause problems with dict subclasses and the like,
so I'm -1 on this.

--

___
Python tracker 

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

[issue9993] shutil.move fails on symlink source

[Hynek Schlawack]

Hynek Schlawack  added the comment:

Oh sorry, I didn't look into the doc patch.

I unified both into one patch and added the versionchanged tag and also updated 
the docstring of shutil.move.

--
Added file: http://bugs.python.org/file24149/shutil_move_symlinks.patch

___
Python tracker 

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

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

[Charles-François Natali]

Charles-François Natali  added the comment:

> Like I said, I dont know much about named pipes and im not even sure thats 
> how they are intended to work in this context. IE: if one process is 
> listening, can another listen on that named pipe as well?

Under Unix, you'd get a EADDRINUSE with a Unix domain socket.

I don't know much about Windows, but here's what CreateNamedPipe doc says:
"""
FILE_FLAG_FIRST_PIPE_INSTANCE
0x0008
If you attempt to create multiple instances of a pipe with this flag,
creation of the first instance succeeds, but creation of the next
instance fails with ERROR_ACCESS_DENIED.
Windows 2000:  This flag is not supported until Windows 2000 SP2 and Windows XP.
"""

So it seems that we should probably pass FILE_FLAG_FIRST_PIPE_INSTANCE
under Windows.

--

___
Python tracker 

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