[issue12364] Deadlock in test_concurrent_futures

[Ross Lagerwall]

Ross Lagerwall  added the comment:

Thanks!

--
assignee:  -> rosslagerwall
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

___
Python tracker 

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

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

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Please consider this: the code that is there was specifically added by somebody 
porting Python to OS/2. So if it doesn't work for you, either OS/2 has changed 
(which I don't think is the case), or you are doing something wrong (such as 
using the wrong tool chain).

If the change you propose was carried out, it would likely break what works 
currently. So everybody is hesitant to add this change, unless you can explain 
it to us: line-by-line, character-by-character. E.g. why are you proposing that 
OS/2 is a POSIX system? Treating it similar to NT is much more plausible, given 
that NT was designed as the OS/2 successor originally.

--

___
Python tracker 

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

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

[Nick Coghlan]

Nick Coghlan  added the comment:

Since walkdir is currently entirely based on returning filesystem paths as 
strings (just like os.walk()) and hence shares the pervasive symlink attack 
vulnerability, I'm particularly interested in the question of whether or not 
the various *at APIs can be used to avoid symlink attacks if we just have a 
os.walkfd() API that emits a (dirfd, subdirs, files) triple instead of the 
os.walk style (dirpath, subdirs, files).

The reason I'd find that interesting is that many of walkdir's filtering steps 
(notably those for including and excluding directories) don't care about the 
value of dirpath, so they could still be used with such an API.

Thoughts?

--

___
Python tracker 

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

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

[Georg Brandl]

Changes by Georg Brandl :


--
assignee:  -> loewis
nosy: +loewis
priority: normal -> high
title: bugs.python.org's Django settings file DEBUG=True -> 
bugs.python.org/review's Django settings file DEBUG=True

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

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

This concerns me too, and is one reason I think the collision counting
code might be the winning solution. Randomness is hard to do correctly
and is expensive. If we can avoid it, we should try very hard to do
so...

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

Interesting point, though I think we might be able to work it out so
that we're only adding instructions when there's actually a detected
collision. I'll be interested to see what the benchmarks (and real
world) have to say about the impacts of randomization as compared to
the existing black-magic optimization of the hash function.

--

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

Tim Peters wrote:
> 
> Tim Peters  added the comment:
> 
> [Marc-Andre]
>> BTW: I wonder how long it's going to take before
>> someone figures out that our merge sort based
>> list.sort() is vulnerable as well... its worst-
>> case performance is O(n log n), making attacks
>> somewhat harder.
> 
> I wouldn't worry about that, because nobody could stir up anguish
> about it by writing a paper ;-)
> 
> 1. O(n log n) is enormously more forgiving than O(n**2).
> 
> 2. An attacker need not be clever at all:  O(n log n) is not only
> sort()'s worst case, it's also its _expected_ case when fed randomly
> ordered data.
> 
> 3. It's provable that no comparison-based sorting algorithm can have
> better worst-case asymptotic behavior when fed randomly ordered data.
> 
> So if anyone whines about this, tell 'em to go do something useful instead :-)

Right on all accounts :-)

--

___
Python tracker 

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

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

[Nick Coghlan]

Nick Coghlan  added the comment:

Another, possibly better, alternative would be to produce a tuple-subclass that 
adds a separate "dirfd" attribute to the (dirpath, subdirs, files) triple.

I'll stop talking about the walkdir implications here. Instead, I've created a 
corresponding issue on walkdir's own tracker:
https://bitbucket.org/ncoghlan/walkdir/issue/8/add-walkfd

--

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

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

I haven't done any profiling on this yet, but will run some
tests.

The lookup functions in the dict implementation are optimized
to make the first non-collision case fast. The patch doesn't touch this
loop. The only change is in the collision case, where an increment
and comparison is added (and then only after the comparison which
is the real cost factor in the loop). I did add a printf() to
see how often this case occurs - it's a surprisingly rare case,
which suggests that Tim, Christian and all the others that have
invested considerable time into the implementation have done
a really good job here.

BTW: I noticed that a rather obvious optimization appears to be
missing from the Python dict initialization code: when passing in
a list of (key, value) pairs, the implementation doesn't make
use of the available length information and still starts with an
empty (small) dict table and then iterates over the pairs, increasing
the table size as necessary. It would be better to start with a
table that is presized to O(len(data)). The dict implementation
already provides such a function, but it's not being used
in the case dict(pair_list). Anyway, just an aside.

--

___
Python tracker 

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

[issue12760] Add create mode to open()

[Charles-François Natali]

Charles-François Natali  added the comment:

I intend to commit this patch within a couple days (unless anyone objects of 
course).

--
stage:  -> patch review

___
Python tracker 

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

[issue10278] add time.wallclock() method

[Matthias Klose]

Matthias Klose  added the comment:

on linux the underlying functionality is implemented in librt; the extension 
doesn't check for this or links with -lrt.

--
nosy: +doko

___
Python tracker 

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

[issue13122] Out of date links in the sidebar of the documentation index of versions 3.1 and 3.2

[Sandro Tosi]

Sandro Tosi  added the comment:

Hi all, how can we fix it? or better, should we fix it? From a user POV, it is 
a weird to see 3.1 doc referring to 3.2 doc as "in development" then clicking 
on that link, being redirect to 3.3a0 doc and see there that 3.2 is stable 
(with no reference back to 3.1).

Maybe we can adjust the sidebar in 3.1 references and do a manual rebuild or 
just wait for another security release? maybe we can discuss a policy for such 
things and write it in stone (aka devguide).

--
nosy: +sandro.tosi

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

Changes by Terry J. Reedy :


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

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

Changes by Terry J. Reedy :


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

___
Python tracker 

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

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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, the answer has probably been already given on python-dev:

> I've been building Python 2.x for a while, and currently have binaries 
> of 2.6.5 available from http://os2ports.smedley.info

