[issue5639] Support TLS SNI extension in ssl module

[Dima Tisnek]

Dima Tisnek added the comment:

Hopefully pep-466 resolves this for 2.x series.

--

___
Python tracker 

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

[issue18304] ElementTree -- provide a way to ignore namespace in tags and seaches

[pocek]

Changes by pocek :


--
nosy: +pocek

___
Python tracker 

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

[issue21197] venv does not create lib64 directory and appropriate symlinks

[Matthias Dahl]

Matthias Dahl added the comment:

Take for example the case that you have to juggle with several venvs and mix 
them together. This has happened to me in the past in very legitimate cases. 
You have to add those venvs to the path yourself. I am not talking about having 
a shell where you do your work but some other automated tasks.

Or jedi (http://jedi.jedidjah.ch/) which has become a popular autocompletion 
third party tool that supports venvs. You pass it the base directories and it 
adds their site-packages to the appropriate places. Naturally it has to know if 
those are under lib or lib64.

Just to name two examples. I guess there are more tools out there which have to 
juggle with venvs and would stumble upon this inconsistency in comparison with 
virtualenv. Both are naturally fixable on the user side here but since 
virtualenv provided those symlinks since quite a while and since IMHO venv 
should stay as compatible with it as possible, it would be nice if venv 
provided those too.

Besides all of that, creating a "lib"-dir during the venv creation while for 
all later installations via pip "lib64" is used (which wasn't created 
initially), sounds like a bug all in itself. ;-)

If you want, I could have a look and come up with a patch, if you would be 
willing to consider this "feature" (adding a lib64 to lib symlink).

--

___
Python tracker 

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

[issue21191] os.fdopen() may eat file descriptor and still raise exception

[Dima Tisnek]

Dima Tisnek added the comment:

I think consistency between Python versions is just as important as consistency 
between fd types.

Here's my hack quickfix outline:

fd = os.open(...)
try:
if not stat.S_ISREG(os.fstat(fd).st_mode):
raise OSError(None, "Not a regular file", ...)
f = os.fdopen(fd, ...)
except EnvironmentError:
os.close(fd)

Can something like this be implemented in os.py
There's already a check `if not isinstance(fd, int): raise ...`

Granted we'd have to get fd type check exactly right.
fdopen should probably succeed for regular files, pipes, char devices, block 
device, ptry's ...
fdopen should fail where underlying implementation fails, i.e. directories, 
sockets(?), epoll(?), timerfd(?)

There's a list at http://en.wikipedia.org/wiki/File_descriptor
I'm not sure about some types.

P.S. I wish there was a way to rescue fd from FILE*, but nothing like that 
seems to exist...

P.P.S. another option is to always use dup(), but that may break existing 
programs is they expect fd == fdopen(fd).fileno()

--

___
Python tracker 

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

[issue21197] venv does not create lib64 directory and appropriate symlinks

[Vinay Sajip]

Vinay Sajip added the comment:

What does pip do under Windows? The symlink feature doesn't work on all Windows 
versions and is not quite the same as on POSIX.

What is it that actually requires lib64? As venvs are specific to a single 
interpreter, it seems like it is inherently not a good idea to add site-package 
links to venvs in other venvs willy-nilly, though of course it would work in 
homogeneous scenarios.

Do we know *why* virtualenv added a lib64 symlink? What (apart from possibly 
pip) fails if it doesn't do this? Does distutils require it?

--

___
Python tracker 

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

[issue21194] json.dumps with ensure_ascii=False doesn't escape control characters

[Weeble]

Weeble added the comment:

Ah, sorry for the confusion.

--

___
Python tracker 

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

[issue21197] venv does not create lib64 directory and appropriate symlinks

[Matthias Dahl]

Matthias Dahl added the comment:

The problem is: Some Linux dists install Python under /usr/lib64 on a multilib 
systems and patch Python accordingly, e.g. Gentoo or Fedora. Thus, Python looks 
for lib64/pythonX.Y/... which is also why pip installs to lib64/... by default 
on those systems.

This has no effect on Windows systems btw.

