[issue22422] IDLE closes all when in dropdown menu

[Brunel]

New submission from Brunel:

While python shell is running if the user puts a period after a statement and 
waits for the dropdown list to pop up, then closes python shell the following 
will happen:

IDLE will close all active windows immediately, regardless of any unsaved 
progress (which is lost.)

--
components: IDLE
messages: 226942
nosy: mandolout
priority: normal
severity: normal
status: open
title: IDLE closes all when in dropdown menu
type: crash

___
Python tracker 

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

[issue22379] Empty exception message of str.join

[Yongzhi Pan]

Yongzhi Pan added the comment:

I tested it and find str of an exception does not contain the exception type:

>>> a = TypeError()
>>> str(a)
''
>>> a = TypeError('b', 3)
>>> a.args
('b', 3)
>>> str(a)
"('b', 3)"

Am I missing some other circumstances?

--

___
Python tracker 

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

[issue22423] Errors in printing exceptions raised in a thread

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Proposed patch fixes some bugs in printing exceptions in the threading module.

1. Fixed names of private variables in initialization. This caused unhandled 
AttributeError. The regression was introduced in changeset e71c3223810f. This 
part of the patch shouldn't be applied to 2.7.

2. Handled the case when sys.stderr is None. Perhaps this caused a crash when 
Python program run with pythonw.exe.

3. Added missed test.

--
components: Library (Lib)
files: threading_print_exception.patch
keywords: patch
messages: 226944
nosy: pitrou, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Errors in printing exceptions raised in a thread
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36629/threading_print_exception.patch

___
Python tracker 

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

[issue14285] Traceback wrong on ImportError while executing a package

[Rob Agar]

Changes by Rob Agar :


--
nosy: +robagar

___
Python tracker 

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

[issue14285] Traceback wrong on ImportError while executing a package

[Rob Agar]

Rob Agar added the comment:

The message also needs to include the file and line number of the ImportError.

--

___
Python tracker 

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

[issue17120] Mishandled _POSIX_C_SOURCE and _XOPEN_SOURCE in pyconfig.h

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +loewis

___
Python tracker 

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

[issue22231] httplib: unicode url will cause an ascii codec error when combined with a utf-8 string header

[Bob Chen]

Bob Chen added the comment:

up...

--

___
Python tracker 

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

[issue22421] securing pydoc server

[Senthil Kumaran]

Senthil Kumaran added the comment:

The localhost breaking on your linux system might be due to improper /etc/hosts 
or is localhost pointing to an ipv6 address?

That said, I think it is okay to rely on 127.0.0.1 as host for running pydoc 
server. I am unsure why the initial check was done only for mac (and windows 
and linux are left to use localhost).

--
nosy: +orsenthil

___
Python tracker 

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

[issue22407] re.LOCALE is nonsensical for Unicode

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue22407] re.LOCALE is nonsensical for Unicode

[STINNER Victor]

Changes by STINNER Victor :


--
components: +Unicode

___
Python tracker 

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

[issue22400] Stable API broken on Windows for PyUnicode_*

[STINNER Victor]

STINNER Victor added the comment:

I think this issue was already fixed by this change:

changeset:   88287:ea0aa3e32ab5
branch:  3.3
parent:  88263:203ca77ea819
user:Martin v. Löwis 
date:Sat Jan 04 10:01:42 2014 +0100
files:   Misc/NEWS PC/python3.def
description:
Issue #17432: Drop UCS2 from names of Unicode functions in python3.def.

--
nosy: +haypo

___
Python tracker 

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

[issue22407] re.LOCALE is nonsensical for Unicode

[Antoine Pitrou]

Antoine Pitrou added the comment:

I don't think we should fix this in 2.x: some people may rely on the old 
behaviour, and it will be difficult for them to debug.
In 3.x, I simply propose we deprecate re.LOCALE for unicode strings and make it 
a no-op.

--