> Unlike Andrew Mcintyre, I'm using libc for development 
> (http://svn.netlabs.org/libc) rather than emx.  libc is still being 
> developed whereas emx hasn't been updated in about 10 years.

--

___
Python tracker 

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

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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Since walkdir is currently entirely based on returning filesystem
> paths as strings (just like os.walk()) and hence shares the pervasive
> symlink attack vulnerability, I'm particularly interested in the
> question of whether or not the various *at APIs can be used to avoid
> symlink attacks if we just have a os.walkfd() API that emits a (dirfd,
> subdirs, files) triple instead of the os.walk style (dirpath, subdirs,
> files).

Be aware that you have to manage dirfd's lifetime, which can make things
interesting.
Also be aware that symlinks mean sometimes you won't have a dirfd: if
you have a symlink that points to another directory, you can't open that
directory using openat from the symlink's directory. So if you follow
symlinks (or have an option to do so) you must also take that case into
account.

--

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

> Randomness is hard to do correctly
> and is expensive. If we can avoid it, we should try very hard to do
> so...

os.urandom() is actually cheaper on Windows 7 here:

100 loops, best of 3: 1.78 usec per loop

than on Linux:

$ ./python -m timeit -s "import os" "os.urandom(16)"
10 loops, best of 3: 4.85 usec per loop
$ ./python -m timeit -s "import os; f=os.open('/dev/urandom', os.O_RDONLY)" 
"os.read(f, 16)"
10 loops, best of 3: 2.35 usec per loop

(note that the os.read timing is optimistic since I'm not checking the
return value!)

I don't know if the patch's startup overhead has to do with initializing
the crypo context or simply with looking up the symbols in advapi32.dll.
Perhaps we should link explicitly against advapi32.dll as suggested by
Martin?

--

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

Again, Roundup ate up some of the text:

>PCbuild\amd64\python.exe  -m timeit -s "import os" "os.urandom(16)"
100 loops, best of 3: 1.81 usec per loop

(for the record, the Roundup issue is at 
http://psf.upfronthosting.co.za/roundup/meta/issue264 )

--

___
Python tracker 

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

[issue12760] Add create mode to open()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I don't think the "created()" method has to be exposed. People can inspect the 
"mode" attribute if they want to have that information.
(besides, the semantics are misleading since a new file opened with "w" has 
also be created, but created() would return False)

There's some bogus indentation in the patch (it uses tab characters in some 
places).

Also:

+if not (creating + reading or writing or appending):

Not sure why the "+". Shouldn't it be "or" instead?

--

___
Python tracker 

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

[issue13738] Optimize bytes.upper() and lower()

[Antoine Pitrou]

New submission from Antoine Pitrou :

The current implementation has useless testing and copying.

--
components: Interpreter Core
files: bytesupper.patch
keywords: patch
messages: 150868
nosy: benjamin.peterson, flox, haypo, pitrou
priority: low
severity: normal
stage: patch review
status: open
title: Optimize bytes.upper() and lower()
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file24175/bytesupper.patch

___
Python tracker 

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

[issue13738] Optimize bytes.upper() and lower()

[Benjamin Peterson]

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

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

[Charles-François Natali]

Charles-François Natali  added the comment:

Here's a possible walkfd() implementation.

Example:
"""
$ cat /home/cf/testwalkfd.py
import os
import sys

topfd = os.open(sys.argv[1], os.O_RDONLY)

for rootfd, dirs, files in os.walkfd(topfd):
print(rootfd, dirs, files)
$ ./python ~/testwalkfd.py /etc/apt/
3 ['sources.list.d', 'preferences.d', 'trusted.gpg.d', 'apt.conf.d']
['trustdb.gpg', 'trusted.gpg~', 'sources.list', 'trusted.gpg']
4 [] []
4 [] []
4 [] []
4 [] ['70debconf', '01autoremove', '00trustcdrom']
[44194 refs]
"""

AFAICT, a safe rmtree could be implemented simply with
walkfd(topdown=False), but Antoine's remarks make me thing I missed
something.

> Be aware that you have to manage dirfd's lifetime, which can make things
> interesting.

Basically, this means that doing:
for rootfd, dirs, files in walkfd(topfd):
print(fstat(rootfd), dirs, files))

is valid whereas

print([(fstat(rootfd), dirs, files) for (rootfd, dirs, files) in
walkfd(topfd)]) isn't.

> Also be aware that symlinks mean sometimes you won't have a dirfd: if
> you have a symlink that points to another directory, you can't open that
> directory using openat from the symlink's directory. So if you follow
> symlinks (or have an option to do so) you must also take that case into
> account.

I'm not sure I understand this. Why "you can't open that directory
using openat from the symlink's directory". Could you elaborate?

--
keywords: +patch
Added file: http://bugs.python.org/file24176/walkfd.diff

___
Python tracker 

___diff --git a/Lib/os.py b/Lib/os.py
--- a/Lib/os.py
+++ b/Lib/os.py
@@ -24,6 +24,7 @@
 #'
 
 import sys, errno
+import stat as st
 
 _names = sys.builtin_module_names
 
@@ -151,7 +152,6 @@
 try:
 mkdir(name, mode)
 except OSError as e:
-import stat as st
 if not (e.errno == errno.EEXIST and exist_ok and path.isdir(name) and
 st.S_IMODE(lstat(name).st_mode) == _get_masked_mode(mode)):
 raise
@@ -298,6 +298,78 @@
 
 __all__.append("walk")
 