virtualenv introduced the symlink sometime 2007, if I researched that correctly 
(https://github.com/pypa/virtualenv/commit/244b23b5e89b58a4c2777a0f0975bbab7fda4dd2)
 and kept and tuned it ever since.

Again, it is debatable where this should be fixed but since it is such an easy 
fix to venv while potentially keeping compatibility with tools relying on 
finding everything under lib/... as well as virtualenv itself, I'd think it 
would be nice to have it here.

@vinay.sajip: I never said anything about adding links to the site-packages 
itself-- even though those can be useful and safe in a very limited number of 
cases. It is just about the fact that on systems where Python is installed 
under lib64, pip also installs to lib64 while the venv only creates a lib/ dir, 
no lib64/ symlink to it and some tools (rightfully so) rely on finding 
everything under lib/ itself... which is empty in that case. For the global 
python that is irrelevant because there is always a lib to lib64 symlink on 
multilib systems.

--

___
Python tracker 

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

[issue21177] ValueError: byte must be in range(0, 256)

[STINNER Victor]

STINNER Victor added the comment:

I suggested "must be in the range [0; 255]" which is not a valid Python
list: ";" is the instruction operator and there is "range" word in front of
the "list". In my opinion, it's much easier to read and understand it.

Another example is the Unicode range(0x11). "range [0; 0x10]" would
be better. Or maybe "must be in the range U+-U+10" but it requires
to know the Unicode U+ syntax and the input type may be int, not a
character.

--

___
Python tracker 

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

[issue21200] pkgutil.get_loader() fails on "__main__"

[Eric Snow]

New submission from Eric Snow:

Prior to 3.4, pkgutil.get_loader('__main__') would return None.  Now it results 
in an ImportError.  That's because it calls importlib.util.find_spec() which 
fails if an existing module does not have __spec__ or it is None.

--
components: Library (Lib)
keywords: 3.4regression
messages: 215926
nosy: brett.cannon, eric.snow, larry, ncoghlan
priority: release blocker
severity: normal
stage: test needed
status: open
title: pkgutil.get_loader() fails on "__main__"
type: behavior
versions: Python 3.4, Python 3.5

___
Python tracker 

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

[issue21177] ValueError: byte must be in range(0, 256)

[akira]

akira added the comment:

"byte must be in range [0, 256)"

- it hints at the builtin `range()` -- the intuition works for those who knows 
what `range()` does
- it uses the standard math notation for half-open intervals [1] -- no Python 
knowledge required (among other things)
- it is not a valid Python -- no confusion with a list, tuple literals
- Dijkstra explains why half-open intervals are preferable [2]

Another alternative is to use `range(0x100)` and require that to understand the 
error message, you should know Python and the hex notation.

[1]: http://en.wikipedia.org/wiki/Interval_(mathematics)#Notations_for_intervals
[2]: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html

--
nosy: +akira

___
Python tracker 

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

[issue21197] venv does not create lib64 directory and appropriate symlinks

[Vinay Sajip]

Vinay Sajip added the comment:

Thanks for the info.

I'm not opposed to adding a symlink on POSIX systems - I just wanted to make 
sure that was the right solution.

My comment about adding links willy-nilly was about tools like Jedi that you 
mentioned (perhaps I misunderstood how it works).

Clearly, if the idea is to support Pythons patched by distros, then it seems 
that there is little alternative available apart from the symlink.

As you say, lib64 should be the symlink name, pointing to the lib directory.  
Should the symlink be created on 64-bit Linux venvs on all POSIX platforms, and 
should OS X be excluded?

--

___
Python tracker 

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

[issue21177] ValueError: byte must be in range(0, 256)

[Mark Lawrence]

Mark Lawrence added the comment:

How about plain English?  "byte must be between 0 and 255 inclusive"

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue21197] venv does not create lib64 directory and appropriate symlinks

[Ned Deily]

Ned Deily added the comment:

"should OS X be excluded?"

Yes. OS X uses universal binaries, with multiple CPU archs automatically 
combined at build time into one file, so there generally is no need for 
arch-specific directories.

But if the problem is being caused by Pythons patched by third-party 
distributors, shouldn't the onus be on them to properly patch venv, too, rather 
than having upstream CPython trying to guess what distributors are doing?

--
nosy: +ned.deily

___
Python tracker 

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

[issue21194] json.dumps with ensure_ascii=False doesn't escape control characters

[Ned Deily]

Changes by Ned Deily :


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

___
Python tracker 

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

[issue21158] Windows installer service could not be accessed (Python bug!)

[Terry J. Reedy]

Terry J. Reedy added the comment:

If you were upgrading an existing install, try cleanly removing it from Control 
Panel / Programs and Features (Win 7). To do that, you may have to first fix 
the existing installation and that will require the installer used to install 
it.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue21177] ValueError: byte must be in range(0, 256)

[Antoine Pitrou]

Antoine Pitrou added the comment:

> I suggested "must be in the range [0; 255]" which is not a valid Python
> list: ";" is the instruction operator and there is "range" word in front of
> the "list". In my opinion, it's much easier to read and understand it.

I'm -1 on it. It may not be a valid Python list, but it definitely *looks* like 
a valid Python list, which makes it a double "wtf" IMO.

--

___
Python tracker 

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

[issue21177] ValueError: byte must be in range(0, 256)

[Antoine Pitrou]

Antoine Pitrou added the comment:

Ok, seeing how the alternative proposals are all worse than the statu quo, and 
how this is going a massive bikeshedding anyway, I'd rather close the issue.

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

___
Python tracker 

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

[issue21201] Uninformative error message in multiprocessing.Manager()

[Wojciech Walczak]

New submission from Wojciech Walczak:

While using multiprocessing.Manager() to send data between processes I've 
noticed that one of the traceback messages is not very informative:

Traceback (most recent call last):
  File "age_predict.py", line 39, in 
train_data, train_target, test_data = prepare_data()
  File "age_predict.py", line 30, in prepare_data
train_data = q.get(True, 1)
  File "", line 2, in get
  File "/usr/lib/python2.7/multiprocessing/managers.py", line 777, in 