___
Python tracker 

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

[issue22421] securing pydoc server

[Antoine Pitrou]

Changes by Antoine Pitrou :


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

[issue21270] unittest.mock.call object has inherited count method

[Kushal Das]

Kushal Das added the comment:

Uploading the second version of the patch.

--
Added file: http://bugs.python.org/file36630/issue21270_v2.patch

___
Python tracker 

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

[issue21270] unittest.mock.call object has inherited count method

[Roundup Robot]

Roundup Robot added the comment:

New changeset 5660c1bdc2b6 by Kushal Das in branch 'default':
Closes #21270 : We now override tuple methods in mock.call objects.
https://hg.python.org/cpython/rev/5660c1bdc2b6

--
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

___
Python tracker 

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

[issue22424] make: *** [Objects/unicodeobject.o] Error 1

[bono wang]

New submission from bono wang:

when i was upgrade from py 2.6 to py 3.3
the error is show up 

# make && make install
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Parser/acceler.o Parser/acceler.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Parser/grammar1.o Parser/grammar1.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Parser/listnode.o Parser/listnode.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Parser/node.o Parser/node.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Parser/parser.o Parser/parser.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Parser/bitset.o Parser/bitset.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Parser/metagrammar.o Parser/metagrammar.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Parser/firstsets.o Parser/firstsets.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Parser/grammar.o Parser/grammar.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Parser/pgen.o Parser/pgen.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Parser/myreadline.o Parser/myreadline.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Parser/parsetok.o Parser/parsetok.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Parser/tokenizer.o Parser/tokenizer.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/abstract.o Objects/abstract.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/accu.o Objects/accu.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/boolobject.o Objects/boolobject.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/bytes_methods.o 
Objects/bytes_methods.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/bytearrayobject.o 
Objects/bytearrayobject.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/bytesobject.o Objects/bytesobject.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/cellobject.o Objects/cellobject.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/classobject.o Objects/classobject.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/codeobject.o Objects/codeobject.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/complexobject.o 
Objects/complexobject.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/descrobject.o Objects/descrobject.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/enumobject.o Objects/enumobject.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/exceptions.o Objects/exceptions.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/genobject.o Objects/genobject.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/fileobject.o Objects/fileobject.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/floatobject.o Objects/floatobject.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/frameobject.o Objects/frameobject.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/funcobject.o Objects/funcobject.c
gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. 
-I./Include-DPy_BUILD_CORE -o Objects/iterobject.

[issue22424] make: *** [Objects/unicodeobject.o] Error 1

[STINNER Victor]

STINNER Victor added the comment:

> i really dont know how to fix it

It's a GCC bug, not a Python bug: "gcc: Internal error: ...".

What is your OS? What is your GCC version? How much memory do you have?

Do you get the same error if you run "make" again?

Try to run "gcc -pthread -c  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes 
-I. -I./Include -DPy_BUILD_CORE -o Objects/unicodeobject.o" again.

Do you modify MAKEFLAGS to set -j to run GCC in parallel?

Usually, you can workaround GCC bugs by disabling optimizations. You can try to 
modify Makefile to replace "-O3" with "-O2" or even "-O0" (disable all 
optimizations), and then try to run "make" again.

Again, it's not a Python bug, but a GCC bug, probably already fixed in a more 
recent GCC version (the latest is 4.9.1):
https://gcc.gnu.org/

--
nosy: +haypo -165559672

___
Python tracker 

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

[issue22421] securing pydoc server

[Senthil Kumaran]

Senthil Kumaran added the comment:

sys.platform is darwin since OS X 10.5. I am not sure when it's value was 
'mac', So effectively the host was localhost on mac systems.

Directly setting the host value to localhost on all platforms may be right 
thing to do. Here is a patch with tests.

--
assignee:  -> orsenthil
Added file: http://bugs.python.org/file36631/issue22421.diff

___
Python tracker 

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

