[issue14974] rename packaging.pypi to packaging.index

[Westley Martínez]

Westley Martínez added the comment:

I think I like the term catalog myself, but I'm not wholly opposed to index.  I 
think it is certainly better than pypi.

Although the namespace does reduce the genericness of index, a lot of 
programmers (including me) like to use the from namespace import x method.  I 
think that's considerable.  That said, programmers could use from packaging 
import index as pindex or some sort to alleviate this.

--

___
Python tracker 

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

[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689

[Martin Mokrejs]

Martin Mokrejs added the comment:

Hi Stephen,
  I discussed the USE=debug here 
(https://bugs.gentoo.org/show_bug.cgi?id=482348) and it is denied by portage 
maintainers because it is not only a debug addition but a whole API change. We 
have to live with:

mkdir -p /etc/portage/env
echo 'EXTRA_ECONF="--with-pydebug"' > /etc/portage/env/pydebug.conf
echo dev-lang/python pydebug.conf >> /etc/portage/package.env


The above what I had originally. Yesterday I tried even:

# cat /etc/portage/env/pydebug.conf 
EXTRA_ECONF="--with-pydebug --without-pymalloc --with-valgrind"
#

but I don't know what the valgrind option really does and, whether that means:
a) python will run itself under valgrind, don't both doing it yourself
b) you don't have to bother with uncommenting the lines in valgrind.supp
c) "make install" will install the valgrind.supp but you have to edit it on 
your own
d) you may use valgrind but don't use other tool replacing malloc(), like 
electric fence, DUMA, etc.