+def _are_same_file(stat1, stat2):
+"""Helper function that checks whether two stat results refer to the same
+file.
+"""
+return (stat1.st_mode == stat2.st_mode and stat1.st_ino == stat2.st_ino and
+stat1.st_dev == stat2.st_dev)
+
+def walkfd(topfd, topdown=True, onerror=None, followlinks=False):
+"""Directory tree generator.
+
+This behaves exactly like walk(), except that it accepts a file descriptor
+as top directory, and yields a 3-tuple
+
+dirfd, dirnames, filenames
+
+dirfd is a file descriptor referring to the directory.  dirnames is a list
+of the names of the subdirectories in dirpath (excluding '.' and '..').
+filenames is a list of the names of the non-directory files in dirpath.
+
+The advantage of walkfd() over walk() is that it's safe against symlink
+races (when followlinks is False).
+"""
+# fdlistdir() closes the passed FD, hence the dup()
+fd = dup(topfd)
+try:
+names = fdlistdir(fd)
+except error as err:
+if onerror is not None:
+onerror(err)
+return
+
+# whether to follow symlinks
+flag = 0 if followlinks else AT_SYMLINK_NOFOLLOW
+
+dirs, dirmodes, nondirs = [], [], []
+for name in names:
+try:
+orig_st = fstatat(topfd, name, flag)
+except error as err:
+if onerror is not None:
+onerror(err)
+return
+if st.S_ISDIR(orig_st.st_mode):
+# Store the result of stat to check that the file hasn't been
+# modified when we call walkfd() recursively (symlink race).
+dirs.append(name)
+dirmodes.append(orig_st)
+else:
+nondirs.append(name)
+
+if topdown:
+yield topfd, dirs, nondirs
+for name, orig_st in zip(dirs, dirmodes):
+try:
+dirfd = openat(topfd, name, O_RDONLY)
+except error as err:
+if onerror is not None:
+onerror(err)
+return
+try:
+# To guard against symlinks race, compare with the original stat
+# result.
+if followlinks or _are_same_file(orig_st, fstat(dirfd)):
+for x in walkfd(dirfd, topdown, onerror, followlinks):
+yield x
+finally:
+close(dirfd)
+if not topdown:
+yield topfd, dirs, nondirs
+
+__all__.append("walkfd")
+
 # Make sure os.environ exists, at least
 try:
 environ
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

- Can you use pickletools.dis to examine what differs in the pickles' bytecode?
- Does it also apply to 3.3?

> It appears at least some kind of efficiency might be missed out for
> marshall as well.

marshal doesn't use the pickle protocols, so it's unlikely to be affected.

--
nosy: +pitrou

___
Python tracker 

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

[issue13738] Optimize bytes.upper() and lower()

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 9683d59170ee by Antoine Pitrou in branch 'default':
Issue #13738: Simplify implementation of bytes.lower() and bytes.upper().
http://hg.python.org/cpython/rev/9683d59170ee

--
nosy: +python-dev

___
Python tracker 

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

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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> > Also be aware that symlinks mean sometimes you won't have a dirfd: if
> > you have a symlink that points to another directory, you can't open that
> > directory using openat from the symlink's directory. So if you follow
> > symlinks (or have an option to do so) you must also take that case into
> > account.
> 
> I'm not sure I understand this. Why "you can't open that directory
> using openat from the symlink's directory". Could you elaborate?

Hmm, sorry, I must have misremembered. I thought openat didn't follow
symlinks.

As for the patch, I think there's a problem with the API:

+This behaves exactly like walk(), except that it accepts a file descriptor
+as top directory, and yields a 3-tuple
+
+dirfd, dirnames, filenames

It doesn't tell you to which dirname corresponds dirfd, so you don't
know the path of the directory you are handed (which can be useful for
progress report, error report, or anything else where you need the name
- e.g. making a zip archive of the directory). Also giving the dirnames
without their fds encourages using them by name, not by fd ;-)

Also, walkfd would be easier to use if callable with a str or bytes path
rather than an int fd.

--

___
Python tracker 

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

[issue13738] Optimize bytes.upper() and lower()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thanks.

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

[issue13673] PyTraceBack_Print() fails if signal received but PyErr_CheckSignals() not called

[sbt]

sbt  added the comment:

Trivial 3 lines patch.

I guess there is still a race: if Ctrl-C is pressed after PyErr_CheckSignals() 
is called but before PyObject_Str() then the printing of any exception can 
still be suppressed.

--
Added file: http://bugs.python.org/file24177/traceback_checksignals_2.patch

___
Python tracker 

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

[issue13026] Dis module - documentation of MAKE_FUNCTION

[Sandro Tosi]

Sandro Tosi  added the comment:

Hi Arnaud,
would you like to provide a patch to update the MAKE_FUNCTION opcode 
description? That would speed up a bit the fix-up.

Also, I don't have that clear what "For each keyword only default, ..." mean: 
are those the default values for keyword arguments? something else?

Thanks in advance,
Sandro

--
nosy: +sandro.tosi
stage:  -> needs patch
versions: +Python 3.2

___
Python tracker 

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

[issue13739] os.fdlistdir() is not idempotent

[Charles-François Natali]

New submission from Charles-François Natali :

After a call to fdlistdir(), another call to fdlistdir() on the same file 
handle (but using a different FD, since the FD passed to fdlistdir() is closed) 
will return an empty list:

"""
$ cat ~/test_fdlistdir.py 
import os
import sys


fd = os.open(sys.argv[1], os.O_RDONLY)

print(os.fdlistdir(os.dup(fd)))
print(os.fdlistdir(os.dup(fd)))

os.close(fd)
$ ./python ~/test_fdlistdir.py /tmp/
['pulse-B1FebW397VI5', 'ksocket-kdm', 'etc', 'kde-cf', 'ksocket-cf', 
'test_posix.py', '.X0-lock', 'kde-kdm', 'akonadi-cf.k6y52j', 
'ssh-iSFleEAS1243', '.ICE-unix', '.X11-unix']
[]
"""

That's because fdopendir()/readdir doesn't reset the FD offset.
It's documented by POSIX:
"""
The file offset associated with the file descriptor at the time of the call 
determines which entries are returned.
"""

That's rather suprising (I got bitten while trying to write a test for #13734).
I see two options:
1. rewind the directory stream in fdlistdir()
2. document this

Here's a patch for option 1.