[issue22418] ipaddress.py new IPv6 Method for Solicited Multicast Address

[Eric V. Smith]

Eric V. Smith added the comment:

Changing to 3.5 only, as this is an API addition so it can only be added there.

I think that raising an exception instead of retuning None for a multicast 
address would be a better API.

Any chance you can write some tests?

Thanks!

--
nosy: +eric.smith
stage:  -> test needed
versions:  -Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

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

[issue22400] Stable API broken on Windows for PyUnicode_*

[Jeremy Kloth]

Jeremy Kloth added the comment:

Ah, yes indeeed.  Sorry for the noise as it was that my local repos were having 
some syncing issues so I had out of date sources.

Marking as closed (fixed) and duplicate of issue17432.

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

___
Python tracker 

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

[issue22400] Stable API broken on Windows for PyUnicode_*

[R. David Murray]

Changes by R. David Murray :


--
stage:  -> resolved

___
Python tracker 

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

[issue22424] make: *** [Objects/unicodeobject.o] Error 1

[bono wang]

bono wang added the comment:

Usually, you can workaround GCC bugs by disabling optimizations. You can try to 
modify Makefile to replace "-O3" with "-O2" or even "-O0" (disable all 
optimizations), and then try to run "make" again.



donethanks a lot

--
nosy: +165559672
resolution:  -> fixed

___
Python tracker 

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

[issue21472] Fix wsgiref handling of absolute HTTP Request-URI

[mouad]

mouad added the comment:

Hi Guido,

If I understand this correctly, the HOST header was added only in HTTP1.1 and 
setting the absolute URI was the right behavior client should follow if they 
are behind a proxy for HTTP1.0, but the same behavior was kept in HTTP1.1 for 
backward compatibility.

> In any case I would worry (a bit) that this might cause security issues if
> implemented as naively as shown in your patch,
> the other components of the URL should probably be validated against the
> configuration of the server.
> Also I am wondering whether specifying a different port or protocol (e.g.
> HTTPS) should be allowed or not.

If there should be a validation, I think it should be done in 
BaseHTTPRequestHandler, FWIW this later doesn't validate HOST header neither, 
just tested sending a request to "python -mhttp.server" which succeeded.

$ telnet 127.0.0.1 8000
GET /dummy HTTP/1.1
HOST google.com

One thing to note here for future work for the validation part, is that 
according to http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.2, 
first point:

If Request-URI is an absoluteURI, the host is part of the Request-URI.
Any Host header field value in the request MUST be ignored.

> and what to do with extraneous parts of the path (in particular the
> "#fragment" identifier)

AFAIK clients are not supposed to send fragments to servers, and I didn't find 
in the HTTP spec what should happen if they do, CherryPy for example (link of 
the code is in the footer) will raise 400 if request URI include the #fragment 
part.

An other thing that CherryPy guys also did, is that ``HTTPRequest(...).path`` 
will always return a relativ path, which is IMHO the right behavior but for 
backward compatibility I hesitate fixing this problem directly in 
BaseHTTPRequestHandler or should we ? 

> You should probably also be careful with path-less domain names -- IIRC some
> URL parsers produce "" as the path for e.g. "http://python.org";.

According to the PEP-0333 the PATH_INFO can be empty: 

PATH_INFO
 The remainder of the request URL's "path", designating the virtual   
 "location" of the request's target within the application. This may be an
 empty string, if the request URL targets the application root and does 
 
 not have a trailing slash.

> Have you asked for the status of this particular feature?