Or some combination of them? :( The Readme.valgrind does not answer this at all.

I let DUMA inspect "emerge boost" run overnight but my computer stopped 
responding (16GB RAM).

I tried only gcc-4.7.3 and python-2.7.5-r2.

CFLAGS="-ggdb -pipe -msse  -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -msse4 -mavx 
-maes -mpclmul -mpopcnt -march=corei7-avx"
CXXFLAGS="${CFLAGS}"


Per comment from Charles-François, so you mean that this single-bit change 
won't be caught by valgrind, right? Why does not memtest86+ detect that? Could 
python when compiled with the --with-pydebug print also physical, hardware 
address of the wrong value? That would be really helpful here! Thanks.

--

___
Python tracker 

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

[issue18882] Add threading.main_thread() function

[Andrew Svetlov]

New submission from Andrew Svetlov:

We need public API for getting main thread object.
See also http://comments.gmane.org/gmane.comp.python.devel/141370

--
messages: 196521
nosy: asvetlov, haypo, pitrou
priority: normal
severity: normal
status: open
title: Add threading.main_thread() function
versions: Python 3.4

___
Python tracker 

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

[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689

[Stefan Krah]

Stefan Krah added the comment:

I uderstand that you are building Python using "emerge". I would try to get a 
release from python.org, do a normal build ...

make distclean
./configure --prefix=/tmp --with-pydebug --with-valgrind
make
make install

...

then install matplotlib using

/tmp/bin/python setup.py

...

then run (assuming you are in the build directory):

valgrind --suppressions=Misc/valgrind-python.supp /tmp/bin/python your_program

--
nosy: +skrah

___
Python tracker 

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

[issue14130] memoryview: add multi-dimensional indexing and slicing

[Stefan Krah]

Stefan Krah added the comment:

I would probably work on it (it's basically implemented in _testbuffer.c),
but I'm not sure if the NumPy community will actually use the feature.

--

___
Python tracker 

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

[issue17145] memoryview(array.array)

[Stefan Krah]

Stefan Krah added the comment:

The request is certainly valid, but the patch is tricky to review.

--

___
Python tracker 

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

[issue18874] Add a new tracemalloc module to trace memory allocations

[STINNER Victor]

STINNER Victor added the comment:

Ok, let's start with a first patch. It works in the common cases, because they 
are some corner cases like subinterpreter which might still crash.

The hook on PyMem_RawMalloc() takes the GIL. It is disabled because it has 
still bugs (it introduces a deadlock in some corner cases!)

--
keywords: +patch
Added file: http://bugs.python.org/file31517/tracemalloc.patch

___
Python tracker 

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

[issue18849] Failure to try another name for tempfile when directory with chosen name exists on windows

[Vlad Shcherbina]

Changes by Vlad Shcherbina :


--
keywords: +patch
Added file: http://bugs.python.org/file31518/fix_for_27.patch

___
Python tracker 

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

[issue18882] Add threading.main_thread() function

[Christian Heimes]

Changes by Christian Heimes :


--
nosy: +christian.heimes

___
Python tracker 

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

[issue18882] Add threading.main_thread() function

[Christian Heimes]

Christian Heimes added the comment:

The function must take care of fork() in worker threads, too. The 
isinstance(current_thread(), _MainThread) trick may not work.

--

___
Python tracker 

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

[issue16853] add a Selector to the select module

[Giampaolo Rodola']

Giampaolo Rodola' added the comment:

Follows a couple of minor concerns.

- What about Solaris' /dev/poll?

- I'm not sure why in case of EINTR you retry with a different timeout; can't 
you just return []? 

- this is probably because I'm paranoid about performances but given that 
select() method will be called repeatedly I would not use a decorator. Also, 
similarly to what has been done elsewhere in the stdlib, for "critical" parts I 
would recommend localizing variable access in order to minimize overhead as in:

def select(self, timeout=None):
... 
key_from_fd = self._key_from_fd
ready_append = ready.append
for fd in r | w:
...
key = key_from_fd(fd)
if key:
ready_append((key, events & key.events))

--

___
Python tracker 

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

[issue18780] SystemError when formatting int subclass

[Eli Bendersky]

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

[issue18882] Add threading.main_thread() function

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
nosy: +giampaolo.rodola

___
Python tracker 

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

[issue18882] Add threading.main_thread() function

[Antoine Pitrou]

Antoine Pitrou added the comment:

> The function must take care of fork() in worker threads, too. The
> isinstance(current_thread(), _MainThread) trick may not work.

Well, there are two possibilities:
- main_thread() returns the original _MainThread instance, even if it's
  dead in the child process
- main_thread() returns the main thread of the current process

Both are reasonable, but we must settle for one :-)

(also, the use case of forking from a thread is really obscure, I don't
think we should worry too much about it)

--

___
Python tracker 

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

[issue18882] Add threading.main_thread() function

[Andrew Svetlov]

Andrew Svetlov added the comment:

Patch with code and tests is attached.
Test fails when program forks from thread other than the main one.

--
keywords: +patch
Added file: http://bugs.python.org/file31519/issue18882.diff

___
Python tracker 

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

[issue18882] Add threading.main_thread() function

[Andrew Svetlov]

Andrew Svetlov added the comment:

signal module reinitializes main_thread variable in PyOS_AfterFork, threading 
does nothing with forking.

--

___
Python tracker 

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

[issue17741] event-driven XML parser

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8fd72b1bb262 by Eli Bendersky in branch 'default':
Issue #17741: Rename IncrementalParser and its methods.
http://hg.python.org/cpython/rev/8fd72b1bb262

--

___
Python tracker 

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

[issue18852] site.py does not handle readline.__doc__ being None

[Berker Peksag]

Changes by Berker Peksag :


--
nosy: +berker.peksag

___
Python tracker 

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

[issue17741] event-driven XML parser

[Eli Bendersky]

Eli Bendersky added the comment:

This issue has become too large and discusses a few different things; hence I'm 
inclined to close it as fixed and open a new one as a placeholder for 
discussing the new design of the internals.

I'll do this in a couple of days if there are no objections.

--

___
Python tracker 

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

[issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG

[Martin Mokrejs]

New submission from Martin Mokrejs:

Looks I cannot compile when python-3.3 was configured with --with-pydebug. I 
use Gentoo Linux, the -r2 shows they added some patches but should not matter I 
think.

building 'xxlimited' extension
x86_64-pc-linux-gnu-gcc -pthread -fPIC -Wno-unused-result 
-DDYNAMIC_ANNOTATIONS_ENABLED=1 -O2 -pipe -msse -msse2 -msse3 -mssse3 -msse4.1 
-msse4.2 -msse4 -mavx -maes -mpclmul -mpopcnt -march=corei7-avx 
-fstack-protector-all -fwrapv -DPy_LIMITED_API=1 -IInclude -I. 
-I/mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Include 
-I/mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/x86_64-pc-linux-gnu -c 
/mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Modules/xxlimited.c
 -o 
build/temp.linux-x86_64-3.3-pydebug/mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Modules/xxlimited.o
In file included from 
/mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Include/Python.h:68:0,
 from 
/mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Modules/xxlimited.c:17:
/mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Include/object.h:65:2:
 error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and 
Py_REF_DEBUG


I think make should ignore this error unless you fix xxlimited.c sources.

--
files: build.log
messages: 196534
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is 
incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file31520/build.log

___
Python tracker 

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

[issue18882] Add threading.main_thread() function

[Andrew Svetlov]

Andrew Svetlov added the comment:

http://bugs.python.org/issue16500 is required to make work after fork from 
thread other than the main one.

--
dependencies: +Add an 'atfork' module

___
Python tracker 

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

[issue16853] add a Selector to the select module

[Charles-François Natali]

Charles-François Natali added the comment:

Hello,

> - What about Solaris' /dev/poll?

That should be pretty easy to add by someone who has access to a
Solaris box: I could use the buildbots, but it'd take a couple
iterations to get it right.

> - I'm not sure why in case of EINTR you retry with a different timeout; can't 
> you just return []?

Because when I do:
selector.select(10)

I expect the selector to wait 10 seconds if no event occurs: the fact
that a signal comes in shouldn't break the contract made by the API,
i.e. that it will return when a FD is ready or the timeout expires.
Early return can lead to spurious errors: just imagine you send a
request to a busy server: it would be bad to raise a timeout error
just because the user put the client in the background with CTRL-Z
(which results in SIGSTOP).

> - this is probably because I'm paranoid about performances but given that 
> select() method will be called repeatedly I would not use a decorator. Also, 
> similarly to what has been done elsewhere in the stdlib, for "critical" parts 
> I would recommend localizing variable access in order to minimize overhead as 
> in:
>
> def select(self, timeout=None):
> ...
> key_from_fd = self._key_from_fd
> ready_append = ready.append
> for fd in r | w:
> ...
> key = key_from_fd(fd)
> if key:
> ready_append((key, events & key.events))

I find that localizing variables leads to unreadable code, and is tied
to the current CPython interpreter implementation: such optimizations
belong to the interpreter, not user code.

As for the decorator performance overhead, I don't think it weights
much compared to the cost of a syscall (+ GIL acquire/release):
with decorator:
$ ./python -m timeit -s "from selectors import DefaultSelector,
EVENT_WRITE; import os; s = DefaultSelector();
s.register(os.pipe()[1], EVENT_WRITE)" "s.select()"
10 loops, best of 3: 3.69 usec per loop
without decorator:
$ ./python -m timeit -s "from selectors import DefaultSelector,
EVENT_WRITE; import os; s = DefaultSelector();
s.register(os.pipe()[1], EVENT_WRITE)" "s.select()"
10 loops, best of 3: 3.52 usec per loop

That's a 4% overhead, with a single FD that's always ready (and I
suspect that most of the overhead is due to the call to time(), not
the decorator per se).

Also, I'll shortly propose a patch to handle EINTR within C code, so
those EINTR wrappers won't  be needed anymore.

--

___
Python tracker 

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

[issue16853] add a Selector to the select module

[Giampaolo Rodola']

Giampaolo Rodola' added the comment:

> That should be pretty easy to add by someone who has access to a
> Solaris box: I could use the buildbots, but it'd take a couple
> iterations to get it right.

I can probably help with that.

--

___
Python tracker 

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

[issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost

[Martin Mokrejs]

New submission from Martin Mokrejs:

It is not important why I had in this moment matplotlib not in sync with python 
itself whcih was configure using --with-pydebug ... but here I just want to 
show that maybe you do not test for memleaks using valgrind on import errors 
(maybe include such testcase into you tests).
Anyway, here is what I got:


==14007== Memcheck, a memory error detector
==14007== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==14007== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==14007== Command: /usr/bin/python2.7 blah.py
==14007== 
Traceback (most recent call last):
  File "blah.py", line 288, in 
import pylab
  File "/usr/lib64/python2.7/site-packages/pylab.py", line 1, in 
from matplotlib.pylab import *
  File "/usr/lib64/python2.7/site-packages/matplotlib/pylab.py", line 222, in 

from matplotlib import mpl  # pulls in most modules
  File "/usr/lib64/python2.7/site-packages/matplotlib/mpl.py", line 1, in 

from matplotlib import artist
  File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 7, in 

from transforms import Bbox, IdentityTransform, TransformedBbox, \
  File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 35, 
in 
from matplotlib._path import (affine_transform, 
count_bboxes_overlapping_bbox,
ImportError: /usr/lib64/python2.7/site-packages/matplotlib/_path.so: undefined 
symbol: _PyMem_DebugFree
[100070 refs]
==14007== 
==14007== HEAP SUMMARY:
==14007== in use at exit: 6,303,492 bytes in 31,921 blocks
==14007==   total heap usage: 1,266,299 allocs, 1,234,378 frees, 179,304,947 
bytes allocated
==14007== 
==14007== 40 bytes in 1 blocks are definitely lost in loss record 167 of 3,515
==14007==at 0x4C2C63B: malloc (vg_replace_malloc.c:270)
==14007==by 0x4EF1E8C: PyMem_Malloc (object.c:2343)
==14007==by 0x10064848: initialize_builtin_datetime_metadata 
(arraytypes.c.src:3953)
==14007==by 0x100719E2: set_typeinfo (arraytypes.c.src:4047)
==14007==by 0x1016354E: initmultiarray (multiarraymodule.c:4057)
==14007==by 0x4FB2661: _PyImport_LoadDynamicModule (importdl.c:53)
==14007==by 0x4FAE3A7: load_module (import.c:1915)
==14007==by 0x4FB07C1: import_submodule (import.c:2700)
==14007==by 0x4FAFCC6: load_next (import.c:2515)
==14007==by 0x4FAED8B: import_module_level (import.c:2224)
==14007==by 0x4FAF320: PyImport_ImportModuleLevel (import.c:2288)
==14007==by 0x4F78862: builtin___import__ (bltinmodule.c:49)

--
components: Interpreter Core
messages: 196538
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost
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

[issue18720] Switch suitable constants in the socket module to IntEnum

[Eli Bendersky]

Eli Bendersky added the comment:

[Thanks, Guido]

Attaching patch with SOCK_* constants converted as well. The module globals are 
currently walked twice, once to extract AF_* and once SOCK_*. This is not a 
real performance problem, but should we fold it into a single loop that 
collects two dicts? The code will be less pretty but more efficient.

Another issue is _intenum_converter. Ethan - do you think it belongs in the 
enum module as a helper function or something of the sort?

--
Added file: http://bugs.python.org/file31521/socket-intenum-af-type.6.patch

___
Python tracker 

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

[issue18882] Add threading.main_thread() function

[Antoine Pitrou]

Antoine Pitrou added the comment:

> http://bugs.python.org/issue16500 is required to make work after
> fork from thread other than the main one.

No it isn't. Please take a look at _after_fork() in threading.py.

--
dependencies:  -Add an 'atfork' module

___
Python tracker 

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

[issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +haypo, pitrou, skrah
type:  -> resource usage

___
Python tracker 

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

[issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG

[Stefan Krah]

Stefan Krah added the comment:

A similar issue was closed, see msg157249. The error looks deliberate
to me, so let's close this, too.

--
nosy: +skrah
resolution:  -> works for me
status: open -> closed

___
Python tracker 

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

[issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
priority: normal -> low

___
Python tracker 

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

[issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG

[R. David Murray]

R. David Murray added the comment:

I'm curious how this error gets triggered.  I build python --with-pydebug on 
Gentoo all the time, albeit from a checkout, and I've never seen it.  I'm 
imagining that means it is a Gentoo bug.  Well, not even really a bug, since 
Gentoo doesn't itself support emerging python in debug mode.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG

[Martin Mokrejs]

Martin Mokrejs added the comment:

See for what I did to Gentoo: http://bugs.python.org/issue18843#msg196520

--

___
Python tracker 

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

[issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG

[Martin Mokrejs]

Martin Mokrejs added the comment:

Uh. I don't understand. So did you want to say I should not run configure 
--with-pydebug in python 3.3 or what? I am fine if you fix the Makefile not to 
exit on this particular file. I am missing something.

--

___
Python tracker 

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

[issue14974] rename packaging.pypi to packaging.index

[Éric Araujo]

Éric Araujo added the comment:

The issue is moot now that packaging/distutils2 is stopped.

--
resolution:  -> out of date
stage: needs patch -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue14914] pysetup installed distribute despite dry run option being specified

[Éric Araujo]

Éric Araujo added the comment:

Contrary to other issues that are relevant to distlib/pip/others, this one can 
be closed.

--
resolution:  -> out of date
stage: test needed -> 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

[issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG

[Stefan Krah]

Stefan Krah added the comment:

Martin, msg196534 shows that you are building with -DPy_LIMITED_API=1.
You can either use the limited API or --with-pydebug, but not both.

[As I said in the other issue, IMHO it is better to use a minimal set
of build options when reporting bugs.]

--

___
Python tracker 

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

[issue18859] README.valgrind should mention --with-valgrind

[Martin Mokrejs]

Martin Mokrejs added the comment:

Moreover, it should explain what that really does. One could think of several 
answers or even their combinations what this configure flag will really do:

a) python will run itself under valgrind, don't bother ever doing it yourself
b) you don't have to bother with uncommenting the lines in valgrind.supp
c) "make install" will install the valgrind.supp but you have to edit it on 
your own
d) you may use valgrind but don't use other tool replacing malloc(), like 
electric fence, DUMA, etc. You should be quite verbose how (in)compatible is 
this with other tools.

Or some combination of them?

valgrind docs say it won't work if a binary lacks debug symbols (wasn't 
compiled with -g). Initially I got mislead I though I have to convert my 
blah.py to blah.c using cython, compile that with "gcc -ggdb blah.c" and then I 
may run valgrind on the binary.

In the end, I don't understand why everybody has to remove the comment symbols 
from the valgrind-python.supp file at all. Why isn't that by default enabled?



I also suggest you mention right in the file other handy information because 
people quite likely get on this path while chasing memory corruption issues, 
maybe broken hardware:

1. Mention that python uses 256kB chunks by default.
2. Mention there exists --without-pymalloc as Tim explained me in 
http://bugs.python.org/issue18843#msg196492
3. Explain how to interpret those stacktraces one could get: 
http://bugs.python.org/issue18843#msg196481

Thank you!

--
nosy: +mmokrejs

___
Python tracker 

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

[issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG

[Martin Mokrejs]

Martin Mokrejs added the comment:

Hmm, but I did not add -DPy_LIMITED_API=1. Python 2.7.5 can be compiled using 
same configuration. Going back to the build.log file I see:

configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu 
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share 
--sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --with-fpectl 
--enable-shared --disable-ipv6 --with-threads --infodir=${prefix}/share/info 
--mandir=${prefix}/share/man --with-computed-gotos --with-dbmliborder=gdbm 
--with-libc= --enable-loadable-sqlite-extensions --with-system-expat 
--with-system-ffi --with-pydebug --without-pymalloc --with-valgrind


I specified only "--with-pydebug --without-pymalloc --with-valgrind". So where 
does the limited API come from? Bug in configure.ac?

--

___
Python tracker 

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

[issue18720] Switch suitable constants in the socket module to IntEnum

[Guido van Rossum]

Guido van Rossum added the comment:

I prefer two prettier loops over one less pretty one in this case. No
opinion about _intenum_converter yet. (IMO refactoring can always be lazy,
i.e. after you have multiple copies of the same code there's time to
consider whether you should unify them and what the pros and cons are.)

On Fri, Aug 30, 2013 at 6:55 AM, Eli Bendersky wrote:

>
> Eli Bendersky added the comment:
>
> [Thanks, Guido]
>
> Attaching patch with SOCK_* constants converted as well. The module
> globals are currently walked twice, once to extract AF_* and once SOCK_*.
> This is not a real performance problem, but should we fold it into a single
> loop that collects two dicts? The code will be less pretty but more
> efficient.
>
> Another issue is _intenum_converter. Ethan - do you think it belongs in
> the enum module as a helper function or something of the sort?
>
> --
> Added file:
> http://bugs.python.org/file31521/socket-intenum-af-type.6.patch
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG

[Stefan Krah]

Stefan Krah added the comment:

I think I understand now: If you used the strategy from msg196520,
of course you get the Gentoo flags.

What you really should do is download a release or get a checkout
from hg.python.org and build that _without_ using "emerge".

--

___
Python tracker 

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

[issue18844] allow weights in random.choice

[Mark Dickinson]

Mark Dickinson added the comment:

[Madison May]
>  - Should negative weights cause a ValueError to be raised, or should they be 
> converted to 0s?
>  - Should passing a list full of zeros as the weights arg raise a ValueError 
> or be treated as if no weights arg was passed?

Both those seem like clear error conditions to me, though I think it would be 
fine if the second condition produced a ZeroDivisionError rather than a 
ValueError.

I'm not 100% sold on the feature request.  For one thing, the direct 
implementation is going to be inefficient for repeated sampling, building the 
table of cumulative sums each time random.choice is called.  A more efficient 
approach for many use-cases would do the precomputation once, returning some 
kind of 'distribution' object from which samples can be generated.  (Walker's 
aliasing method is one route for doing this efficiently, though there are 
others.)  I agree that this is a commonly needed and commonly requested 
operation;  I'm just not convinced either that an efficient implementation fits 
well into the random module, or that it makes sense to add an inefficient 
implementation.

--
nosy: +tim.peters

___
Python tracker 

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

[issue18885] handle EINTR in the stdlib

[Charles-François Natali]

New submission from Charles-François Natali:

As discussed in 
http://mail.python.org/pipermail/python-dev/2013-August/128204.html, I think 
that we shouldn't let EINTR leak to Python code: it should be handled properly 
by the C code, so that users (and the Python part of the stdlib) don't have to 
worry about this low-level historical nuisance.

For code that doesn't release the GIL, we could simply use this glibc macro:
# define TEMP_FAILURE_RETRY(expression) \
  (__extension__  \
({ long int __result; \
   do __result = (long int) (expression); \
   while (__result == -1L && errno == EINTR); \
   __result; }))
#endif

Now, I'm not sure about how to best handle this for code that releases the GIL.

Basically:

Py_BEGIN_ALLOW_THREADS
pid = waitpid(pid, &status, options);
Py_END_ALLOW_THREADS

should become

begin_handle_eintr:
Py_BEGIN_ALLOW_THREADS
pid = waitpid(pid, &status, options);
Py_END_ALLOW_THREADS

if (pid < 0 && errno == EINTR) {
if (PyErr_CheckSignals())
return NULL;
goto begin_handle_eintr;
}

Should we do this with a macro?

If yes, should it be a new one that should be placed around 
Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS (like BEGIN_SELECT_LOOP in 
selectmodule.c) or could we have a single macro that would do both (i.e. 
release the GIL / reacquire the GIL, and try again in case of EINTR, unless a 
signal handler raised an exception)?

>From a cursory look, the main files affected would be:
Modules/fcntlmodule.c
Modules/ossaudiodev.c
Modules/posixmodule.c
Modules/selectmodule.c
Modules/selectmodule.c
Modules/signalmodule.c
Modules/socketmodule.c
Modules/syslogmodule.c

--
messages: 196555
nosy: neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: handle EINTR in the stdlib
type: enhancement
versions: Python 3.4

___
Python tracker 

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

[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689

[Charles-François Natali]

Charles-François Natali added the comment:

2013/8/30 Martin Mokrejs :
> Per comment from Charles-François, so you mean that this single-bit change 
> won't be caught by valgrind, right? Why does not memtest86+ detect that? 
> Could python when compiled with the --with-pydebug print also physical, 
> hardware address of the wrong value? That would be really helpful here! 
> Thanks.

I mean that in the vast majority of cases, a single bit flip is due to
a hardware error.
That can be due to faulty RAM, electric noise, cosmic rays...

Software-induced memory corruptions generally corrupt at least a byte.

Do you reproduce the crash systematically, or is it random?

--

___
Python tracker 

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

[issue18885] handle EINTR in the stdlib

[Charles-François Natali]

Changes by Charles-François Natali :


--
nosy: +haypo, pitrou, sbt

___
Python tracker 

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

[issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG

[R. David Murray]

R. David Murray added the comment:

Python2 doesn't support the limited ABI, so that flag is a noop for 2.7.

--

___
Python tracker 

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

[issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG

[Martin Mokrejs]

Martin Mokrejs added the comment:

So I conclude that you want to say that some of the configure flags is wrong? 
Which? I can surely report that at Gentoo. I still think Makefile should be 
changed so that it make does not even try to compile xxlimited.c if 
-DPy_LIMITED_API=1 is in CFLAGS regardless how that happened.

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-lang/python/

Look into the python-3.3.2-r2.ebuild file for what it does, and how does differ 
from 3.7.5-r2.ebuild which can be compiled fine through emerge abd thsoe 3 
configure arguments I requested.

--

___
Python tracker 

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

[issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG

[Stefan Krah]

Stefan Krah added the comment:

Well, these look like Gentoo build flags. Did you or "emerge" or
anything else export CFLAGS in the shell?

--

___
Python tracker 

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

[issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost

[Martin Mokrejs]

Martin Mokrejs added the comment:

Why do you think so? My point is that this happens when import fails. But 
python is at fault and should handle import errors.

--

___
Python tracker 

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

[issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost

[STINNER Victor]

STINNER Victor added the comment:

According to traces, the leak does not come from Python but matplotlib. Please 
report the issue to matplotlib bug tracker.

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

___
Python tracker 

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

[issue18438] Obsolete url in comment inside decimal module

[Stefan Krah]

Stefan Krah added the comment:

Wikipedia sounds good. Let's avoid linking directly to "free" versions. :)

--

___
Python tracker 

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

[issue18852] site.py does not handle readline.__doc__ being None

[Berker Peksag]

Berker Peksag added the comment:

Here's a patch with a comment about using pyreadline on Windows.

Should the note in the readline documentation[1] be updated?

[1] http://docs.python.org/3.4/library/readline.html

(See also issue 5845 and msg123703)

--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31522/issue18852.diff

___
Python tracker 

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

[issue18418] Thread.isAlive() sometimes True after fork

[Charles-François Natali]

Changes by Charles-François Natali :


--
nosy: +pitrou
stage: patch review -> commit review
versions: +Python 3.3, Python 3.4

___
Python tracker 

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

[issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost

[Tim Peters]

Tim Peters added the comment:

The matplotlib people won't care about this one either.  matplotlib allocated 
the memory, and the error message at the end says it's _trying_ to call 
_PyMem_DebugFree (which may well be trying to release the memory), but the 
binaries aren't compatible:  _PyMem_DebugFree doesn't exist.  That's on you, 
not on matplotlib or on Python - you're mixing together binaries that can't 
possibly work together.

So if this bug is re-opened, it should be assigned to you to fix it ;-)

--
nosy: +tim.peters

___
Python tracker 

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

[issue18709] SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238)

[Charles-François Natali]

Changes by Charles-François Natali :


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

[issue18844] allow weights in random.choice

[Madison May]

Madison May added the comment:

[Mark Dickinson]
> Both those seem like clear error conditions to me, though I think it would be 
> fine if the second condition produced a ZeroDivisionError rather than a 
> ValueError.

Yeah, in hindsight it makes sense that both of those conditions should raise 
errors.  After all: "Explicit is better than implicit".

As far as optimization goes, could we potentially use functools.lru_cache to 
cache the cumulative distribution produced by the weights argument and optimize 
repeated sampling? 

Without @lru_cache:
>>> timeit.timeit("x = choice(list(range(100)), list(range(100)))", setup="from 
>>> random import choice", number=10)
36.7109281539997

With @lru_cache(max=128):
>>> timeit.timeit("x = choice(list(range(100)), list(range(100)))", setup="from 
>>> random import choice", number=10)
6.6788657720007905

Of course it's a contrived example, but you get the idea.

Walker's aliasing method looks intriguing.  I'll have to give it a closer look. 
 

I agree that an efficient implementation would be preferable but would feel out 
of place in random because of the return type.  I still believe a relatively 
inefficient addition to random.choice would be valuable, though.

--

___
Python tracker 

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

[issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost

[Martin Mokrejs]

Martin Mokrejs added the comment:

Of course I did recompile matplotlib to use the recompiled python with debug 
ABI. I just don't understand why if something is not leaded why a memleak has 
to happen.

Anyway, now my application using the recompiled matplotlib baffled this through 
valgrind as well. An there was no ImportError: ;-)


==17489== 40 bytes in 1 blocks are definitely lost in loss record 718 of 5,487
==17489==at 0x4C2C63B: malloc (vg_replace_malloc.c:270)
==17489==by 0x4EF1E8C: PyMem_Malloc (object.c:2343)
==17489==by 0x10064848: initialize_builtin_datetime_metadata 
(arraytypes.c.src:3953)
==17489==by 0x100719E2: set_typeinfo (arraytypes.c.src:4047)
==17489==by 0x1016354E: initmultiarray (multiarraymodule.c:4057)
==17489==by 0x4FB2661: _PyImport_LoadDynamicModule (importdl.c:53)
==17489==by 0x4FAE3A7: load_module (import.c:1915)
==17489==by 0x4FB07C1: import_submodule (import.c:2700)
==17489==by 0x4FAFCC6: load_next (import.c:2515)
==17489==by 0x4FAED8B: import_module_level (import.c:2224)
==17489==by 0x4FAF320: PyImport_ImportModuleLevel (import.c:2288)
==17489==by 0x4F78862: builtin___import__ (bltinmodule.c:49)


This is probably because I also added --without-pymalloc as you wanted.

--

___
Python tracker 

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

[issue18852] site.py does not handle readline.__doc__ being None

[Ned Deily]

Ned Deily added the comment:

The use of libedit is not restricted to OS X; in particular, some other 
BSD-derived distributions use it.  There are some other open issues regarding 
generalization of support for libedit.  So I don't think the proposed comments 
should be added to site.py.  The docs for the readline module do not give a 
detailed code example (yet) so there's nothing to update there (yet).

--
nosy: +ned.deily

___
Python tracker 

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

[issue18709] SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238)

[Charles-François Natali]

Charles-François Natali added the comment:

Oops.

--
status: closed -> open

___
Python tracker 

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

[issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost

[Martin Mokrejs]

Changes by Martin Mokrejs :


Added file: 
http://bugs.python.org/file31523/valgrind_python275_without-pymalloc.txt

___
Python tracker 

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

[issue18709] SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238)

[Christian Heimes]

Christian Heimes added the comment:

It's not fixed in 3.1 and 3.2 yet. Please re-open the issue. I can't do it 
because I'm not at home.

"Charles-François Natali"  schrieb:
>
>Changes by Charles-François Natali :
>
>
>--
>resolution:  -> fixed
>stage: patch review -> committed/rejected
>status: open -> closed
>
>___
>Python tracker 
>
>___

--
title: SSL module fails to handle NULL bytes inside subjectAltNames general 
names (CVE-2013-4238) -> SSL module fails to handle NULL bytes inside   
subjectAltNames general names (CVE-2013-4238)

___
Python tracker 

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

[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689

[Tim Peters]

Tim Peters added the comment:

Martin, would it be possible to borrow someone else's machine and try to 
reproduce this?  If you can, that would greatly reduce the probability of this 
being a HW error.  It would also leave us with an exact set of commands to 
share so others can try it on their boxes.

It's true that SW memory corruption usually affects several contiguous bytes, 
but "usually" != "always" ;-)

--

___
Python tracker 

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

[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689

[Martin Mokrejs]

Martin Mokrejs added the comment:

I think it would be of tremendous help if python reported the physical memory 
address though do not know how much work is that for you. I already said that, 
I wonder why memtest86+ could not find an error, I even tried other tools for 
that. Could --with-pydebug immediately after writing those pad bytes try to 
read them back, just to make sure they are readable? Theoretically one could 
catch the wrong bit of memory immediately.

It is random, I think CPU must be fully loaded for a long while, plus something 
unknown has to kick in. Maybe that has to heat up the memory modules to cause 
the failure. My motherboard is already 3rd but doubt it is at fault, except 
that the SandyBridge chip is bad by design. Was replaced few days ago with CPU 
cooler (was the main reason for technician to come). I take that replacing 
motherboard was a nice offer from Dell. I would instead think that maybe CPU is 
heating too much.

BIOS is weird. ACPI and PCIe ASPM are exploiting Linux kernel hotplug support 
and PCI developers are puzzled. I experience that SandyBridge resets e.g. its 
USB2.0 controller if there was a hotplug even on some of its other root ports 
(express card was inserted/ejected). But in overall I don't think it is a bad 
deal and it works. These exceptional glitches are I think a software error or 
BIOS error. It just wouldn't be running all the days and nights. No, it is not 
overheated, at least not now with the replaced cooler.

I can put in other memory module (with which I bought the laptop from Dell). 
Other than that, hmm ... I could take out the hard drive and attach it to some 
other computer, boot from Live-DVD ... the problem is I need a lot of RAM for 
some of my stuff and it would have to be relatively same CPU type (I compiled 
binaries with avx). Yes, the emerge crash definitely was another case, I could 
hope to get that happen on even 1GB RAM machine, sure. I just don't have a 
testcase for that to trigger. I tried to stitch something but no, I probably 
coded something not going in the right direction. If you would have the time to 
stitch down some test for me to execute with the garbage collector calls, it 
would be probably the best.

--

___
Python tracker 

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

[issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost

[Tim Peters]

Tim Peters added the comment:

Now you have something to show the matplotlib folks - although they're not 
likely to get excited about leaking 40 bytes.

There is nothing Python can do about this.  matplotlib is responsible for 
free'ing the memory matplotlib allocates, just as Python is responsible for 
free'ing the memory Python allocates.  If _you_ wrote a C extension module, and 
did

char *p = (char *)malloc(40);

and never did a free(p) later, it would be the same kind of thing.

--

___
Python tracker 

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

[issue18886] BytesGenerator does not handle 'binary' CTE correctly

[R. David Murray]

New submission from R. David Murray:

ByteGenerator will assume that it can change any linesep characters to the 
linesep being used for the general message serialization, even if the content 
transfer encoding is 'binary'.  This is incorrect, as existing \r and \n 
characters in binary parts must be retained exactly as is.

--
components: email
messages: 196572
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: BytesGenerator does not handle 'binary' CTE correctly
type: behavior
versions: Python 3.3, Python 3.4

___
Python tracker 

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

[issue16853] add a Selector to the select module

[Giampaolo Rodola']

Giampaolo Rodola' added the comment:

I'm playing with devpoll on Open Solaris and it seems it works exactly as 
poll(). Basically a copy & paste of PollSelector class with a different 
self._poll attribute will suffice.
With dev/poll support you now have 3 classes (PollSelector, EpollSelector, 
DevpollSelector) which look basically the same except for very little details. 
It looks like there's space for some code reuse / refactoring.

--

___
Python tracker 

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

[issue18840] Tutorial recommends pickle module without any warning of insecurity

[Terry J. Reedy]

Terry J. Reedy added the comment:

For the tutorial, I agree with presenting json rather than pickle for all the 
reasons given, with pickle mentioned in a paragraph at the end (more powerful, 
more dangerous, see warning in manual before using).

--
nosy: +terry.reedy
stage:  -> needs patch

___
Python tracker 

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

[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689

[Tim Peters]

Tim Peters added the comment:

OK, it sounds to me like you do not have a reproducible test case, of any kind. 
 It that's true, this bug report isn't going anywhere :-(

Python isn't a memory-testing program, so it would be insanely inefficient for 
it to (for example) read up every byte it writes, just to make sure the memory 
isn't bad.  If you want to alter the source of _your_ Python to do that, fine!  
It won't go into the official distribution, but it might help you.

For the same reason, core Python won't go into the business of sorting out 
various kinds of memory addresses.  User-level code (including Python) works 
with the virtual (logical) addresses the operating system gives it.  For a hint 
of some of the difficulties in going deeper than that, here's a note from Linus 
Torvalds:

http://www.tldp.org/LDP/khg/HyperNews/get/devices/addrxlate.html

About "If you would have the time to stitch down some test for me to execute 
with the garbage collector calls, it would be probably the best."  I'm not sure 
what you're suggesting there.  That we write a Python program that tries to 
trigger errors in your BIOS?  LOL - not likely ;-)

If you want to force a lot of allocations, deallocations, and gc runs, 
something like this will do it:

"""
def stress():
import gc

class C(object):
def __init__(self):
self.loop = self

N = 50
d = dict((C(), C()) for i in xrange(N))
j = 0
while 1:
for i in xrange(N // 2):
d.popitem()
for i in xrange(N // 2):
d[C()] = C()
j += 1
if j % 10 == 0:
print j
gc.set_debug(gc.DEBUG_STATS)
gc.collect()
gc.set_debug(0)

stress()
"""

Setting N larger will make it consume more RAM.  The output is essentially 
meaningless, produced just so you know it's still running.

--

___
Python tracker 

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

[issue18418] Thread.isAlive() sometimes True after fork

[Antoine Pitrou]

Antoine Pitrou added the comment:

Well... I can't say anything except that the patch looks harmless.
It's a pity the test failure is hard to trigger, though.

--

___
Python tracker 

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

[issue18845] 2.7.5-r2: Fatal Python error: Segmentation fault

[Terry J. Reedy]

Terry J. Reedy added the comment:

I think this should be closed as extremely likely to be a matplotlib error.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue18826] reversed() requires a sequence - Could work on any iterator?

[Terry J. Reedy]

Terry J. Reedy added the comment:

The two cases are not parallel.
  a = sorted(b)
abbreviates
  a = list(b)
  a.sorted()
which occurred often enough to be a nuisance. With this proposal,
  a = reversed(b)
would abbreviate
  a = reversed(list(b))
which is probably less common and certainly less obnoxious than the two lines 
condensed by sorted.

A second problem: reversed already has a fallback default if (a presumably more 
efficient or effective) b.__reversed__ does not exit:

n = len(b)
a = [None]*n
for i,j in enumerate(range(n-1, -1, -1)): # reversed(range(n))
  a[i] = b[j]

(I believe this is more efficient, at least in C, than
  a = []
  for i in range(len(b)-1, -1, -1):
a.append(b[i])
but it is hard to know.)

At what point, and under what conditions, would you introduce the second 
fallback?

--
nosy: +terry.reedy

___
Python tracker 

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

[issue18855] Inconsistent README filenames

[Terry J. Reedy]

Terry J. Reedy added the comment:

README.txt is also used in lib/idlelib and lib/idlelib/idle_test. In the latter 
case, I was told to use this.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue18418] Thread.isAlive() sometimes True after fork

[Roundup Robot]

Roundup Robot added the comment:

New changeset ba54011aa295 by Charles-François Natali in branch '2.7':
Issue #18418: After fork(), reinit all threads states, not only active ones.
http://hg.python.org/cpython/rev/ba54011aa295

New changeset 29fce7f31539 by Charles-François Natali in branch '3.3':
Issue #18418: After fork(), reinit all threads states, not only active ones.
http://hg.python.org/cpython/rev/29fce7f31539

New changeset 8f39e2f987fb by Charles-François Natali in branch 'default':
Issue #18418: After fork(), reinit all threads states, not only active ones.
http://hg.python.org/cpython/rev/8f39e2f987fb

--
nosy: +python-dev

___
Python tracker 

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

[issue18831] importlib.import_module() bypasses builtins.__import__

[Terry J. Reedy]

Terry J. Reedy added the comment:

The discrepancy between doc and code should be eliminated. In this case, it 
seems the doc should be changed (in 3.3 as well). Would 'not' in the right 
place suffice?

--
nosy: +terry.reedy

___
Python tracker 

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

[issue18851] subprocess's Popen closes stdout/stderr filedescriptors used in another thread when Popen errors

[Roundup Robot]

Roundup Robot added the comment:

New changeset 43749cb6bdbd by Antoine Pitrou in branch '2.7':
Issue #18851: Avoid a double close of subprocess pipes when the child process 
fails starting.
http://hg.python.org/cpython/rev/43749cb6bdbd

--
nosy: +python-dev

___
Python tracker 

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

[issue18831] importlib.import_module() bypasses builtins.__import__

[Brett Cannon]

Brett Cannon added the comment:

Not sure what doc discrepancy you are talking about, Terry. The docs for 
importlib are totally accurate which means no one has been accidentally mislead 
by them. This bug is about whether importlib.import_module() bypassing 
builtins.__import__ is a big enough deal to change or not.

--

___
Python tracker 

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

[issue18851] subprocess's Popen closes stdout/stderr filedescriptors used in another thread when Popen errors

[Roundup Robot]

Roundup Robot added the comment:

New changeset c11754defe1c by Antoine Pitrou in branch '3.3':
Forward port new tests from Issue #18851.
http://hg.python.org/cpython/rev/c11754defe1c

New changeset 290ca31d4cfe by Antoine Pitrou in branch 'default':
Forward port new tests from Issue #18851.
http://hg.python.org/cpython/rev/290ca31d4cfe

--

___
Python tracker 

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

[issue18851] subprocess's Popen closes stdout/stderr filedescriptors used in another thread when Popen errors

[Antoine Pitrou]

Antoine Pitrou added the comment:

Committed after applying Charles-François's suggested fixes. Thanks!

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

___
Python tracker 

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

[issue18853] Got ResourceWarning unclosed file when running Lib/shlex.py demo

[Madison May]

Madison May added the comment:

The patch LGTM as well.

ResourceWarning was silenced after applying patch when tested on my machine.

--
nosy: +madison.may

___
Python tracker 

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

[issue18853] Got ResourceWarning unclosed file when running Lib/shlex.py demo

[Terry J. Reedy]

Terry J. Reedy added the comment:

I think the warning should be silenced on all versions where it occurs. There 
is no real problem here, but there can be with multiple opens without close on 
non-refcounted interpreters. Patch looks good but I have not tried it.

--
nosy: +terry.reedy
stage:  -> patch review
versions: +Python 2.7, Python 3.3

___
Python tracker 

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

[issue18845] 2.7.5-r2: Fatal Python error: Segmentation fault

[Tim Peters]

Tim Peters added the comment:

As issue 18843 has evolved, seems more likely now that it's flaky HW, but 
agreed in any case there's really no evidence of a Python problem here.  So 
closing it.  Martin, we can revisit this if there's real progress on the other 
issue.

--
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue17224] can not open idle in python 2.7.3

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
resolution:  -> duplicate
status: open -> closed

___
Python tracker 

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

[issue8786] Add support for IEEE 754 contexts to decimal module.

[Stefan Krah]

Stefan Krah added the comment:

BTW, in _decimal the feature can already be enabled with:

./configure CFLAGS=-DEXTRA_FUNCTIONALITY


>>> IEEEContext(DECIMAL128)
Context(prec=34, rounding=ROUND_HALF_EVEN, Emin=-6143, Emax=6144, capitals=1, 
clamp=1, flags=[], traps=[])
>>> IEEEContext(DECIMAL64)
Context(prec=16, rounding=ROUND_HALF_EVEN, Emin=-383, Emax=384, capitals=1, 
clamp=1, flags=[], traps=[])
>>> IEEEContext(DECIMAL32)
Context(prec=7, rounding=ROUND_HALF_EVEN, Emin=-95, Emax=96, capitals=1, 
clamp=1, flags=[], traps=[])
>>>


>>> IEEEContext(512)
Context(prec=142, rounding=ROUND_HALF_EVEN, Emin=-103079215103, 
Emax=103079215104, capitals=1, clamp=1, flags=[], traps=[])
>>> IEEEContext(1024)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: argument must be a multiple of 32, with a maximum of 512
>>>

Of course this isn't the official API yet, but I think it's
reasonable.

--

___
Python tracker 

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

[issue18823] Idle: use pipes instead of sockets to talk with user subprocess

[Tshepang Lekhonkhobe]

Changes by Tshepang Lekhonkhobe :


--
nosy: +tshepang

___
Python tracker 

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

[issue18855] Inconsistent README filenames

[Tshepang Lekhonkhobe]

Changes by Tshepang Lekhonkhobe :


--
nosy: +tshepang

___
Python tracker 

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

[issue18877] tkinter askopenfilenames does not work in Windows library folder

[Terry J. Reedy]

Terry J. Reedy added the comment:

There was a issue about people not being able to open windows 'library' files 
from Idle, but it was determined not to be an Idle problem. I cannot find it 
now. The outcome may have been that this was presumed to be a tk bug, but your 
report about the alternate dialog is interesting. it.

--
nosy: +terry.reedy
stage:  -> needs patch

___
Python tracker 

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

[issue18756] os.urandom() fails under high load

[Roundup Robot]

Roundup Robot added the comment:

New changeset acc7439b1406 by Antoine Pitrou in branch 'default':
Issue #18756: os.urandom() now uses a lazily-opened persistent file descriptor, 
so as to avoid using many file descriptors when run in parallel from multiple 
threads.
http://hg.python.org/cpython/rev/acc7439b1406

--

___
Python tracker 

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

[issue18887] test_multiprocessing.test_connection failure

[Charles-François Natali]

New submission from Charles-François Natali:

http://buildbot.python.org/all/builders/x86%20Windows7%202.7/builds/2211/steps/test/logs/stdio

"""
test_ignore_listener (test.test_multiprocessing.TestIgnoreEINTR) ... test 
test_multiprocessing failed -- Traceback (most recent call last):
  File 
"D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\test\test_multiprocessing.py",
 line 1524, in test_connection
conn.send_bytes(really_big_msg)
ValueError: Cannnot send 16777216 bytes over connection
"""

--
components: Tests
messages: 196591
nosy: neologix, sbt
priority: normal
severity: normal
status: open
title: test_multiprocessing.test_connection failure
type: behavior

___
Python tracker 

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

[issue18756] os.urandom() fails under high load

[Antoine Pitrou]

Antoine Pitrou added the comment:

Ok, I've committed the patch for the lazy opening approach.

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

[issue18875] Automatic insertion of the closing parentheses, brackets, and braces

[Terry J. Reedy]

Terry J. Reedy added the comment:

I have thought about such a feature also. I would at least like to have patch 
to try it out. Possible? I suspect so.

--
nosy: +terry.reedy
versions: +Python 3.4 -Python 2.7

___
Python tracker 

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

[issue18831] importlib.import_module() bypasses builtins.__import__

[Terry J. Reedy]

Terry J. Reedy added the comment:

Perhaps I am confused because I did not notice the switch between 
builtins.__import__ and importlib.__import__ -- and I do not know the relation 
between the two, if indeed they are two and not one. What I read and understood 
is
* importlib.import_module doc say it calls ???.__import__;
* importlib.import_module code does not call ???.__import__;
it instead calls _gcd_import (for good reasons).

If the claim and reality disagree, because ??? is effectively the same in both 
statements, then either code or doc could be changed.

If importlib.__import__ and builtins.__import__ are different objects, and the 
doc is clear about that, then no one should expect that 'calls 
importlib.__import__' means 'calls builtins.__import__'.

--

___
Python tracker 

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

[issue18840] Tutorial recommends pickle module without any warning of insecurity

[Westley Martínez]

Westley Martínez added the comment:

How about we simply add the warning from 
http://docs.python.org/3/library/pickle.html#module-pickle to the beginning (or 
end) of the section?  The Official Python Tutorial has always assumed a certain 
programmer's competence.  It's up to them if they want to use the module or not.

--
nosy: +anikom15

___
Python tracker 

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

[issue16853] add a Selector to the select module

[Guido van Rossum]

Guido van Rossum added the comment:

On Fri, Aug 30, 2013 at 6:34 AM, Charles-François Natali
 wrote:
[Giampaolo Rodola']
> > - I'm not sure why in case of EINTR you retry with a different timeout; 
> > can't you just return []?
>
> Because when I do:
> selector.select(10)
>
> I expect the selector to wait 10 seconds if no event occurs: the fact
> that a signal comes in shouldn't break the contract made by the API,
> i.e. that it will return when a FD is ready or the timeout expires.

I disagree. In this case it is almost certain that there is already
some kind of retry loop around the Selector.select() call, so there is
no need for the retry. (Certainly this is how it happens in Tulip.) In
the case of select() the contract is actually quite clear, and there
shouldn't be any problem with returning an empty list early. (This is
quite different from e.g. an interrupted read() or recv() call, where
there is no existing return value that you can return safely, since
their users don't expect None and will usually treat an empty string
as an EOF indicator.)

> Early return can lead to spurious errors: just imagine you send a
> request to a busy server: it would be bad to raise a timeout error
> just because the user put the client in the background with CTRL-Z
> (which results in SIGSTOP).

Yeah, and Tulip's retry handles this just fine.

I also noticed that you are hardcoding a dependency on
time.monotonic() if it exists. If it weren't for your desire to "fix"
this issue you wouldn't have needed a time function at all!

> > - this is probably because I'm paranoid about performances but given that 
> > select() method will be called repeatedly I would not use a decorator. 
> > Also, similarly to what has been done elsewhere in the stdlib, for 
> > "critical" parts I would recommend localizing variable access in order to 
> > minimize overhead as in:
> >
> > def select(self, timeout=None):
> > ...
> > key_from_fd = self._key_from_fd
> > ready_append = ready.append
> > for fd in r | w:
> > ...
> > key = key_from_fd(fd)
> > if key:
> > ready_append((key, events & key.events))
>
> I find that localizing variables leads to unreadable code, and is tied
> to the current CPython interpreter implementation: such optimizations
> belong to the interpreter, not user code.
>
> As for the decorator performance overhead, I don't think it weights
> much compared to the cost of a syscall (+ GIL acquire/release):
> with decorator:
> $ ./python -m timeit -s "from selectors import DefaultSelector,
> EVENT_WRITE; import os; s = DefaultSelector();
> s.register(os.pipe()[1], EVENT_WRITE)" "s.select()"
> 10 loops, best of 3: 3.69 usec per loop
> without decorator:
> $ ./python -m timeit -s "from selectors import DefaultSelector,
> EVENT_WRITE; import os; s = DefaultSelector();
> s.register(os.pipe()[1], EVENT_WRITE)" "s.select()"
> 10 loops, best of 3: 3.52 usec per loop
>
> That's a 4% overhead, with a single FD that's always ready (and I
> suspect that most of the overhead is due to the call to time(), not
> the decorator per se).

But still I agree with Giampaolo that the decorator doesn't feel
right. It's like a try/except around the entire body of your function,
which is usually a code smell (even though I realize the exception it
catches can only be raised by the syscall). Please go back to the
explicit try/except returning [].

> Also, I'll shortly propose a patch to handle EINTR within C code, so
> those EINTR wrappers won't  be needed anymore.

Hm, it may be a while before everyone is comfortable with that change.
Who knows what might break?

--

___
Python tracker 

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

[issue18825] Making msg optional on logging.exception() and similar variants

[Vinay Sajip]

Vinay Sajip added the comment:

No, because in the general case, it would be useful to provide a message. If 
you don't want to, you can specify '', but there's no reason to make that the 
default.

--
nosy: +vinay.sajip
resolution:  -> invalid
status: open -> pending

___
Python tracker 

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

[issue18840] Tutorial recommends pickle module without any warning of insecurity

[Terry J. Reedy]

Terry J. Reedy added the comment:

> How about we simply add the warning from 
> http://docs.python.org/3/library/pickle.html#module-pickle to the beginning 
> (or end) of the section?

That is one possibility.

> The Official Python Tutorial has always assumed a certain programmer's 
> competence.

Such a person is much more likely to know about and find use for 
language independent json than Python-specific pickle. The tutorial was 
written before json existed, but if it were written today, json would 
seem to me to be the better choice for first exposure to serialization. 
If someone cares enough to write a patch, I think it should be considered.

--

___
Python tracker 

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

[issue14937] IDLE's deficiency in the completion of file names (Python 32, Windows XP)

[Westley Martínez]

Westley Martínez added the comment:

On 3.4.0a1 on Windows it seems to come up automatically with \ or \\.  A single 
\ will only pop up with the tab key; I think it's good that way.  Special 
characters (i.e. æ) work normally.  All this said, I think this issue is fixed.

--

___
Python tracker 

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

[issue18840] Tutorial recommends pickle module without any warning of insecurity

[Westley Martínez]

Westley Martínez added the comment:

I won't question the usefulness of JSON.  I'm not a web programmer and have 
never used it.  From my interpretation of the tutorial, it seems that the 
section's purpose is for storing python objects.  If pickle is going to stay in 
the tutorial, I think a warning is imperative.  Either way, I think a section 
on JSON would be a welcome addition to the tutorial.

+1 adding a warning
+0 keeping pickle in the tutorial

--

___
Python tracker 

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

[issue18840] Tutorial recommends pickle module without any warning of insecurity

[Westley Martínez]

Westley Martínez added the comment:

Here's a patch that adds the warning, if we so choose to keep pickle in the 
tutorial.  It's taken verbatim from the pickle module's documentation.

--
keywords: +patch
Added file: http://bugs.python.org/file31524/pickle-add-warning_18840.diff

___
Python tracker 

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

[issue18840] Tutorial recommends pickle module without any warning of insecurity

[Antoine Pitrou]

Antoine Pitrou added the comment:

The very fact that we would add a warning makes pickle unfit for the tutorial, 
IMHO. The tutorial should stick to simple enough stuff that doesn't need any 
warnings.

--

___
Python tracker 

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

[issue18888] Add stdlib support for random sampling with replacement

[Madison May]

New submission from Madison May:

Although the random module supports random sampling without replacement, there 
is no support for random sampling with replacement.  Efficient random sampling 
with replacement is trivial using random.choice() (see below), but supporting 
it as an optional 'replace' arg to random.sample() might be nice for symmetry. 

array = range(100)
random_sample = [random.choice(array) for i in range(10)]

--
components: Library (Lib)
messages: 196603
nosy: madison.may
priority: normal
severity: normal
status: open
title: Add stdlib support for random sampling with replacement
type: enhancement
versions: Python 3.4, Python 3.5

___
Python tracker 

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

[issue18858] dummy_threading lacks threading.get_ident() equivalent

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue12037] test_email failures under Windows with the eol extension activated

[Terry J. Reedy]

Terry J. Reedy added the comment:

Two years later, I get the exact same failure in both repository 3.3.2+ and 
installed 3.3.2. So eol extension and .hgignore seem irrelevant.

I sometime think Python should stop generating files with \r\n. In other words, 
change os.linesep to '\n' even on windows. Or maybe just do it for test files 
that will be read in binary mode and compared with generated data. The only 
program I know of that does not recognize \n alone is Notepad, and that hardly 
worth bothering with.

Repository 3.4.0a1+ has the same error + essentially the same in
test_as_bytes. (Repository 2.7.5+ passes.) For one test, \r only appears in the 
file; in the other, it also sporadically appeared in the generated bytes. I 
don't know why the test works on buildbots, but the attached patch fixes it for 
my desktop. Any objections to committing it?

--
keywords: +patch
nosy: +terry.reedy
stage:  -> commit review
versions: +Python 3.4
Added file: http://bugs.python.org/file31525/12037_test_email.diff

___
Python tracker 

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