--
components: None
files: fdlistdir.diff
keywords: patch
messages: 150877
nosy: neologix, pitrou, rosslagerwall
priority: normal
severity: normal
status: open
title: os.fdlistdir() is not idempotent
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24178/fdlistdir.diff

___
Python tracker 

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

[issue13521] Make dict.setdefault() atomic

[Filip Gruszczyński]

Filip Gruszczyński  added the comment:

Bump! There was no activity here for two weeks. Is my patch for 2.7 ok or 
should I do something more about it?

--

___
Python tracker 

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

[issue13739] os.fdlistdir() is not idempotent

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I see two options:
> 1. rewind the directory stream in fdlistdir()
> 2. document this
> 
> Here's a patch for option 1.

Agreed with that, and ok with the patch :)

--

___
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 won't claim to know more about socket error codes than what the Linux man 
pages says. According to them only send() can fail with ECONNRESET, even though 
POSIX Programmer's Manual man pages mentions many others. getpeername() is 
however not documented as being able to return ECONNRESET, and ENOTCONN is 
apparently the most appropriate error code for getpeername() both on linux (3) 
and posix (3p).

So: ENOTCONN from getpeername just means that the connection isn't connected. 
It doesn't indicate that no connection attempt has been mode, and the use of 
getpeername in SSLSocket.__init__ is thus not usable for checking "if the 
underlying socket isn’t connected yet".

The wrap_socket API promises to be able to wrap both connected and unconnected 
sockets without being told explicit what the programmer intended. A system 
network socket knows if it is unused or failed, but I am not aware of any 
reliable cross-platform way to observe that (but that doesn't mean that none 
exist). The only way to reliably implement the documented wrap_socket API might 
thus be to maintain a flag in PySocketSockObject.

Introducing a new and more explicit way of wrapping connected sockets might be 
a simpler and more stable solution.

>From another perspective: Any user of sockets must be aware that socket 
>operations can fail at any time. It might thus not be a problem that 
>wrap_socket fails to fail, as long as the programmer knows how to catch the 
>failure in the next operation. From that point of view the problem is that it 
>is surprising and undocumented how getpeercert can fail.

--

___
Python tracker 

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

[issue12760] Add create mode to open()

[Charles-François Natali]

Charles-François Natali  added the comment:

Here's a new version of the patch that should address all the comments.

--
Added file: http://bugs.python.org/file24179/open_create_x-3.patch

___
Python tracker 

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

[issue13739] os.fdlistdir() is not idempotent

[Ross Lagerwall]

Ross Lagerwall  added the comment:

> I see two options:
> 1. rewind the directory stream in fdlistdir()
> 2. document this
> 
> Here's a patch for option 1.

Yeah, looks good.

--

___
Python tracker 

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

[issue13739] os.fdlistdir() is not idempotent

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 7b2a178c028b by Charles-François Natali in branch 'default':
Issue #13739: In os.listdir(), rewind the directory stream (so that listdir()
http://hg.python.org/cpython/rev/7b2a178c028b

--
nosy: +python-dev

___
Python tracker 

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

[issue12760] Add create mode to open()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Here's a new version of the patch that should address all the comments.

Just a small note: FileExistsError is raised, not exactly OSError, when
the file exists.

--

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

> The only way to reliably implement the documented wrap_socket API
> might thus be to maintain a flag in PySocketSockObject.

Agreed. With the annoyance that the flag must be exposed to Python code,
since ssl's wrap_socket is written in Python. It may be private, though.

> Introducing a new and more explicit way of wrapping connected sockets
> might be a simpler and more stable solution.

I'm a bit wary of API bloat here.

> From another perspective: Any user of sockets must be aware that
> socket operations can fail at any time. It might thus not be a problem
> that wrap_socket fails to fail, as long as the programmer knows how to
> catch the failure in the next operation. From that point of view the
> problem is that it is surprising and undocumented how getpeercert can
> fail.

Thanks. So fixing how getpeercert behaves and either raise a dedicated
error or return None would improve things here, right?

--

___
Python tracker 

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

[issue13521] Make dict.setdefault() atomic

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Looking at the patch again, I think this isn't enough.
setdefault() will still call the lookup routine twice which, in the general 
case (i.e. lookdict() not lookdict_unicode()), can call arbitrary Python code 
through e.g. __eq__ methods.

--

___
Python tracker 

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

[issue13739] os.fdlistdir() is not idempotent

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 36f2e236c601 by Charles-François Natali in branch 'default':
Issue #13739: It's simpler and more direct to call rewinddir() at the
http://hg.python.org/cpython/rev/36f2e236c601

--

___
Python tracker 

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

[issue10278] add time.wallclock() method

[STINNER Victor]

STINNER Victor  added the comment:

> on linux the underlying functionality is implemented in librt; the extension 
> doesn't check for this or links with -lrt.

The changeset 35e4b7c4bafa changed configure.in to check clock_gettime(). It 
checks without and with librt:

 7.7 +AC_CHECK_FUNCS(clock_gettime, [], [
 7.8 +AC_CHECK_LIB(rt, clock_gettime, [
 7.9 +AC_DEFINE(HAVE_CLOCK_GETTIME, 1)
7.10 +AC_DEFINE(TIMEMODULE_LIB, [rt],
7.11 +  [Library needed by timemodule.c: librt may be 
needed for clock_gettime()])
7.12 +])
7.13 +])

wallclock-3.patch checks for HAVE_CLOCK_GETTIME, which does use librt in its 
test (see above).

--

___
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'm a bit wary of API bloat here.

Yes, but explicit is better than magic ...

> Thanks. So fixing how getpeercert behaves and either raise a dedicated
> error or return None would improve things here, right?

Well ... that would at least make it theoretically possible to claim 
that it works as intended ;-)

A counter argument could be that retrieving the certificate that already 
has been used for negotiation isn't a socket operation. It would make 
sense to be able to look at it even after the socket has been closed. 
 From that point of view _sslobj should be kept "forever".