I sent an email to python WEB-SIG mailing list trying to gather information 
about this behavior, but not luck yet :(

At this point I would like to link to both CherryPy and Werkzeug that already 
handle this behavior.

Werkzeug: 
https://github.com/mitsuhiko/werkzeug/blob/0.9.6/werkzeug/serving.py#L75-81
CherryPy: 
https://github.com/cherrypy/cherrypy/blob/cherrypy-3.2.2rc1/cherrypy/wsgiserver/wsgiserver3.py#L633-638.

As a side note, I have already said in my email to the WEB-sig kudos to 
cherrypy guys, the funny part is that I am starting to think that they 
succeeded in both my tests because they didn't rely on core python 
implementation of BaseHTTPRequestHandler (I guess reinventing the wheel 
sometime works :)), at the opposite to other frameworks that showed this 
problems :).

Cheers,

--

___
Python tracker 

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

[issue22424] make: *** [Objects/unicodeobject.o] Error 1

[STINNER Victor]

Changes by STINNER Victor :


--
nosy:  -165559672
resolution: fixed -> not a bug
status: open -> closed

___
Python tracker 

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

[issue22407] re.LOCALE is nonsensical for Unicode

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Yes, one of solution is to deprecate re.LOCALE for unicode strings and then 
make it incompatible with unicode strings. But I think it would be good to 
implement locale-aware matching.

Example.

>>> for a in 'Ii\u0130\u0131':
... for b in 'Ii\u0130\u0131':
... if a != b and re.match(a, b, re.I): print(a, '~', b)
... 
I ~ i
I ~ İ
i ~ I
i ~ İ
İ ~ I
İ ~ i

This is incorrect result in Turkish. Capital dotless "I" matches capital "İ" 
with dot above, and small dotless "ı" doesn't match anything.

Regex produces more relevant output, which includes matches for Turkish and 
English:

I ~ i
I ~ ı
i ~ I
i ~ İ
İ ~ i
ı ~ I

With locale tr_TR.utf8 (with the patch):

>>> for a in 'Ii\u0130\u0131':
... for b in 'Ii\u0130\u0131':
... if a != b and re.match(a, b, re.I|re.L): print(a, '~', b)
... 
I ~ ı
i ~ İ
İ ~ i
ı ~ I

This is correct result in Turkish.

Therefore there is a use case for this feature.

--

___
Python tracker 

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

[issue22407] re.LOCALE is nonsensical for Unicode

[Antoine Pitrou]

Antoine Pitrou added the comment:

Ha, I always forget about the Turkish locale case...

--

___
Python tracker 

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

[issue22412] Towards an asyncio-enabled command line

[Guido van Rossum]

Guido van Rossum added the comment:

There's a sage piece of advice somewhere in the developer docs. "Know when to 
give up."

I think you need to write a PEP trying to argue that supporting "yield from" in 
the REPL is essential to a large category of users, so you can lobby for 
support.

In the mean time, you have not even responded to the repeated option of 
providing a simple helper function. If you are concerned about integrating with 
a platform-provide UI, perhaps you can use a second thread? Asyncio and threads 
actually have a well-defined interface.

I am actually more sympathetic to getting the readline thing fixed -- perhaps 
you can work with the IPython folks on a proposal.

--

___
Python tracker 

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

[issue22379] Empty exception message of str.join

[R. David Murray]

R. David Murray added the comment:

No, you are right and I am wrong.  I should have checked myself :)

--

___
Python tracker 

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

[issue22412] Towards an asyncio-enabled command line

[Martin Teichmann]

Martin Teichmann added the comment:

Well, so I am giving up, apparenty my work is not wanted here.

But not before submitting at least the last version of my
patch. I seperated out my _input function into two, start_input
and continue_input, which are supposed to work in a loop
as in 

start_input(prompt)
while True:
   r = continue_input()
   if r is not None: return r

This would help at least people like IPython.

--
Added file: http://bugs.python.org/file36632/patch3

___
Python tracker 

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

[issue22412] Towards an asyncio-enabled command line

[Martin Teichmann]

Martin Teichmann added the comment:

And as a last comment, just for completeness, a complete 
async console. With it you can do cool things like