_callmethod
raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError: 
-
Unserializable message: ('#RETURN', [A WHOLE LOT OF DATA GOES HERE]
 

The real problem here is that my machine is running out of memory, but the 
traceback message shadows this information and reports "Unserializable message" 
instead.

After a simple path (see: attached file) the traceback message is as follows:


Traceback (most recent call last):
  File "age_predict.py", line 39, in 
train_data, train_target, test_data = prepare_data()
  File "age_predict.py", line 30, in prepare_data
train_data = q.get(True, 1)
  File "", line 2, in get
  File "/usr/lib/python2.7/multiprocessing/managers.py", line 775, in 
_callmethod
raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError: 
-
Unserializable message: Traceback (most recent call last):
  File "/usr/lib/python2.7/multiprocessing/managers.py", line 288, in 
serve_client
send(msg)
MemoryError: out of memory


Here's another example (see: http://bugs.python.org/issue6766):

This python3 code:

from multiprocessing import Manager
manager = Manager()
ns_proxy = manager.Namespace()
evt_proxy = manager.Event()
ns_proxy.my_event_proxy = evt_proxy
print(ns_proxy.my_event_proxy)


Produces following traceback message:


Traceback (most recent call last):
  File "test.py", line 6, in 
print(ns_proxy.my_event_proxy)
  File "/cpython/Lib/multiprocessing/managers.py", line 1032, in __getattr__
return callmethod('__getattribute__', (key,))
  File "/cpython/Lib/multiprocessing/managers.py", line 748, in _callmethod
raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError: 
--
Unserializable message: ('#RETURN', )
--


...and after applying the attached patch it becomes clearer what's going on:


Traceback (most recent call last):
  File "test.py", line 6, in 
print(ns_proxy.my_event_proxy)
  File "/cpython/Lib/multiprocessing/managers.py", line 1032, in __getattr__
return callmethod('__getattribute__', (key,))
  File "/cpython/Lib/multiprocessing/managers.py", line 748, in _callmethod
raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError: 
--
Unserializable message: Traceback (most recent call last):
  File "/cpython/Lib/multiprocessing/managers.py", line 276, in serve_client
send(msg)
  File "/cpython/Lib/multiprocessing/connection.py", line 206, in send
self._send_bytes(ForkingPickler.dumps(obj))
  File "/cpython/Lib/multiprocessing/reduction.py", line 50, in dumps
cls(buf, protocol).dump(obj)
_pickle.PicklingError: Can't pickle : attribute lookup 
lock on _thread failed

This patch doesn't break any tests.

--
components: Library (Lib)
files: managers_tb_msg.patch
keywords: patch
messages: 215934
nosy: wojtekwalczak
priority: normal
severity: normal
status: open
title: Uninformative error message in multiprocessing.Manager()
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34785/managers_tb_msg.patch

___
Python tracker 

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

[issue19628] maxlevels -1 on compileall for unlimited recursion

[Claudiu.Popa]

Claudiu.Popa added the comment:

Added patch which addresses the comments of Berker Peksag. Thanks for the 
review!

--
Added file: http://bugs.python.org/file34786/issue19628_1.patch

___
Python tracker 

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

[issue21127] Path objects cannot be constructed from str subclasses

[Antony Lee]

Antony Lee added the comment:

I am loading some structure from a MATLAB binary file using scipy.io.loadmat.  
This structure contains (in particular) paths (written as bytestrings) to other 
files which end up being loaded as numpy.str_ objects.

In fact, just trying to store and retrieve strings from numpy arrays wraps them 
in numpy.str_:

>>> import numpy
>>> type(numpy.array(["foo"])[0])


... and now trying to construct a Path from that will crash.

I agree, though, that force-casting str subclasses in the constructor may avoid 
other issues.

--

___
Python tracker 

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

[issue21164] print unicode in Windows console

[Terry J. Reedy]

Terry J. Reedy added the comment:

You can change the code page of a Command Prompt window, before calling Python, 
with ...> chcp . There is 'something' called cp65001 that is 
supposed to be a utf-8 codepage. Once can change to it, but it does not work 
right. This has been discussed on StackOverflow and elsewhere.

The Idle Shell, running on tkinter, handles everything in the BMP because 
tcl/tk is unicode (ucs-2) based. The characters that display properly depend on 
the font you select. On my machine, all but three of the following arbitrary 
codepoints display proper characters.
>>> print('\u\u\u\u\u\u\u\u\u\u\u\u\u\u')
ᄑ∢㌳䑄啕晦睷袈香ꪪ뮻쳌�

--
nosy: +terry.reedy
resolution:  -> duplicate
status: open -> closed
superseder:  -> windows console doesn't print or input Unicode

___
Python tracker 

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

[issue21177] ValueError: byte must be in range(0, 256)

[Stefan Krah]

Stefan Krah added the comment:

Antoine Pitrou  wrote:
> > I suggested "must be in the range [0; 255]" which is not a valid Python
> > list: ";" is the instruction operator and there is "range" word in front of
> > the "list". In my opinion, it's much easier to read and understand it.
> 
> I'm -1 on it. It may not be a valid Python list, but it definitely *looks* 
> like a valid Python list, which makes it a double "wtf" IMO.

It's a valid OCaml list;; :P

[Glad that the issue is closed]

--

___
Python tracker 

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

[issue21170] Incorrect signature for unittest.TestResult.startTestRun(), .stopTestRun()

[Terry J. Reedy]

Terry J. Reedy added the comment:

Good catch. I verified in code that patch is correct.

--
assignee: docs@python -> terry.reedy
nosy: +terry.reedy

___
Python tracker 

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

[issue21202] Naming a file` io.py` causes cryptic error message

[Madison May]

Changes by Madison May :


--
versions: +Python 3.5

___
Python tracker 

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

[issue21202] Naming a file` io.py` causes cryptic error message

[Madison May]

New submission from Madison May:

Naming a file `io.py` in the root directory of a project causes the following 
error on 2.7: 

AttributeError: 'module' object has no attribute 'BufferedIOBase'

Similar issues arise on 3.x., although the error message is a bit more useful:

Fatal Python error: Py_Initialize: can't initialize sys standard streams
AttributeError: 'module' object has no attribute 'OpenWrapper'

At the very least we should ensure that the error message is a bit more 
straightforward and clear, as I imagine its not all that uncommon to cause this 
kind of conflict.

--
assignee: docs@python
components: Documentation, IO
messages: 215940
nosy: docs@python, madison.may
priority: normal
severity: normal
status: open
title: Naming a file` io.py` causes cryptic error message
versions: Python 2.7

___
Python tracker 

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

[issue21170] Incorrect signature for unittest.TestResult.startTestRun(), .stopTestRun()

[Roundup Robot]

Roundup Robot added the comment:

New changeset c1ea2846a564 by Terry Jan Reedy in branch '2.7':
Issue #21170: Removed invalid parameter names from unittest doc.
http://hg.python.org/cpython/rev/c1ea2846a564

New changeset 5734175a87d1 by Terry Jan Reedy in branch '3.4':
Issue #21170: Removed invalid parameter names from unittest doc.
http://hg.python.org/cpython/rev/5734175a87d1

--
nosy: +python-dev

___
Python tracker 

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

[issue21170] Incorrect signature for unittest.TestResult.startTestRun(), .stopTestRun()

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type:  -> behavior

___
Python tracker 

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

[issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided

[Roundup Robot]

Roundup Robot added the comment:

New changeset dc6c2ab7fec2 by Mark Dickinson in branch 'default':
Issue #21193: Make (e.g.,) pow(2, -3, 5) raise ValueError rather than 
TypeError.  Patch by Josh Rosenberg.
http://hg.python.org/cpython/rev/dc6c2ab7fec2

--
nosy: +python-dev

___
Python tracker 

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

[issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided

[Mark Dickinson]

Mark Dickinson added the comment:

Patch applied. Thanks, all.

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

___
Python tracker 

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

[issue21171] Outdated usage str.encode('rot-13') in rot13 codec

[Terry J. Reedy]

Terry J. Reedy added the comment:

Since rot_13 is a transcoder, not an encoder, the error message is correct, as 
is the fix for the function. However, since neither the module encodings.rot_13 
nor the rot13 function in the module are documented, (not even in 2.7), I 
wonder if the function and the if __name__; clause are ancient holdovers that 
should be removed. In other words, I am not sure if Berker's test is currently 
a supported usage. I remember that there was some discussion on pydev about how 
much to add back but not the details.

--
nosy: +benjamin.peterson, ezio.melotti, haypo, pitrou, terry.reedy

___
Python tracker 

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

[issue21164] print unicode in Windows console

[Leslie Klein]

Leslie Klein added the comment:

I start ipython in Windows PowerShell. The "console" I am referring to is
ipython running in WindowsPowerShell.
I do not use the DOS cmd.exe

When running ipython notebook from WindowsPowerShell -- no problem printing
unicode.

When running in PTVS (Python Tools for Visual Studio) debugger -- no
problem printing unicode in Output window, or Interactive Python window.
Problem does appear in Console window (which is the DOS window I believe).

On Mon, Apr 7, 2014 at 7:08 AM, STINNER Victor wrote:

>
> STINNER Victor added the comment:
>
> Hi, when you say "The console" is the the old MS-DOS command ("Windows
> console") opened when you run the "cmd.exe" program? Or IDLE or another
> console?
>
> For the Windows console, see the old issue #1602 which is not fixed yet.
>
> On Windows, sys.stdout.encoding is your OEM code page, which is usually
> different than the ANSI code page (locale.getpreferredencoding()).
>
> --
> nosy: +haypo
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue21202] Naming a file` io.py` causes cryptic error message

[Ned Deily]

Ned Deily added the comment:

Using a local module name that shadows one in the standard library is a very 
common "import trap".  See, for example, 
https://ncoghlan_devs-python-notes.readthedocs.org/en/latest/python_concepts/import_traps.html#the-name-shadowing-trap.
  I did a quick search through the documentation and didn't find an explicit 
reference to the general topic.  If it isn't already, it probably should be 
mentioned in the tutorial and the FAQ.  I don't think that 'io' should be 
special-cased.

--
components:  -IO
nosy: +ned.deily

___
Python tracker 

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

[issue21202] Naming a file` io.py` causes cryptic error message

[Brett Cannon]

Brett Cannon added the comment:

While mentioning something in the FAQ and/or tutorial is fine, I wouldn't want 
to change Python's message too much to deal with this unless it was extremely 
fast (e.g. we pre-generated a set and check that on ImportError and then 
modified the message only in those instances).

--
nosy: +brett.cannon

___
Python tracker 

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

[issue21202] Naming a file` io.py` causes cryptic error message

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti, ncoghlan
type:  -> behavior

___
Python tracker 

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

[issue21178] doctest cause warnings in tests using generators

[Terry J. Reedy]

Terry J. Reedy added the comment:

I not am not sure I see a bug here, a discrepancy between doc and behavior. 
Even if not, you may have a legitimate enhancement request.

3.4 now warns about ignored exceptions during shutdown in case there is a 
fixable bug in the code being shut down. This is intended to be a feature, not 
a problem. I don't know if the warnings can be suppressed.

3.4 also implemented PEP 442 so "objects with __del__() methods, as well as 
generators with finally clauses, can be finalized when they are part of a 
reference cycle." Your second patch puts a generator in a reference cycle. 
Generators have a .__del__ method. Perhaps its body is the equivalent of 
"self.throw(GeneratorExit)". If so, that could be wrapped with the equivalent 
of "try:...except BaseException: pass" to avoid leaking exceptions.

--
nosy: +ncoghlan, terry.reedy
stage:  -> needs patch
versions: +Python 3.5

___
Python tracker 

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

[issue21201] Uninformative error message in multiprocessing.Manager()

[Ned Deily]

Changes by Ned Deily :


--
nosy: +sbt
versions:  -Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

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

[issue21180] Cannot efficiently create empty array.array of given size, inconsistency with bytearray

[Terry J. Reedy]

Terry J. Reedy added the comment:

You are  proposing to copy behavior that will likely be deprecated and removed 
(see  http://legacy.python.org/dev/peps/pep-0467/#id5). Lets reject that idea. 
The same pep proposes to replace byte(s/array)(n) "by two more explicit 
alternate constructors provided as class methods" -- perhaps called .zeros(n). 
A proposal to copy the new replacements to array might be accepted.

--
nosy: +ncoghlan, terry.reedy

___
Python tracker 

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

[issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided

[Roundup Robot]

Roundup Robot added the comment:

New changeset a8f3ca72f703 by Benjamin Peterson in branch 'default':
test the change of #21193 correctly
http://hg.python.org/cpython/rev/a8f3ca72f703

--

___
Python tracker 

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

[issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided

[Mark Dickinson]

Mark Dickinson added the comment:

Benjamin: thanks for the fix.  To be clear: Josh Rosenberg's patch had the 
correct test change.  It was the (poorly) trained monkey who made the commit 
who broke the test.

Sorry, all.

--

___
Python tracker 

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

[issue21202] Naming a file` io.py` causes cryptic error message

[Madison May]

Madison May added the comment:

I definitely agree that io shouldn't be special cased, as it's more about the 
name shadowing issue that this specific example.

A simple docs addition would make me happy, to be honest.

--

___
Python tracker 

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

[issue14758] SMTPServer of smptd does not support binding to an IPv6 address

[R. David Murray]

R. David Murray added the comment:

I added some review comments.  Since this is a new feature, the patch also 
needs a 'versionchanged' that indicates that ipv6 support was added.

--
stage: needs patch -> patch review
versions: +Python 3.5 -Python 3.3

___
Python tracker 

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

[issue21203] logging configurators ignoring documented options

[Jure Koren]

New submission from Jure Koren:

2.7's logging.config.DictConfig does not respect the "class" option, but 
fileConfig does.

The default branch logging.config has the same problem in DictConfig, but also 
lacks "style" support in fileConfig.

--
components: Library (Lib)
files: logging_config_2_7.diff
hgrepos: 233
keywords: patch
messages: 215954
nosy: Jure.Koren
priority: normal
severity: normal
status: open
title: logging configurators ignoring documented options
type: behavior
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file34787/logging_config_2_7.diff

___
Python tracker 

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

[issue21203] logging configurators ignoring documented options

[Jure Koren]

Jure Koren added the comment:

2.7's logging.config.DictConfig does not respect the "class" option, but 
fileConfig does.

The default branch logging.config has the same problem in DictConfig, but also 
lacks "style" support in fileConfig.

--
hgrepos: +234
Added file: http://bugs.python.org/file34788/logging_config_default.diff

___
Python tracker 

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

[issue1191964] asynchronous Subprocess

[Josiah Carlson]

Josiah Carlson added the comment:

I added the chunking for Windows because in manual testing before finishing the 
patch, I found that large sends on Windows without actually waiting for the 
result can periodically result in zero data sent, despite a child process that 
wants to read.

Looking a bit more, this zero result is caused by ov.cancel() followed by 
ov.getresult() raising an OSError, specifically:
[WinError 995] The I/O operation has been aborted because of either a thread 
exit or an application request

That causes us to observe on the Python side of things that zero data was sent 
for some writes, but when looking at what the child process actually received, 
we discover that some data was actually sent. How much compared to what we 
thought we sent? That depends. I observed in testing today that the client 
could receive ~3.5 megs when we thought we had sent ~3 megs.

To make a long story short-ish, using Overlapped IO with WriteFile() and 
Overlapped.cancel(), without pausing between attempts with either a sleep or 
something else results in a difference in what we think vs. reality roughly 87% 
of the time with 512 byte chunks (87 trials out of 100), and roughly 100% of 
the time with 4096 byte chunks (100 trials out of 100). Note that this is when 
constantly trying to write data to the pipe. (each trial is as many 
Popen.write_nonblocking() calls as can complete in .25 seconds)

Inducing a 1 ms sleep between each overlapped.WriteFile() attempt drops the 
error rate to 0/100 trials and 1/100 trials for 512 byte and 4096 byte writes, 
respectively. Testing for larger block sizes suggests that 2048 bytes is the 
largest send that we can push through and actually get correct results.


So, according to my tests, there isn't a method by which we can both cancel an 
overlapped IO while at the same time guaranteeing that we will account exactly 
for the data that was actually sent without adding an implicit or explicit 
delay. Which makes sense as we are basically trying to interrupt another 
process in their attempts to read data that we said they could read, but doing 
so via a kernel call that interrupts another kernel call that is doing 
chunk-by-chunk copies from our write buffer (maybe to some kernel memory then) 
to their read buffer.

Anyway, by cutting down what we attempt to send at any one time, and forcing 
delays between attempted sends, we can come pretty close to guaranteeing that 
child processes don't have any sends that we can't account for. I'll try to get 
a patch out this weekend that encompasses these ideas with a new test that 
demonstrates the issue on Windows (for those who want to verify my results).

--

___
Python tracker 

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

[issue21204] published examples don't work

[jmaki]

New submission from jmaki:

Would you consider putting examples given in official documentation as part of 
release testing?  e.g. (from official python.org documentation):
- snip -

An example of how a pool of worker processes can each run a 
SimpleHTTPServer.HttpServer instance while sharing a single listening socket.

#
# Example where a pool of http servers share a single listening socket
#
# On Windows this module depends on the ability to pickle a socket
# object so that the worker processes can inherit a copy of the server
# object.  (We import `multiprocessing.reduction` to enable this pickling.)
#
# Not sure if we should synchronize access to `socket.accept()` method by
# using a process-shared lock -- does not seem to be necessary.
#
# Copyright (c) 2006-2008, R Oudkerk
# All rights reserved.
#

import os
import sys

from multiprocessing import Process, current_process, freeze_support
from BaseHTTPServer import HTTPServer
from SimpleHTTPServer import SimpleHTTPRequestHandler

if sys.platform == 'win32':
import multiprocessing.reduction# make sockets pickable/inheritable


def note(format, *args):
sys.stderr.write('[%s]\t%s\n' % (current_process().name, format%args))


class RequestHandler(SimpleHTTPRequestHandler):
# we override log_message() to show which process is handling the request
def log_message(self, format, *args):
note(format, *args)

def serve_forever(server):
note('starting server')
try:
server.serve_forever()
except KeyboardInterrupt:
pass


def runpool(address, number_of_processes):
# create a single server object -- children will each inherit a copy
server = HTTPServer(address, RequestHandler)

# create child processes to act as workers
for i in range(number_of_processes-1):
Process(target=serve_forever, args=(server,)).start()

# main process also acts as a worker
serve_forever(server)


def test():
DIR = os.path.join(os.path.dirname(__file__), '..')
ADDRESS = ('localhost', 8000)
NUMBER_OF_PROCESSES = 4

print 'Serving at http://%s:%d using %d worker processes' % \
  (ADDRESS[0], ADDRESS[1], NUMBER_OF_PROCESSES)
print 'To exit press Ctrl-' + ['C', 'Break'][sys.platform=='win32']

os.chdir(DIR)
runpool(ADDRESS, NUMBER_OF_PROCESSES)


if __name__ == '__main__':
freeze_support()
test()
- snip -
does not work on windows...

Regards,
John

--
components: Cross-Build
messages: 215957
nosy: jmaki
priority: normal
severity: normal
status: open
title: published examples don't work
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue7951] Should str.format allow negative indexes when used for __getitem__ access?

[Terry J. Reedy]

Terry J. Reedy added the comment:

Either leading sign, '+' or '-', cause string interpretation, so I think 
'unsigned integer' should be the term in the doc.

>>> '{0[-1]}'.format({'-1': 'neg int key'})
'neg int key'
>>> '{0[+1]}'.format({'+1': 'neg int key'})
'neg int key'
>>> '{0[+1]}'.format([1,2,3])
Traceback (most recent call last):
  File "", line 1, in 
'{0[+1]}'.format([1,2,3])
TypeError: list indices must be integers, not str

--

___
Python tracker 

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

[issue21171] Outdated usage str.encode('rot-13') in rot13 codec

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +ncoghlan

___
Python tracker 

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

[issue15955] gzip, bz2, lzma: add option to limit output size

[Nikolaus Rath]

Nikolaus Rath added the comment:

I've attached the second iteration of the patch. I've factored out a new 
function decompress_buf, and added two new (C only) instance variables 
input_buffer and input_buffer_size.

I've tested the patch by enabling Py_USING_MEMORY_DEBUGGER in 
Objects/obmalloc.c and compiling --with-pydebug --without-pymalloc. Output is:

$ valgrind --tool=memcheck --suppressions=Misc/valgrind-python.supp ./python -m 
test -R : -v test_lzma
==18635== Memcheck, a memory error detector
==18635== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==18635== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==18635== Command: ./python -m test -R : -v test_lzma
==18635== 
== CPython 3.5.0a0 (default:a8f3ca72f703+, Apr 11 2014, 21:48:07) [GCC 4.8.2]
[]
Ran 103 tests in 43.655s

OK
beginning 9 repetitions
123456789
[...]
OK
.
1 test OK.
==18635== 
==18635== HEAP SUMMARY:
==18635== in use at exit: 2,328,705 bytes in 13,625 blocks
==18635==   total heap usage: 2,489,623 allocs, 2,475,998 frees, 91,305,463,593 
bytes allocated
==18635== 
==18635== LEAK SUMMARY:
==18635==definitely lost: 0 bytes in 0 blocks
==18635==indirectly lost: 0 bytes in 0 blocks
==18635==  possibly lost: 963,533 bytes in 1,334 blocks
==18635==still reachable: 1,365,172 bytes in 12,291 blocks
==18635== suppressed: 0 bytes in 0 blocks
==18635== Rerun with --leak-check=full to see details of leaked memory
==18635== 
==18635== For counts of detected and suppressed errors, rerun with: -v
==18635== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)


When running the tests only once (no -R option), the number of possibly lost 
bytes is 544,068 in 1,131 blocks. When running without the patch, the number is 
545,740 bytes in 1,134 blocks (for one iteration). I guess this means that 
Python is using interior pointers, so these blocks are not truly lost?

--
Added file: http://bugs.python.org/file34789/issue15955_r2.diff

___
Python tracker 

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

[issue21203] logging configurators ignoring documented options

[Ned Deily]

Changes by Ned Deily :


--
nosy: +vinay.sajip

___
Python tracker 

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

[issue21196] Name mangling example in Python tutorial

[Éric Araujo]

Éric Araujo added the comment:

Thanks for the report and proposed fix!  Could you upload a patch file that we 
could directly apply to the documentation instead of Python files?  More 
information about how to do that is found here: 
https://docs.python.org/devguide/#quick-start

If you need any kind of help, the devguide has the address of the 
core-mentorship mailing list where many friendly people can answer questions.  
You can also ask in this issue page.

--
nosy: +eric.araujo
stage:  -> patch review
versions: +Python 2.7, Python 3.4, Python 3.5

___
Python tracker 

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

[issue21197] venv does not create lib64 directory and appropriate symlinks

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo

___
Python tracker 

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

[issue21171] Outdated usage str.encode('rot-13') in rot13 codec

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo

___
Python tracker 

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

[issue21186] RawConfigParser __name__ option handling inconsistent

[Éric Araujo]

Changes by Éric Araujo :


--
assignee:  -> lukasz.langa
nosy: +lukasz.langa

___
Python tracker 

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

[issue21188] Broken link

[Éric Araujo]

Éric Araujo added the comment:

Thanks for the report.

If the python.org links can be found in the Internet Archive, then one could 
find the new addresses to use by looking for the same message on 
http://www.python.org/pipermail/python-dev/2000-March/

Would you be willing to try that?

--
nosy: +eric.araujo

___
Python tracker 

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

[issue21198] Minor tarfile documentation bug

[Éric Araujo]

Éric Araujo added the comment:

Thanks for the report.  Is it an issue in the docstrings, the HTML 
documentation or both?

--
nosy: +eric.araujo

___
Python tracker 

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