A return value of None would still not indicate if we had a working 
connection without certificate or a failed connection. That would be 
annoying.

My primary concern with my Mercurial hat on is to get the documentation 
updated so we know how to write code that works correctly also with 
previous Python versions.

--

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

> A return value of None would still not indicate if we had a working 
> connection without certificate or a failed connection. That would be 
> annoying.

Ah, right. Then raising e.g. a ValueError would be better.

--

___
Python tracker 

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

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

[Kay Hayen]

Kay Hayen  added the comment:

It seems that there is an extra "BINPUT 2", whatever it does. I am attaching a 
variant that does pickletools.dis on the 3 dumps.

Protocol 2 :
Dumping read const const stream '\x80\x02}q\x01U\x07modulesq\x02Ns.'
0: \x80 PROTO  2
2: }EMPTY_DICT
3: qBINPUT 1
5: USHORT_BINSTRING 'modules'
   14: qBINPUT 2
   16: NNONE
   17: sSETITEM
   18: .STOP
highest protocol among opcodes = 2
Dumping load const const stream '\x80\x02}q\x01U\x07modulesNs.'
0: \x80 PROTO  2
2: }EMPTY_DICT
3: qBINPUT 1
5: USHORT_BINSTRING 'modules'
   14: NNONE
   15: sSETITEM
   16: .STOP
highest protocol among opcodes = 2
Dumping load const const stream '\x80\x02}q\x01U\x07modulesNs.'
0: \x80 PROTO  2
2: }EMPTY_DICT
3: qBINPUT 1
5: USHORT_BINSTRING 'modules'
   14: NNONE
   15: sSETITEM
   16: .STOP
highest protocol among opcodes = 2

--
Added file: http://bugs.python.org/file24180/stream.py

___
Python tracker 

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

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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ah, right. BINPUT is used to memoize objects in case a restructive structure 
happens. You can use pickletools.optimize() to remove the useless BINPUTs out 
of a pickle stream.

Note that 3.x is more consistent and always emits the BINPUTs. It seems 2.x's 
cPickle (which is really a weird piece of code) may do some premature 
optimization here.

--

___
Python tracker 

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

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

[Kay Hayen]

Kay Hayen  added the comment:

Sending my attached file "stream.py" through "2to3.py" it shows that CPython 
3.2 doesn't exihibit the issue for either protocol, which may be because it's 
now "unicode" key, but as it's the only value I tried, I can't tell.

Hope this helps.

Regarding the "marshal", I presume, that somehow the dictionary when created 
via "marshal" (or compile, if no ".pyc" is involved?) first time is somehow 
less efficient to determine/stream that the one "cPickle" created.

My assumption is that somehow, when creating the dictionary from cPickle, it is 
different (has to be), and that's interesting. And of course the easier to 
stream dictionary may be the nicer one at runtime as well. But that is just my 
speculation.

Yours,
Kay

--

___
Python tracker 

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

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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I think the "premature" optimization comes down to that code:

"""
static int
put(Picklerobject *self, PyObject *ob)
{
if (Py_REFCNT(ob) < 2 || self->fast)
return 0;

return put2(self, ob);
}
"""

(put2() being the function which emits BINPUT)

When you unpickle a dict, its contents are created anew and therefore the 
refcount is 1 => next pickling avoids emitting a BINPUT.

--

___
Python tracker 

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

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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Regarding the "marshal", I presume, that somehow the dictionary when
> created via "marshal" (or compile, if no ".pyc" is involved?) first
> time is somehow less efficient to determine/stream that the one
> "cPickle" created.

I don't think so.  marshal uses a much simpler and less general
serialization protocol, so it should theoretically (!) be faster as
well.
For example, I don't think marshal supports recursive structures.

--

___
Python tracker 

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

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

[Kay Hayen]

Kay Hayen  added the comment:

I see, if it's refcount dependent, that explains why it changes from 
interpreter provided dictionary and self-created one.

So, I take, I should always call "pickletools.optimize( cPickle.dumps( value 
))" then.

Thanks,
Kay

--

___
Python tracker 

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

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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Closing the issue as it's really a quirk rather than a bug. Thanks for 
reporting, though.

--
resolution:  -> wont fix
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

[issue13739] os.fdlistdir() is not idempotent

[Antoine Pitrou]

Antoine Pitrou  added the comment:

For some reason, the second changeset broke the OpenIndiana buildbots:
http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.x/builds/2485