>>> from asyncio import sleep, async
>>> def f():
...yield from sleep(3)
...print("done")
>>> yield from f()
[after 3 seconds]
done
>>> async(f())
>>> [wait another 3 seconds] done

Just see how async puts something in the background, while
yield from keeps it up, and how the event loop runs even
while we're doing nothing!

Let's hope other projects out there are more open to making 
their event loops asyncio-compatible than CPython is -
otherwise asyncio will soon cease to exist.

--
Added file: http://bugs.python.org/file36633/cl.py

___
Python tracker 

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

[issue22425] 2to3 import fixer writes dotted_as_names into import_as_names

[Simon Weber]

New submission from Simon Weber:

When dealing with implicit relative imports of the form "import 
 as...", the 2to3 import fixer will rewrite them as "from . 
import  as...".

This is invalid syntax. Here's an example:

$ tree package/
package/
├── __init__.py
├── rootmod.py
└── subpackage
├── __init__.py
└── mod.py

1 directory, 4 files

$ cat package/rootmod.py  # this is the only nonempty file
import subpackage.mod as my_name

$ python package/rootmod.py

$ 2to3 -w -f import package/
RefactoringTool: Refactored package/rootmod.py
--- package/rootmod.py  (original)
+++ package/rootmod.py  (refactored)
@@ -1 +1 @@
-import subpackage.mod as my_name
+from . import subpackage.mod as my_name
RefactoringTool: Files that were modified:
RefactoringTool: package/rootmod.py

$ python package/rootmod.py
  File "package/rootmod.py", line 1
from . import subpackage.mod as my_name
^
SyntaxError: invalid syntax

Probably the easiest way to rewrite this is "from .subpackage import mod as 
my_name".

--
components: 2to3 (2.x to 3.x conversion tool)
messages: 226965
nosy: simonmweber
priority: normal
severity: normal
status: open
title: 2to3 import fixer writes dotted_as_names into import_as_names
type: behavior
versions: Python 2.7, Python 3.4

___
Python tracker 

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

[issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD'

[Akira Li]

New submission from Akira Li:

>>> import os
  >>> import time
  >>> os.environ['TZ'] = 'Europe/Moscow'
  >>> time.tzset()
  >>> time.strptime('2010-06-01 MSK', '%Y-%m-%d %Z')
  time.struct_time(tm_year=2010, tm_mon=6, tm_mday=1, tm_hour=0, tm_min=0, 
tm_sec=0, tm_wday=1, tm_yday=152, tm_isdst=0)
  >>> time.strptime('2010-06-01 MSD', '%Y-%m-%d %Z')
  Traceback (most recent call last):
File "", line 1, in 
File "/usr/lib/python2.7/_strptime.py", line 467, in _strptime_time
  return _strptime(data_string, format)[0]
File "/usr/lib/python2.7/_strptime.py", line 325, in _strptime
  (data_string, format))
  ValueError: time data '2010-06-01 MSD' does not match format '%Y-%m-%d %Z'

datetime.strptime() and Python 3 behavior is exactly the same. 

The correct name is MSD:

  >>> from datetime import datetime, timezone
  >>> dt = datetime(2010, 5, 31, 21, tzinfo=timezone.utc).astimezone()
  >>> dt.strftime('%Y-%m-%d %Z')
  '2010-06-01 MSD'

strptime() uses the current (wrong for the past date) time.tzname names
despite the correct name being known to the system (as the example above 
demonstrates).

In general, it is impossible to validate a time zone abbreviation even if
the time zone database is available:

- tzname may be ambiguous -- multiple zoneinfo matches (around one third
  of tznames the tz database correspond to multiple UTC offsets (at the
  same or different times) -- it is not unusual) i.e., any scheme that 
  assumes that tzname is enough to get UTC offset such as
  Lib/email/_parsedate.py is wrong.