Also, wouldn't it be better to call rewinddir with the GIL released?
(although I agree rewinddir shouldn't be expensive)

--

___
Python tracker 

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

[issue13739] os.fdlistdir() is not idempotent

[Charles-François Natali]

Charles-François Natali  added the comment:

> For some reason, the second changeset broke the OpenIndiana buildbots:
>

I have absolutely no idea of why this doesn't work. I suspect
rewinddir() is a noop on OpenIndiana if readdir() hasn't been called.
I'll revert this commit.

> Also, wouldn't it be better to call rewinddir with the GIL released?
> (although I agree rewinddir shouldn't be expensive)

rewinddir() just changes a pointer, and calls - or ought to call -
lseek() on the FD. This should be fast, since no I/O is involved
(lseek() is not documented to return EINTR, for example). Releasing
the GIL has a cost :-)

--

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

Here's a patch addressing the multiple bind() problem on Windows.

Note that this problem also affects other parts of the stdlib, which use 
SO_REUSEADDR when available.

Also, there's an rather confusing comment in support.find_unused_port():

"""
(This is easy to reproduce on Windows, unfortunately, and can be traced to
the SO_REUSEADDR socket option having different semantics on Windows versus
Unix/Linux.  On Unix, you can't have two AF_INET SOCK_STREAM sockets bind,
listen and then accept connections on identical host/ports.  An EADDRINUSE
socket.error will be raised at some point (depending on the platform and
the order bind and listen were called on each socket).

However, on Windows, if SO_REUSEADDR is set on the sockets, no EADDRINUSE
will ever be raised when attempting to bind two identical host/ports. When
accept() is called on each socket, the second caller's process will steal
the port from the first caller, leaving them both in an awkwardly wedged
state where they'll no longer respond to any signals or graceful kills, and
must be forcibly killed via OpenProcess()/TerminateProcess().

The solution on Windows is to use the SO_EXCLUSIVEADDRUSE socket option
instead of SO_REUSEADDR, which effectively affords the same semantics as
SO_REUSEADDR on Unix.  Given the propensity of Unix developers in the Open
Source world compared to Windows ones, this is a common mistake.  A quick
look over OpenSSL's 0.9.8g source shows that they use SO_REUSEADDR when
openssl.exe is called with the 's_server' option, for example. See
http://bugs.python.org/issue2550 for more info.  The following site also
has a very thorough description about the implications of both REUSEADDR
and EXCLUSIVEADDRUSE on Windows:
http://msdn2.microsoft.com/en-us/library/ms740621(VS.85).aspx)
"""

I have no idea why it uses SO_REUSEADDR + SO_EXCLUSIVEADDRUSE instead of just 
keeping the default setting, since we don't want to allow multiple bind(), but 
bypass the TIME-WAIT lingering.

--
Added file: http://bugs.python.org/file24181/connection_multiple_bind.diff

___
Python tracker 

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

[issue12760] Add create mode to open()

[Charles-François Natali]

Charles-François Natali  added the comment:

> Just a small note: FileExistsError is raised, not exactly OSError,
> when the file exists.

I've updated the doc accordingly.

--
stage: patch review -> commit review

___
Python tracker 

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

[issue13026] Dis module - documentation of MAKE_FUNCTION

[Terry J. Reedy]

Terry J. Reedy  added the comment:

"For each keyword only default" is not in my text, but if you are referring to 
"keyword only name, default parameter object pairs ", yes. Here is a revised 
suggested wording:

MAKE_FUNCTION(argc)
Pushes a new function object on the stack. From bottom to top, the consumed 
stack must have have (argc & 0xFF) default argument objects in positional 
order, ((argc >> 8) & 0xFF) (name, default argument) pairs, with name just 
below the object on the stack, for keyword-only parameters, ((argc >> 16) & 
0x7FFF) parameter annotation objects, a tuple listing the parameter names for 
the annotations, and finally a code object as TOS.

--

___
Python tracker 

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

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

[Martin v . Löwis]

Martin v. Löwis  added the comment:

I disagree that this is a security issue, or an issue at all. All source code 
of the site is in a public subversion repository, available for review to any 
attacker (as well as any security review) - and that is deliberately so because 
we fundamentally believe in openness of source code.

I fail to see why making the traceback available would pose any additional 
threat. Having the traceback is lightly helpful when people actually do 
encounter bugs and report them.

--
priority: high -> normal

___
Python tracker 

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

[issue13122] Out of date links in the sidebar of the documentation index of versions 3.1 and 3.2

[Terry J. Reedy]

Terry J. Reedy  added the comment:

http://docs.python.org/release/2.6.7/
has the same problem that the 3.x 'in development' version is called 3.2, while 
there is no link to current stable 3.2.2 except indirectly by going to 'old 
versions' (which perhaps should be 'other versions'). I do not know enough 
about frames to know how to future-proof the sidebar better.

--

___
Python tracker 

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

[issue13122] Out of date links in the sidebar of the documentation index of versions 3.1 and 3.2

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Nobody said 3.2 was not stable...

Well, the sidebar says it's in development while 2.7 is stable :)

--
nosy: +pitrou

___
Python tracker 

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

[issue13122] Out of date links in the sidebar of the documentation index of versions 3.1 and 3.2

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Well, actually I do have an idea. When 3.3 comes out, I think docs.python.org 
should point to that, and another url should point to the most recent 2.7.x 
release. The url for all versions is already stable. Then the sidebar could 
have entries for most recent 3.x and 2.x releases (without specifying) and 
other versions.

--

___
Python tracker 

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

[issue13122] Out of date links in the sidebar of the documentation index of versions 3.1 and 3.2

[Terry J. Reedy]

Terry J. Reedy  added the comment:

My specific suggestion is that the sidebar be time-independent (for at least a 
decade, until Python 4 ;-) and say

Docs for other versions
  Current Python 3
  Current Python 2
  In development
  Everything else

with stable links for each.

--

___
Python tracker 

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

[issue13521] Make dict.setdefault() atomic

[Filip Gruszczyński]

Filip Gruszczyński  added the comment:

I understand you are talking about this call:

mp->ma_lookup(mp, key, hash);

I haven't noticed that earlier. I'll try to provide a better fix (for 2.7 
first, after we agree it's good enough, I will provide one for 3.3).

Do you have any idea, how I might this part? I mean how to check, that this is 
called only once?

--

___
Python tracker 

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

[issue13122] Out of date links in the sidebar of the documentation index of versions 3.1 and 3.2

[Georg Brandl]

Georg Brandl  added the comment:

Sounds good.

--

___
Python tracker 

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

[issue13717] print fails on unicode '\udce5' surrogates not allowed

[Atle Pedersen]

Atle Pedersen  added the comment:

Just wanted to say thanks for very fast response, and informative information.

I respect your decision to close the bug as invalid. But my five cent is that 
it still feels like a bug, something that shouldn't happen. Especially since 
it's part of a very basic function, and very unpredictable for inexperienced 
Python programmers.

I do understand your headache. I've had my share of character set issues in my 
time.

But thanks again for the quick reply, and suggested workarounds, which will 
work well for me and my situation.

--

___
Python tracker 

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

[issue13122] Out of date links in the sidebar of the documentation index of versions 3.1 and 3.2

[Terry J. Reedy]

Terry J. Reedy  added the comment:

To make my idea work both now and after we switch docs.python.org, that url 
should not be used as either of the first two links. Rather there should be a 
docs.python.org/py2k (or whatever) that is the permanent 'latest Python 2 
release' docs link.

--

___
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

[Michele Orrù]

Michele Orrù  added the comment:

There's no need to port your patch over python3k, since urllib behaves 
differently with http passwords - as you can see in the doc 
http://docs.python.org/dev/py3k/library/urllib.request.html#examples 

I would be glad to finish your password on 2.7 as soon as possible, joneskoo. 
Thanks.

--

___
Python tracker 

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

[issue13521] Make dict.setdefault() atomic

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Do you have any idea, how I might this part? I mean how to check, that
> this is called only once?

Checking that __eq__ is called only once should be a good proxy.

--

___
Python tracker 

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

[issue13521] Make dict.setdefault() atomic

[Filip Gruszczyński]

Filip Gruszczyński  added the comment:

Thanks, I'll try that. Like before I will probably find time next weekend.

--

___
Python tracker 

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

[issue13740] winsound.SND_NOWAIT ignored on modern Windows platforms

[Jelle Geerts]

New submission from Jelle Geerts :

As the attached example Python script explains, the winsound.SND_NOWAIT flag 
doesn't do anything, at least not on modern Windows platforms.

The updated MSDN documentation for PlaySound() states that SND_NOWAIT is not 
supported (it is ignored).
Link: 
http://msdn.microsoft.com/en-us/library/windows/desktop/dd743680%28v=vs.85%29.aspx

Assuming that the flag is supported on older Windows versions, I propose that 
the Python documentation is updated to state the same thing for SND_NOWAIT that 
it states for the SND_PURGE flag, which is the following:
"Note: This flag is not supported on modern Windows platforms."

Even though it might be that SND_NOWAIT was in fact never supported on any 
Windows version, the proposed change is at least better than not doing anything 
about it.

--
components: Windows
files: example.py
messages: 150915
nosy: bughunter2
priority: normal
severity: normal
status: open
title: winsound.SND_NOWAIT ignored on modern Windows platforms
type: behavior
Added file: http://bugs.python.org/file24182/example.py

___
Python tracker 

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

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

[Nick Coghlan]

Nick Coghlan  added the comment:

Thanks for that Charles-François - do you mind if I adapt that for walkdir?

The changes I would make are basically those that Antoine pointed out:
- rather than replacing the dirpath entry, instead yield a 4-tuple that appends 
the dirfd attribute at the end*
- if the dup(fd) fails, fall back to assuming top is a string or bytes path

*I'm still interested in opinions on this aspect. I see 5 main possibilities:
- (dirfd, subdirs, files) triple (problematic for the reasons Antoine pointed 
out)
- (dirpath, subdirs, files, dirfd) 4-tuple
- ((dirpath, dirfd), subdirs, files) nested tuple
- (dirpath, subdirs, files) tuple subclass with separate dirfd attribute
- (dirpath, subdirs, files) triple with dirpath as a str subclass with a 
separate fd attribute

I'm currently leaning towards the simple 4-tuple approach - it's simple, 
explicit and the walkdir pipeline operations can easily accept either 
underlying iterable by using indexing operations rather than tuple unpacking (a 
change I already planned to make so that the pipeline passed along the objects 
from the underlying iterable, anyway)

(I'll also need to create ctypes-based variants of all the relevant *at 
functions, since the stdlib wrappers won't be available in existing versions of 
Python)

--

___
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 would find ValueError surprising here. socket.error or SSLError would be less 
surprising ... even though it technically isn't completely true. But isn't it 
more like a kind of RuntimeError to call getpeercert after the socket has been 
closed?

--

___
Python tracker 

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

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

[Bithin A]

Bithin A  added the comment:

The bugs.python.org/review is a running application and it is very bad to see 
debug error messages.

--

___
Python tracker 

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

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

[Ross Lagerwall]

Ross Lagerwall  added the comment:

> I'm currently leaning towards the simple 4-tuple approach

I would also take that approach. It seems simplest to me.

--

___
Python tracker 

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

[issue13741] *** glibc detected *** python: double free or corruption (!prev): 0x0000000001d53ad0 ***

[Andrew]

New submission from Andrew :

Hello,
This program crashes after 12-24 hours of running.  My OS is Ubuntu 11.10, I'm 
using Python 2.7.2, and gcc 4.6.1.

Here's the error:

*** glibc detected *** python: double free or corruption (!prev): 
0x01d53ad0 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x78a96)[0x7fbd28c21a96]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x7fbd28c25d7c]
/usr/lib/python2.7/dist-packages/psycopg2/_psycopg.so(+0xd6aa)[0x7fbd27c806aa]
/usr/lib/python2.7/dist-packages/psycopg2/_psycopg.so(+0xde51)[0x7fbd27c80e51]
/usr/lib/python2.7/dist-packages/psycopg2/_psycopg.so(+0x13f9b)[0x7fbd27c86f9b]
/usr/lib/python2.7/dist-packages/psycopg2/_psycopg.so(+0x146c6)[0x7fbd27c876c6]
python(PyEval_EvalFrameEx+0x2f9)[0x4b6569]
python(PyEval_EvalFrameEx+0xb07)[0x4b6d77]
=== Memory map: 
0040-00633000 r-xp  08:06 1901460
/usr/bin/python2.7
00832000-00833000 r--p 00232000 08:06 1901460
/usr/bin/python2.7
00833000-0089c000 rw-p 00233000 08:06 1901460
/usr/bin/python2.7
0089c000-008ae000 rw-p  00:00 0 
01b3-01f26000 rw-p  00:00 0  [heap]
7fbd1dffc000-7fbd1dffd000 ---p  00:00 0 
7fbd1dffd000-7fbd1e7fd000 rw-p  00:00 0 
7fbd1e7fd000-7fbd1e7fe000 ---p  00:00 0 
7fbd1e7fe000-7fbd1effe000 rw-p  00:00 0 
7fbd1effe000-7fbd1efff000 ---p  00:00 0 
7fbd1efff000-7fbd1f7ff000 rw-p  00:00 0 
7fbd1f7ff000-7fbd1f80 ---p  00:00 0 
7fbd1f80-7fbd2000 rw-p  00:00 0 
7fbd2000-7fbd2011e000 rw-p  00:00 0 
7fbd2011e000-7fbd2400 ---p  00:00 0 
7fbd24411000-7fbd24426000 r-xp  08:06 1754089
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fbd24426000-7fbd24625000 ---p 00015000 08:06 1754089
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fbd24625000-7fbd24626000 r--p 00014000 08:06 1754089
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fbd24626000-7fbd24627000 rw-p 00015000 08:06 1754089
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fbd24627000-7fbd24628000 ---p  00:00 0 
7fbd24628000-7fbd24e28000 rw-p  00:00 0 
7fbd24e28000-7fbd24e34000 r-xp  08:06 1754109
/lib/x86_64-linux-gnu/libnss_files-2.13.so
7fbd24e34000-7fbd25033000 ---p c000 08:06 1754109
/lib/x86_64-linux-gnu/libnss_files-2.13.so
7fbd25033000-7fbd25034000 r--p b000 08:06 1754109
/lib/x86_64-linux-gnu/libnss_files-2.13.so
7fbd25034000-7fbd25035000 rw-p c000 08:06 1754109
/lib/x86_64-linux-gnu/libnss_files-2.13.so
7fbd25035000-7fbd2503f000 r-xp  08:06 1754113
/lib/x86_64-linux-gnu/libnss_nis-2.13.so
7fbd2503f000-7fbd2523f000 ---p a000 08:06 1754113
/lib/x86_64-linux-gnu/libnss_nis-2.13.so
7fbd2523f000-7fbd2524 r--p a000 08:06 1754113
/lib/x86_64-linux-gnu/libnss_nis-2.13.so
7fbd2524-7fbd25241000 rw-p b000 08:06 1754113
/lib/x86_64-linux-gnu/libnss_nis-2.13.so
7fbd25241000-7fbd25258000 r-xp  08:06 1754103
/lib/x86_64-linux-gnu/libnsl-2.13.so
7fbd25258000-7fbd25457000 ---p 00017000 08:06 1754103
/lib/x86_64-linux-gnu/libnsl-2.13.so
7fbd25457000-7fbd25458000 r--p 00016000 08:06 1754103
/lib/x86_64-linux-gnu/libnsl-2.13.so
7fbd25458000-7fbd25459000 rw-p 00017000 08:06 1754103
/lib/x86_64-linux-gnu/libnsl-2.13.so
7fbd25459000-7fbd2545b000 rw-p  00:00 0 
7fbd2545b000-7fbd25463000 r-xp  08:06 1754105
/lib/x86_64-linux-gnu/libnss_compat-2.13.so
7fbd25463000-7fbd25662000 ---p 8000 08:06 1754105
/lib/x86_64-linux-gnu/libnss_compat-2.13.so
7fbd25662000-7fbd25663000 r--p 7000 08:06 1754105
/lib/x86_64-linux-gnu/libnss_compat-2.13.so
7fbd25663000-7fbd25664000 rw-p 8000 08:06 1754105
/lib/x86_64-linux-gnu/libnss_compat-2.13.so
7fbd25664000-7fbd2566b000 r-xp  08:06 1754132
/lib/x86_64-linux-gnu/librt-2.13.so
7fbd2566b000-7fbd2586a000 ---p 7000 08:06 1754132
/lib/x86_64-linux-gnu/librt-2.13.so
7fbd2586a000-7fbd2586b000 r--p 6000 08:06 1754132
/lib/x86_64-linux-gnu/librt-2.13.so
7fbd2586b000-7fbd2586c000 rw-p 7000 08:06 1754132
/lib/x86_64-linux-gnu/librt-2.13.so
7fbd2586c000-7fbd2587a000 r-xp  08:06 1982536
/usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so
7fbd2587a000-7fbd25a7a000 ---p e000 08:06 1982536
/usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so
7fbd25a7a000-7fbd25a7b000 r--p e000 08:06 1982536
/usr/lib/python2.7/dist-packages/