- and even if zoneinfo is known, it may be misleading e.g., 
  e.g., HAST (Hawaii-Aleutian Standard Time) might be rejected
  because Pacific/Honolulu zoneinfo uses HST. HAST corresponds to 
  America/Adak (US/Aleutian) in tzdata (UTC offset may be the same).
  It might be too rare to care.

Related: issue22377

--
components: Library (Lib)
messages: 226966
nosy: akira
priority: normal
severity: normal
status: open
title: strptime accepts the wrong '2010-06-01 MSK' string but rejects the right 
'2010-06-01 MSD'
type: behavior
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

[issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD'

[Akira Li]

Akira Li added the comment:

Correction:

The correct offset is +0400:

  >>> dt = datetime(2010, 5, 31, 20, tzinfo=timezone.utc).astimezone()

And _timezones dict is defined in Lib/email/_parseaddr.py

--

___
Python tracker 

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

[issue22412] Towards an asyncio-enabled command line

[Guido van Rossum]

Guido van Rossum added the comment:

I'm sorry you feel that way. I hope one day you will understand the other side 
of this kind of issue.

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

[issue22425] 2to3 import fixer writes dotted_as_names into import_as_names

[Ned Deily]

Changes by Ned Deily :


--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD'

[Ned Deily]

Changes by Ned Deily :


--
nosy: +belopolsky, lemburg

___
Python tracker 

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

[issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD'

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

There is no daylight savings time in Moscow and python detects this correctly:

$ TZ=Europe/Moscow python3
>>> import time
>>> time.daylight
0

Note that historically, there was DST, but time module cannot handle historical 
TZ changes.

(Russian government compensates the relative sanity of not moving the clocks 
twice a year by changing the UTC offset and TZ boundaries every 5 years or 
so.:-)

--

___
Python tracker 

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

[issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD'

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

I don't think there is anything we can do here.  Without a TZ database, Python 
has to rely on time.tzname which in case of TZ=Europe/Moscow returns

>>> time.tzname
('MSK', 'MSK')

Hardcoding a timezones dictionary as done in email module may work for a 
handful of American timezones, but will not work for TZ's like Europe/Moscow.

$ zdump -v  Europe/Moscow| tail
Europe/Moscow  Sat Oct 24 22:59:59 2009 UTC = Sun Oct 25 02:59:59 2009 MSD 
isdst=1
Europe/Moscow  Sat Oct 24 23:00:00 2009 UTC = Sun Oct 25 02:00:00 2009 MSK 
isdst=0
Europe/Moscow  Sat Mar 27 22:59:59 2010 UTC = Sun Mar 28 01:59:59 2010 MSK 
isdst=0
Europe/Moscow  Sat Mar 27 23:00:00 2010 UTC = Sun Mar 28 03:00:00 2010 MSD 
isdst=1
Europe/Moscow  Sat Oct 30 22:59:59 2010 UTC = Sun Oct 31 02:59:59 2010 MSD 
isdst=1
Europe/Moscow  Sat Oct 30 23:00:00 2010 UTC = Sun Oct 31 02:00:00 2010 MSK 
isdst=0
Europe/Moscow  Sat Mar 26 22:59:59 2011 UTC = Sun Mar 27 01:59:59 2011 MSK 
isdst=0
Europe/Moscow  Sat Mar 26 23:00:00 2011 UTC = Sun Mar 27 03:00:00 2011 MSK 
isdst=0
Europe/Moscow  Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 07:14:07 2038 MSK 
isdst=0
Europe/Moscow  Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 07:14:07 2038 MSK 
isdst=0

(And it looks like the planned for 2014-10-26 switch back to winter time is not 
in my laptop's database yet.)

--

___
Python tracker 

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

[issue22377] %Z in strptime doesn't match EST and others

[Berker Peksag]

Berker Peksag added the comment:

> if PEP 431 is implemented (or anything that gives access to zoneinfo)
> then strptime could extend the list of timezones it accepts (utc + 
> local timezone names) to include names from the tz database:

FTR, I have a WIP(and probably a bit outdated) branch to implement PEP 431 on 
GitHub:

https://github.com/berkerpeksag/cpython/tree/pep431

--
nosy: +berker.peksag

___
Python tracker 

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

[issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD'

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

On the second thought, we can probably make the same guesswork as in 
PyInit_timezone (see Modules/timemodule.c) in time.strptime, but not for the 
current time, but for the time parsed.

--

___
Python tracker 

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

[issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD'

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
assignee:  -> belopolsky

___
Python tracker 

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

[issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD'

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
stage:  -> needs patch
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.4

___
Python tracker 

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

[issue22339] Incorrect behavior when subclassing enum.Enum

[Ethan Furman]

Ethan Furman added the comment:

http://hg.python.org/cpython/rev/4135f3929b35
http://hg.python.org/cpython/rev/cdd412347827

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue21738] Enum docs claim replacing __new__ is not possible

[Roundup Robot]

Roundup Robot added the comment:

New changeset 28c21f09719e by Ethan Furman in branch '3.4':
Issue21738: clarify usage of __new__ in Enum subclasses
https://hg.python.org/cpython/rev/28c21f09719e

New changeset 91ec34801232 by Ethan Furman in branch 'default':
Issue21738: clarify usage of __new__ in Enum subclasses
https://hg.python.org/cpython/rev/91ec34801232

--
nosy: +python-dev

___
Python tracker 

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

[issue21738] Enum docs claim replacing __new__ is not possible

[Ethan Furman]

Changes by Ethan Furman :


--
assignee: ethan.furman -> docs@python
nosy: +docs@python
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue21706] Add base for enumerations (Functional API)

[Roundup Robot]

Roundup Robot added the comment:

New changeset ec016ba862ba by Ethan Furman in branch 'default':
Close issue21706: add 'start' parameter to functional API
https://hg.python.org/cpython/rev/ec016ba862ba

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue22377] %Z in strptime doesn't match EST and others

[Akira Li]

Akira Li added the comment:

If the current implementation is considered correct (%Z not recognizing
EST) then indeed extending the list of recognized timezones is another
issue. And the docs should be changed to match the implementation.

The current behavior is broken, see also issue22426

If we assume that the docs are correct (%Z should match EST) even if it
is not implemented yet then it is this issue's responsibility to extend
the list of recognized timezones (even an incomplete hard-coded list
generated by the code from msg226857 would be fine).

Lib/email/_parseaddr.py approach (tzname corresponds to a fixed utc
offset) is wrong: tzname may correspond to multiple utc offsets at the
same time (different timezones) and at different times (even within the
same timezone). Having the tz database won't fix it: *tzname along is
not enough to determine UTC offset in _many_ cases.*


CST is ambiguous if %z is not given therefore even if strptime() had the
access to a larger list of recognized timezones; it is not clear what
the return value would be:

- aware datetime: which timezone to use?

- naive datetime: it might be misleading if the input timezone name
  doesn't correspond to utc or the local timezone

email._parseaddr._timezones is misleading if used globally: CST is also
used in Australia, China with different utc offsets.

One of possible solutions is to return aware datetime objects if a new
truthy *timezones* keyword-only argument is provided. It may contain a
mapping to disambiguate timezone abbreviations: {'EST': timedelta|tzinfo}.

If *timezones* is False then strptime() returns a naive datetime
object. The only difference from the current behavior is that a larger
list of timezones is supported to match the docs.

With bool(timezones) == True, strptime() could return an aware datetime
object in utc, local timezones, or any timezone in *timezones* if it is
a mapping.

Default *timezones* is None that means timezone=False for backward
compatibility. DeprecationWarning is added that timezone=True will be
default in the next release 3.6 if no objections are received
until then e.g.,

if tzname and timezones is None: # %Z matches non-empty string
warn("Default *timezones* parameter for "
 "%s.strptime() will be True in Python 3.6. "
 "Pass timezones=False to preserve the old behaviour" % (
 cls.__qualname__,),
 category=DeprecationWarning, stacklevel=2)

I've uploaded the patch draft-strptime-%Z-timezones.diff that implements
this solution. It also contains tests and docs updates.

--
keywords: +patch
Added file: http://bugs.python.org/file36634/draft-strptime-%Z-timezones.diff

___
Python tracker 

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

[issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD'

[Akira Li]

Akira Li added the comment:

My patch for issue22377 also fixes this bug.

With the patch applied. Both MSK and MSD are accepted if the new 
timezones parameter is false (default for Python 3.5, will be changed to 
True in Python 3.6

If timezones is True then MSD return a correct aware datetime object,
MSK is rejected.

--

___
Python tracker 

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

[issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD'

[Akira Li]

Akira Li added the comment:

MSD variant works on my machine because C library uses
the historical timezone database there. I'm not sure whether it
works on old Windows versions.

--

___
Python tracker 

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

[issue22427] TemporaryDirectory attempts to clean up twice

[Jack O'Connor]

New submission from Jack O'Connor:

The following little script prints (but ignores) a FileNotFoundError.

import tempfile
def generator():
with tempfile.TemporaryDirectory():
yield
g = generator()
next(g)

Exception ignored in: 
Traceback (most recent call last):
  File "gen.py", line 6, in generator
  File "/usr/lib/python3.4/tempfile.py", line 691, in __exit__
  File "/usr/lib/python3.4/tempfile.py", line 697, in cleanup
  File "/usr/lib/python3.4/shutil.py", line 454, in rmtree
  File "/usr/lib/python3.4/shutil.py", line 452, in rmtree
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/tmp7wek4xhy'

Putting print statements in the TemporaryDirectory class shows what's happening 
(confirming Guido's theory from 
https://groups.google.com/forum/#!topic/python-tulip/QXgWH32P2uM): As the 
program exits, the TemporaryDirectory object is finalized. This actually 
rmtree's the directory. After that, the generator is finalized, which raises a 
GeneratorExit inside of it. That exception causes the with statement to call 
__exit__ on the already-finalized TemporaryDirectory, which tries to rmtree 
again and throws the FileNotFoundError.

The main downside of this bug is just garbage on stderr. I suppose in 
exceptionally unlikely circumstances, a new temp dir by the same name could be 
created between the two calls, and we might actually delete something we 
shouldn't. The simple fix would be to store a _was_cleaned flag or something on 
the object. Is there any black magic in finalizers or multithreading that 
demands something more complicated?

--
components: Library (Lib)
messages: 226979
nosy: oconnor663
priority: normal
severity: normal
status: open
title: TemporaryDirectory attempts to clean up twice
type: behavior
versions: Python 3.4

___
Python tracker 

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

[issue22421] securing pydoc server

[Roundup Robot]

Roundup Robot added the comment:

New changeset c438f6aaafa9 by Senthil Kumaran in branch '3.3':
Issue #22421 - Secure pydoc server run. Bind it to localhost instead of all 
interfaces.
https://hg.python.org/cpython/rev/c438f6aaafa9

New changeset d36c0f2ab821 by Senthil Kumaran in branch '3.4':
Merge from 3.3
https://hg.python.org/cpython/rev/d36c0f2ab821

New changeset 9f7b97fac919 by Senthil Kumaran in branch 'default':
Merge from 3.4
https://hg.python.org/cpython/rev/9f7b97fac919

--
nosy: +python-dev

___
Python tracker 

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

[issue22421] securing pydoc server

[Senthil Kumaran]

Senthil Kumaran added the comment:

2.7 was not affected and it was binding to localhost properly.

Since it is security related issue, I have fixed it in 3.3 as well.
Fix is now present in 3.4 and 3.5

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.3 -Python 2.7

___
Python tracker 

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