[issue11990] redirected output - stdout writes newline as \n in windows

[Peter Csapo]

Peter Csapo  added the comment:

I have having the same issues as Jimbofbx. This seems to stem from changes due 
to issue 10841. All stdio is now opened in binary mode, in consideration that 
it is the TextIOWrapper's job to do endline translation.

The problem here is that the newline mode = '\n' for the TextIOWrapper created 
for stdout. ( see pythonrun.c: create_stdio() ). For windows, the newline mode 
for stdin is already set to null enabling universal newline translation on 
input, and it should be set to null for newline transation on output as well.

OLD CODE
newline = "\n";
#ifdef MS_WINDOWS
if (!write_mode) {
/* translate \r\n to \n for sys.stdin on Windows */
newline = NULL;
}
#endif


FIXED??? CODE
newline = "\n";
#ifdef MS_WINDOWS
/* translate \r\n to \n for sys.stdin on Windows */
/* translate \n to \r\n for sys.stdout on Windows */
newline = NULL;
#endif

--
nosy: +astrobuf

___
Python tracker 

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

[issue9116] test_capi.test_no_FatalError_infinite_loop crash on Windows

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I just got 'fatal error' running python_d 3.3.a0 checked out yesterday. When I 
closed message, test continued (but really crashed later).

--
nosy: +terry.reedy

___
Python tracker 

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

[issue11906] test_argparse failure in interactive mode

[Terry J. Reedy]

Terry J. Reedy  added the comment:

http://docs.python.org/devguide/runtests.html
"If you don’t have easy access to a command line, you can run the test suite 
from a Python or IDLE shell:
>>> from test import autotest"

However, argparse is the least of the test suite problems on Windows.
(#9116, #11732, other problems)

--

___
Python tracker 

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