date:20151004


STINNER Victor added the comment:

I reopen the issue. The patch is outdated. Richard Oudkerk doens't seem to be 
active last weeks :-/

--
resolution: out of date -> 
status: closed -> open

___
Python tracker 

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

[issue23919] [Windows] test_os fails several C-level assertions


STINNER Victor added the comment:

I would prefer to disable the popups and messages to stderr by default in 
Python directly. If some users want to see them, we can add a -X option to 
enable them. Example: -X enable_mscrt_checks. What do you think? Do you recall 
who complain that Python hides MSCRT warnings? And why he/she complained?

I don't want these warnings, especially popups blocking my program, on my own 
applications. Python already raises OSError on errors.

The problem in tests is also that some tests use subprocesses and regrtest only 
configures the test runner, not subprocesses. For example, I had to modify a 
subprocess started by the test. Otherwise, the test *hangs* :-(

Popups are annoying because it's not possible to ignore them all by a single 
click. I have to click N times for N errors, with N>100 it's just a nightmare...

For me, it's a regression compared to older Python versions. I don't remember 
to have to click on so much popups or have stderr flooded by warnings when 
working on Windows, when I worked on Python 3.4 or older.

--

___
Python tracker 

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

[issue23919] [Windows] test_os fails several C-level assertions


STINNER Victor added the comment:

23919_1.patch looks good to me.

--

___
Python tracker 

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

[issue25301] Optimize UTF-8 decoder with error handlers


Changes by STINNER Victor :


Added file: http://bugs.python.org/file40671/bench.py

___
Python tracker 

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

[issue25301] Optimize UTF-8 decoder with error handlers


STINNER Victor added the comment:

Results of the microbenchmark on the UTF-8 decoder.

As expected, performances on valid UTF-8 is unchanged, which was an important 
goal for me.

Decoding with error handlers optimized by the patch are *much* faster.

backslashreplace is still slow, because I didn't optimize it.

Common platform:
Python unicode implementation: PEP 393
Timer: time.perf_counter
Platform: Linux-4.1.5-200.fc22.x86_64-x86_64-with-fedora-22-Twenty_Two
CPU model: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
Timer info: namespace(adjustable=False, 
implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, 
resolution=1e-09)
Bits: int=32, long=64, long long=64, size_t=64, void*=64
CFLAGS: -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g 
-fwrapv -O3 -Wall -Wstrict-prototypes
Timer precision: 55 ns

Platform of campaign before:
SCM: hg revision=f51921883f50 tag=tip branch=default date="2015-10-04 01:19 
-0400"
Python version: 3.6.0a0 (default:f51921883f50, Oct 4 2015, 10:19:37) [GCC 5.1.1 
20150618 (Red Hat 5.1.1-4)]
Date: 2015-10-04 10:19:44

Platform of campaign after:
SCM: hg revision=f51921883f50+ tag=tip branch=default date="2015-10-04 01:19 
-0400"
Python version: 3.6.0a0 (default:f51921883f50+, Oct 4 2015, 10:14:05) [GCC 
5.1.1 20150618 (Red Hat 5.1.1-4)]
Date: 2015-10-04 10:18:55

-+-+
valid UTF-8 (strict) |  before |   after
-+-+
100 x 10**1 bytes|  297 ns (*) |  297 ns
100 x 10**3 bytes|  7.4 us (*) | 7.44 us
100 x 10**2 bytes|  929 ns (*) |  924 ns
100 x 10**4 bytes| 80.4 us (*) | 80.4 us
-+-+
Total| 89.1 us (*) |   89 us
-+-+

--+-+---
ignore|  before |  after
--+-+---
100 x 10**1 bytes | 6.68 us (*) |  743 ns (-89%)
100 x 10**3 bytes |  561 us (*) | 42.6 us (-92%)
100 x 10**2 bytes | 56.8 us (*) | 4.55 us (-92%)
100 x 10**4 bytes | 6.02 ms (*) |  425 us (-93%)
--+-+---
Total | 6.65 ms (*) |  473 us (-93%)
--+-+---

--+-+---
replace   |  before |  after
--+-+---
100 x 10**1 bytes | 7.61 us (*) |  890 ns (-88%)
100 x 10**3 bytes |  639 us (*) | 50.3 us (-92%)
100 x 10**2 bytes | 64.8 us (*) | 5.37 us (-92%)
100 x 10**4 bytes | 7.09 ms (*) |  505 us (-93%)
--+-+---
Total | 7.81 ms (*) |  561 us (-93%)
--+-+---

--+-+---
surrogateescape   |  before |  after
--+-+---
100 x 10**1 bytes | 7.96 us (*) |  855 ns (-89%)
100 x 10**3 bytes |  674 us (*) | 50.2 us (-93%)
100 x 10**2 bytes | 68.8 us (*) | 5.35 us (-92%)
100 x 10**4 bytes | 7.38 ms (*) |  504 us (-93%)
--+-+---
Total | 8.13 ms (*) |  560 us (-93%)
--+-+---

--+-+
backslashreplace  |  before |   after
--+-+
100 x 10**1 bytes | 7.66 us (*) | 7.89 us
100 x 10**3 bytes |  633 us (*) |  633 us
100 x 10**2 bytes | 64.1 us (*) | 64.6 us
100 x 10**4 bytes |  6.9 ms (*) | 6.93 ms
--+-+
Total | 7.61 ms (*) | 7.64 ms
--+-+

-+-+---
Summary  |  before |  after
-+-+---
valid UTF-8 (strict) | 89.1 us (*) |  89 us
ignore   | 6.65 ms (*) |  473 us (-93%)
replace  | 7.81 ms (*) |  561 us (-93%)
surrogateescape  | 8.13 ms (*) |  560 us (-93%)
backslashreplace | 7.61 ms (*) |7.64 ms
-+-+---
Total| 30.3 ms (*) | 9.32 ms (-69%)
-+-+---

--

___
Python tracker 

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

[issue24848] Warts in UTF-7 error handling


Serhiy Storchaka added the comment:

Test failure is random. With build 3435 tests are successful, with all other 
are failed. The same with other buildbot: 
http://buildbot.python.org/all/builders/x86%20Windows7%202.7/ . 3345 and 3347 
are green, others are red.

--

___
Python tracker 

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

[issue23919] [Windows] test_os fails several C-level assertions

2015-10-04 Thread Steve Dower


Steve Dower added the comment:

I referred to the issues that had -n added in the first place many times while 
adding the IPH handlers, but I don't have them handy now on my phone.

The rationale was that people who cause assertions in their C extensions should 
see them and not have Python suppress them. All cases where an assert is raised 
in a debug build is a coding error - the test suite deliberately causes some 
but this is not normal development and should not dictate normal configuration.

--

___
Python tracker 

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

[issue25304] Add run_coroutine_threadsafe() to asyncio

2015-10-04 Thread Vincent Michel


Vincent Michel added the comment:

While I was working on the documentation update, I realized that what we called 
`run_coroutine_threadsafe` is actually a thread-safe version of 
`ensure_future`. What about renaming it to `ensure_future_threadsafe`? It might 
be a bit late since `run_coroutine_threadsafe` has been committed, but I think 
it is worth to be considered. I can see two benefits:

- it is less confusing, because it has the same name and using the same 
prototype as `ensure_future`
- it accepts futures and awaitables

The docstring would be "Wrap a coroutine, an awaitable or a future in a 
concurrent.futures.Future.". The documentation would explain that it works like 
`ensure_future` except:
1. its execution is threadsafe
2. it provides a thread-safe future instead of a regular future

I attached an implementation of it. Also, note that I added a `try-except` in 
the callback, which is not mandatory but probably a good thing have.

In any case, I'll keep working on the documentation update.

--
Added file: http://bugs.python.org/file40672/ensure_future_threadsafe.py

___
Python tracker 

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

[issue25308] Multiple names can target the same namespace


R. David Murray added the comment:

I'd be willing to bet there are people using this as a feature.  I don't think 
we should make any change here.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue25304] Add run_coroutine_threadsafe() to asyncio

2015-10-04 Thread Yury Selivanov


Yury Selivanov added the comment:

> - it is less confusing, because it has the same name and using the same 
> prototype as `ensure_future`
> - it accepts futures and awaitables

I like this idea.

--

___
Python tracker 

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

[issue25304] Add run_coroutine_threadsafe() to asyncio

2015-10-04 Thread Guido van Rossum


Guido van Rossum added the comment:

I'm against that idea. I don't really see a great important future for this 
method either way: It's just a little bit of glue between the threaded and 
asyncio worlds, and people will learn how to use it by finding an example.

The existing ensure_future() function is mostly meant as an internal helper, 
with the understanding that libraries written on top of asyncio might also need 
this functionality. Basically I want people writing asyncio code not to have to 
worry about the difference between futures and coroutines, because they can 
both be awaited for; ensure_future() helps preserve that illusion for code that 
really needs a future (usually to add a callback).

But honestly I *don't* want to encourage flipping back and forth between 
threads and event loops; I see it as a necessary evil. The name we currently 
have is fine from the POV of someone coding in the threaded world who wants to 
hand off something to the asyncio world.

Why would someone in the threaded world have an asyncio.future that they need 
to wait for? That sounds like they're mixing up the two worlds -- or they 
should be writing asyncio code instead of threaded code.

OTOH, I would love to see the documentation update!

--

___
Python tracker 

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

[issue25300] Enable Intel MPX (Memory protection Extensions) feature

2015-10-04 Thread Stefan Krah


Stefan Krah added the comment:

Wouldn't setting CFLAGS be sufficient?

./configure CFLAGS="-fcheck-pointer-bounds -mmpx"


Otherwise we could also add --with-stack-protector and --with-fortify-source 
and others. I'm not sure if we should add a special --with*
option for every gcc flag.

--

___
Python tracker 

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

[issue25304] Add run_coroutine_threadsafe() to asyncio


R. David Murray added the comment:

I thought you might be interested to know what the name suggests to a relative 
newcomer to asyncio.

When I saw this issue opened, I though "oh, good, an easy way to submit a 
coroutine from a thread in my test code, now I don't have to write 
'loop.call_soon_threadsafe(loop.create_task, my_coroutine(loop=loop))".  Which 
I suspect you are going to tell me is stupid code, but the point is that that's 
what the name 'call_coroutine_threadsafe' made me think it was going to do.  
After reading the linked issue I was very confused about what it was actually 
going to do, as I've never gotten around to looking up what ensure_future does.

If I'm understanding correctly now, I think my assumption was pretty much 
correct, and the only difference is that I get back something I can actually 
manipulate if I need to, making it even better, and which the documentation 
should make clear when I get to read it :)

--
nosy: +r.david.murray

___
Python tracker 

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

[issue25309] askopenfilename crashes on XP with "Show pop-up description for folder and desktop items" on

2015-10-04 Thread alex wieder


alex wieder added the comment:

Terry, thanks for your feedback.

By crash, I mean python crashing with a Windows c005 error. I can't even 
capture that exception in a try...except structure.

This is on an Intel Core2Duo 2.7GHz with 4 GB of RAM, with Acrobat Reader X 
installed, which might account for Windows Explorer's delay in gathering the 
pdfs' information and presenting it in the pop-up. It also happens on a virtual 
XP machine I use at my office (VirtualBox running on an i7-based linux box).

I ran pickfile.py every way I could think of: with python's console 
interpreter, with the windows-based interpreter (no black console window 
showing up). In both cases I tried compiled and interpreted versions of it (.py 
& .pyc), and also from within Eclipse (regular run and debugger).

As long as a user double-clicks on a file while Windows is still gathering 
information to display in the pop-up, it crashes.

I will have access to win7 i5-based computers next week, so I can test  then, 
but these will be much faster computers, so this issue might be moot.

Python 3.4.3. I don't know how to check tkinter version, but it's the one that 
comes with the 3.4.3 python installer.

Comment-per-line... I know, but I need to be able to read my own code six 
months from now (I still maintain code written by me 25 years ago and if it 
weren't for those, I'd be screwed sometimes). I realize that this particular 
program is quite obvious, but pickfile.py is just a slice of a much longer 
file. I'll remove obvious comments if I have to post again.

--

___
Python tracker 

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

[issue25311] Add f-string support to tokenize.py

2015-10-04 Thread Stefan Krah


New submission from Stefan Krah:

I think tokenize.py needs to be updated to support f-strings.


BTW, the f-string implementation seems to be incredibly robust. Nice work!

--
components: Library (Lib)
messages: 252274
nosy: eric.smith, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: Add f-string support to tokenize.py
type: behavior
versions: Python 3.6

___
Python tracker 

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

[issue25311] Add f-string support to tokenize.py

2015-10-04 Thread Eric V. Smith


Eric V. Smith added the comment:

Thanks for noticing tokenize.py. And thanks for the kind note!

--
assignee:  -> eric.smith

___
Python tracker 

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

[issue25312] Cryptic error message if incorrect spec is set on a callable mock

2015-10-04 Thread Tzu-ping Chung


New submission from Tzu-ping Chung:

>>> from unittest import mock
>>> 
>>> class Foo:
... def __init__(self, val):
... pass
... def func(self):
... pass
... 
>>> class FooMock(mock.Mock):
... def _get_child_mock(self, **kwargs):
... return mock.Mock(spec_set=Foo)
... 
>>> mock_foo = FooMock()
>>> mock_foo.func()

>>> mock_foo.func.mock_calls
[call()]
>>> mock_foo.func.assert_has_calls([mock.call()])
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.5/unittest/mock.py", line 824, in assert_has_calls
) from cause
AssertionError: Calls not found.
Expected: [call()]
Actual: [call()]


While this code is expected to fail (FooMock.func is set to an incorrect spec), 
the error message is misleading and does not make any sense.

--
components: Library (Lib)
messages: 252276
nosy: uranusjr
priority: normal
severity: normal
status: open
title: Cryptic error message if incorrect spec is set on a callable mock
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

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

[issue25304] Add run_coroutine_threadsafe() to asyncio

2015-10-04 Thread Yury Selivanov


Yury Selivanov added the comment:

> But honestly I *don't* want to encourage flipping back and forth between 
> threads and event loops; I see it as a necessary evil. The name we currently 
> have is fine from the POV of someone coding in the threaded world who wants 
> to hand off something to the asyncio world.

I agree, but on the other hand supporting awaitables in addition to coroutines 
would be great. Can we at least add that?

--
nosy: +Yury.Selivanov

___
Python tracker 

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

[issue25313] IDLE: gracefully handle themes (or keysets, or ...) not present


New submission from Mark Roseman:

As a follow-on to #24820, when a particular theme is selected in the 
configuration files, but that theme is not available, IDLE will print out a 
bunch of warning messages on console. That can occur for example when using a 
newer built-in theme in an older version before that theme was added, or if the 
user highlight config file was modified or removed.

IDLE should be smart enough to recognize that and switch to a default theme, 
without dumping out console error messages. May alert user to that case with an 
appropriate error message, e.g. theme xyz not found, using default.

The current workaround in #24820 (when a newer theme is chosen in a new 
version, explain it may not work in older version but explain how it could be 
made to) is unfortunately necessary unless a more clever solution for this 
backwards compatibility issue can be found.

Would apply to keysets, etc. in the same was as themes.

--
components: IDLE
messages: 252278
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: gracefully handle themes (or keysets, or ...) not present
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6

___
Python tracker 

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

[issue24820] IDLE themes for light on dark


Mark Roseman added the comment:

FYI, the change multiple backgrounds thing is in my working version for the new 
dialog. Added new issue #25313 to remind us that the warning message is 
something we'd love to get rid of in the future and as quickly as possible make 
it unnecessary if we add more new themes and/or new features in themes.

--

___
Python tracker 

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

[issue25309] askopenfilename crashes on XP with "Show pop-up description for folder and desktop items" on


Serhiy Storchaka added the comment:

Please test Tcl version of your example.

wish pickfile.tcl

--
nosy: +serhiy.storchaka
Added file: http://bugs.python.org/file40673/pickfile.tcl

___
Python tracker 

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

[issue25309] askopenfilename crashes on XP with "Show pop-up description for folder and desktop items" on

2015-10-04 Thread alex wieder


alex wieder added the comment:

wish pickfile.tcl? Sorry. Too cryptic for me.

I ran the following code from the python interpreter:

import tkinter as tk

tk.TclVersion 
tk.TkVersion

Both return 8.6.

--

___
Python tracker 

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

[issue25313] IDLE: gracefully handle themes (or keysets, or ...) not present


Mark Roseman added the comment:

Actually, I think we may be able to get away without the warning message when 
you select a 'new' theme, and still maintain backwards compatibility.

For 'new' themes (i.e. IDLE Dark and any more builtins we add in the future), 
we write the theme out to the user configuration file, keeping the same name, 
and perhaps adding an extra field, i.e. 'builtin=1', so that we can recognize 
it in newer versions, along with a comment if possible.

The existing code looks up theme names by checking if its in the default list, 
and if not, looks in the user list. For older versions without IDLE Dark, it 
will then find it in the user list.

Besides writing out the theme to user config file, the only other change that 
would be needed in the code is to modify GetSectionList so that when it's 
looking in a user config file, it doesn't include sections that either have the 
builtin=1 from above, or just have the same name as things in the default file.

--

___
Python tracker 

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

[issue25313] IDLE: gracefully handle themes (or keysets, or ...) not present


Mark Roseman added the comment:

Patch write-new-defaults.patch attached so that we write 'newer' default themes 
to config-highlight.cfg if selected, and ignore them if we already have a 
default by that name.

--
keywords: +patch
Added file: http://bugs.python.org/file40674/write-new-defaults.patch

___
Python tracker 

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

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

2015-10-04 Thread shanmbic


shanmbic added the comment:

I modified the "format_utcoffset" function in "_datetimemodule.c", to accept 
one more parameter "secondsrequired" . It is a boolean variable (PyObject) , 
which when set to true, the function will return the offset formatted as 
"+HH:MM:SS" or "-HH:MM:SS". I also modified the "wrap_strftime" function to 
also accept the strings "%:z" and "%::z" as format specifiers. This is my first 
contribution to python , so my approach of modifying a function's default 
parameters might not be correct. Any help is appreciated 
Thanks

--
components: +ctypes
hgrepos: +319
keywords: +patch
nosy: +shanmbic
Added file: http://bugs.python.org/file40675/datetime.patch

___
Python tracker 

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

[issue25008] Deprecate smtpd (based on deprecated asyncore/asynchat): write a new smtp server with asyncio

2015-10-04 Thread Barry A. Warsaw


Barry A. Warsaw added the comment:

I'm liking RDM's port of smtpd.py.  I've done some clean ups, bug fixes, and 
added some debugging.  See this branch over on gitlab:

https://gitlab.com/python-smtpd-hackers/aiosmtpd/tree/issue25508

Try `python3 server.py` then run client.py in another terminal (it uses 
smtplib) or just telnet.

I plan to continue pursuing this approach; please comment over there.

--

___
Python tracker 

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

[issue25304] Add run_coroutine_threadsafe() to asyncio

2015-10-04 Thread Guido van Rossum


Guido van Rossum added the comment:

@rdm: thanks, you nailed it. :-)

@yury: but where would you have gotten the awaitable in the first place? It's 
easy to see how to get a coroutine -- just define it (with either @coroutine or 
async def) and call it -- and I think that's the only use case that matters 
here.

I'm unclear how you could have gotten another awaitable (e.g. an asyncio.Future 
instance) in another thread -- except by an utterly confused user.

--

___
Python tracker 

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

[issue25304] Add run_coroutine_threadsafe() to asyncio

2015-10-04 Thread Yury Selivanov


Yury Selivanov added the comment:

> @yury: but where would you have gotten the awaitable in the first place? It's 
> easy to see how to get a coroutine -- just define it (with either @coroutine 
> or async def) and call it -- and I think that's the only use case that 
> matters here.

Just a few days ago Andrew Svetlov raised a question on github -- how could he 
refactor `aiohttp.get()` coroutine to be a coroutine (compatible with coroutine 
ABC) *and* an async context manager.  With my recent commit, `ensure_future()` 
now accepts not just coroutines or futures, but all objects with `__await__`.

So if you have a library with an API exposed through coroutines, it would be 
great if you have some freedom do refactor it and keep it compatible with 
asyncio functions such as `run_coroutine_threadsafe()`

--

___
Python tracker 

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

[issue25314] Documentation: argparse's actions store_{true, false} default to False/True (undocumented)

2015-10-04 Thread Julien Baley


New submission from Julien Baley:

The documentation of the action `store_const` states that it defaults to None. 
In turn, the documentation of `store_true` and `store_false` states that 
"[t]hese are special cases of 'store_const'", suggesting that they would also 
default to None.

Thankfully, `store_true` defaults to False and `store_false` to True, but this 
is not documented. That would be useful, as I keep seeing people writing 
`action='store_true' default=False` and vice-versa.

--
assignee: docs@python
components: Documentation
files: store_true_false_doc.patch
keywords: patch
messages: 252288
nosy: Julien Baley, docs@python
priority: normal
severity: normal
status: open
title: Documentation: argparse's actions store_{true,false} default to 
False/True (undocumented)
type: enhancement
Added file: http://bugs.python.org/file40676/store_true_false_doc.patch

___
Python tracker 

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

[issue25309] askopenfilename crashes on XP with "Show pop-up description for folder and desktop items" on

2015-10-04 Thread Terry J. Reedy

Terry J. Reedy added the comment:

The Windows error, as opposed to Python traceback, is a crash. My machine is
probably too fast even if it did have XP.

Serhiy: 'wish' is not a normal Windows command.

https://social.msdn.microsoft.com/Forums/en-US/2a65c068-4bf7-42ff-94b1-283105d5548d/fatal-errorexception-error-c005?forum=visualfoxprogeneral

says C005 is an
"Exception Error that occurs when a process (application, driver, etc.) tries
to execute a processor command that references memory outside the space
allocated to that process by the Operating System.

There are many possible causes ranging from corrupt data tables, to a bad
network connection, ActiveX controls, or Printer or Video driver errors.
WIthout knowing what type of error you are seeing, it is impossible to guess
what the cause may be."

It can result either from corrupt system files on a particular machine or a bug
in a particular application or a particular use of an application. Searching
'Windows c005 error tcl tk' lead to a stackoverflow answer reporting that
running Tk.mainloop in a non-main thread without a command queue could lead to
this error.

tkinter.filedialog.askopenfilename ends up running tcl command
"tk_getSaveFile". See tkinter.commondialog. Searching "Windows c005
tk_getOpenFile" leads to

http://comp.lang.tcl.narkive.com/miTBmbe1/crash-in-tk-getopenfile
which ends on 2014-11-14 with "fixed in the trunk*. Even in the released 8.6.3
you should see the problem only if you are on a Windows version prior to Vista
AND pass the same string to -typevariable and -filetypes." *8.6.4, delivered
with 3.5.

So until there is a problem with tk 8.6.4+ on Vista+ on more than one machine,
I am going to assume that you either have a bad file on your machine or that
you ran into this known now-fixed tk bug. Hence closing.

--
resolution: -> third party
stage: test needed -> resolved
status: open -> closed
type: behavior -> crash

___
Python tracker

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

[issue25314] Documentation: argparse's actions store_{true, false} default to False/True (undocumented)


R. David Murray added the comment:

There is another issue to fix the documentation for store_const, which does not 
in fact default to anything.  The 'default" in this case is the default for the 
value stored when the option is specified.  So if store_true also implies 
'default=False', that should indeed be documented.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue25314] Documentation: argparse's actions store_{true, false} default to False/True (undocumented)

2015-10-04 Thread Julien Baley


Julien Baley added the comment:

That's true, store_const has no default and will throw an exception if const is 
not provided. Updated the patch consequently.

--
Added file: http://bugs.python.org/file40677/store_const_true_false_doc.patch

___
Python tracker 

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

[issue25314] Documentation: argparse's actions store_{true, false} default to False/True (undocumented)

2015-10-04 Thread Julien Baley


Changes by Julien Baley :


Removed file: http://bugs.python.org/file40676/store_true_false_doc.patch

___
Python tracker 

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

[issue8550] Expose SSL contexts

2015-10-04 Thread Lance Warrior


Changes by Lance Warrior :


Added file: http://bugs.python.org/file40678/entry.tbp

___
Python tracker 

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

[issue25313] IDLE: gracefully handle themes (or keysets, or ...) not present

2015-10-04 Thread Terry J. Reedy


Terry J. Reedy added the comment:

There over-arching issue is that IDLE was not built to allow addition of new 
builtin themes.  IDLE New is currently identical to IDLE Classic, so maybe that 
was intended to allow a revision of IDLE Classic (and I have an idea for that), 
but IDLE Dark is too drastically different to have added it as IDLE New. There 
are two sub-issues here.

1. Theme loading: I experienced the multiple error messages to console behavior 
once, but only once.  This is the 'or worse' in the new message.  I could not 
find out why only once, or know that the same would be true on other machines. 
If possible, there should only be one message. Whether it goes to console or 
messagebox is a different issue, part of revisiting the configure error message 
system.

The first fallback should be to existing and accessible builtins, namely IDLE 
Classic, rather than a default of no colors.  This strikes me as a buggy design.

2. New theme addition and selection: This has to take into account that we 
cannot patch existing releases and that all IDLEs used by one user use the same 
user configuration files.  (There is an issue post that suggests maybe changing 
this, but I cannot find it now.)  This is a minus in that we cannot currently 
restrict selection of IDLE Dark to new IDLEs (but see below).  This is a plus 
in that IDLE Dark can be 'backported' by saving as a custom theme.  We may 
always need some sort of message.

I thought about automatically saving as a custom theme, but besides the 
presumed deadline for 3.4.4 (see below), there are potential problems. A) It is 
magical and potentially confusing enough that I might want a message anyway. B) 
It may not be possible (no writable .idlerc).  I am not sure what happens if 
not. C) If we write with the same name, 'IDLE Dark', then two things have the 
same name but may or may not be identical. (Users could modify the custom 
version of IDLE Dark.)  This is why the interface demands a new name. Your 
patch assumes that they stay identical. D) If we write as a different name, 
users need to be notified anyway.  Might as well let them choose, so they 
remember. E) A custom version is not needed for students in a class with only 
one IDLE on the machine. F) We would have to look at possible interactions with 
other parts of the dialog's behavior.

"See below", time pressure: I though 3.4.4c1 was due out today.  It has not 
appeared, and there have been no pydev messages for 20 hours, since I posted an 
enquiry out the release.  If the release is a week away, we can potentially 
change the patch, though I would want to test very carefully.

"See below", date-specific user config: because all releases after today will 
have IDLE Dark, the needed marker is date rather than version.  Right now, 
selecting 'IDLE Dark' as a built-in theme results in user config-main.cfg 
having this section.

[Theme]
default = True
name = IDLE Dark

Suppose instead the result were

[Theme]
default = True
name2 = IDLE Dark
#or
[Theme]
default = True
name = IDLE New
name2 = IDLE Dark

I tested with 2.7.10 and it starts fine with either of the above, and just as 
important, writes the above when Classic or New are selected if the name2 line 
is there.  I expect the both should be true of all versions that recognize user 
config files, especially the startup part.

The challenge would be to have new IDLEs add the name2 line when IDLE Dark is 
selected and have it replace name with name2 when fetching the name.  The 
message could then be something to the effect of "IDLE Dark only comes with 
IDLE releases in Oct, 2015 and later.  To make it available to older releases, 
save it as a custom theme (with a new name)."

This is a bit clumsy, and would have to be generalized for further theme (but 
YAGNI for now), but would eliminate errors and no color with old versions.  
What do you think?

--

___
Python tracker 

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

[issue25304] Add run_coroutine_threadsafe() to asyncio

2015-10-04 Thread Guido van Rossum


Guido van Rossum added the comment:

Well, I still worry that this is just going to encourage more people to try and 
call awaitables from threaded code, and through some circuitous path of 
misunderstandings (probably involving StackOverflow :-) end up using this 
function.

(Pretty much the worst-case scenario would be calling 
run_coroutine_threadsafe() targeting the *current* loop, and then blocking the 
thread waiting for its result. Deadlock!)

--

___
Python tracker 

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

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()


Martin Panter added the comment:

I added some comments on Rietveld. I guess the documentation should get notices 
and What’s New entries saying it is new in 3.6. Test cases would be good, 
including negative ones to check error handling is sensible if the Z is 
missing. Also shanmbic, perhaps look at signing the contributor agreement 
 if you haven’t already.

Adding to the list of format codes means that the statement at the top of the 
list about them all being required by C89 will need fixing.

For parsing, perhaps the existing %z code could be extended to accept colons, 
without needing to specify a new %:z code. Although if %:z is added for 
formatting, it should also be supported for parsing.

I am not convinced that it is worth adding %::z or %:::z to Python. The 
documentation of tzinfo.utcoffset() says it returns the offset “in minutes”, 
hinting that sub-minute offsets are not supported. RFC 3339 acknowledges that 
sub-minute offsets exist in history, but AFAIK neither RFC 3339 nor ISO 8601 
support them. So I think it is too specialized to build %::z into Python. And I 
don’t imagine the %:::z necessary precision version would be used much either.

--
nosy: +martin.panter
stage: needs patch -> patch review

___
Python tracker 

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

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()


Changes by Martin Panter :


--
components: +Extension Modules -ctypes

___
Python tracker 

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

[issue25311] Add f-string support to tokenize.py


Martin Panter added the comment:

I was just about to make the same bug report :) I guess it would be fine to 
tokenize F-strings as the same string objects as others, it probably just needs 
adding an F to the right regular expression.

$ ./python -btWall -m tokenize
"string"
1,0-1,8:STRING '"string"' 
1,8-1,9:NEWLINE'\n'   
b"string"
3,0-3,9:STRING 'b"string"'
3,9-3,10:   NEWLINE'\n'   
f"string"
4,0-4,1:NAME   'f'
4,1-4,9:STRING '"string"' 
4,9-4,10:   NEWLINE'\n'

--
keywords: +easy
nosy: +martin.panter

___
Python tracker 

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

[issue8550] Expose SSL contexts

2015-10-04 Thread Berker Peksag


Changes by Berker Peksag :


Removed file: http://bugs.python.org/file40678/entry.tbp

___
Python tracker 

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

[issue25315] OrderedDict mangled private attribute is inaccessible

2015-10-04 Thread Serge Matveenko (lig)


New submission from Serge Matveenko (lig):

Consider this code in Python 3.5.0:

Python 3.5.0 (default, Sep 26 2015, 14:59:25) 
[GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import OrderedDict
>>> class MyDict(OrderedDict):
... def __setitem__(self, *args, **kwargs):
... print(self._OrderedDict__root)
... OrderedDict.__setitem__(self, *args, **kwargs)
... 
>>> md = MyDict({'a': 1})
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in __setitem__
AttributeError: 'MyDict' object has no attribute '_OrderedDict__root'


However in Python 3.4:

Python 3.4.2 (default, Jul  9 2015, 17:24:30) 
[GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import OrderedDict
>>> class MyDict(OrderedDict):
... def __setitem__(self, *args, **kwargs):
... print(self._OrderedDict__root)
... OrderedDict.__setitem__(self, *args, **kwargs)
... 
>>> md = MyDict({'a': 1})


--
components: Library (Lib)
messages: 252296
nosy: Serge Matveenko (lig)
priority: normal
severity: normal
status: open
title: OrderedDict mangled private attribute is inaccessible
type: behavior
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

[issue17061] tokenize unconditionally emits NL after comment lines & blank lines


Martin Panter added the comment:

The plain Python shell does respond to lines with only a comment and/or 
horizontal space with a continuation prompt. It only treats completely blank 
lines without any horizontal space specially:

>>> 
... # Indented blank line above; completely blank line below:
... 
>>> 

Meador: The documentation already says what you proposed: “NL tokens are 
generated when a logical line of code is continued over multiple physical 
lines” .

Thomas: It sounds like you actually want to differentiate newlines inside 
bracketed expressions from newlines outside of statements. I think this would 
require a new feature.

Also, I noticed that an escaped continued newline doesn’t seem to generate any 
token at all. Not sure if this is a bug or intended, but it does seem 
inconsistent with the other uses of the NL token.

$ ./python -btWall -m tokenize
1 + \
1,0-1,1:NUMBER '1'
1,2-1,3:OP '+'
1
2,0-2,1:NUMBER '1'
2,1-2,2:NEWLINE'\n'   
3,0-3,0:ENDMARKER  ''

--
nosy: +martin.panter
type: behavior -> enhancement
versions: +Python 3.6 -Python 2.6, Python 2.7, 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

[issue25315] OrderedDict mangled private attribute is inaccessible

2015-10-04 Thread Zachary Ware


Zachary Ware added the comment:

This is a side-effect of 3.5 having a C implementation of OrderedDict, and will 
not be fixed.

In the standard library, even just having a single trailing underscore is a 
clear indication of "if you use this, expect it to break without warning at any 
time."  Mangled names in the standard library are more of an indication of "you 
*really* shouldn't use this".

--
nosy: +eric.snow, zach.ware
resolution:  -> wont fix
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

[issue12486] tokenize module should have a unicode API


Martin Panter added the comment:

I agree it would be very useful to be able to tokenize arbitrary text without 
worrying about encoding tokens. I left some suggestions for the documentation 
changes. Also some test cases for it would be good.

However I wonder if a separate function would be better for the text mode 
tokenization. It would make it clearer when an ENCODING token is expected and 
when it isn’t, and would avoid any confusion about what happens when readline() 
returns a byte string one time and a text string another time. Also, having 
untokenize() changes its output type depending on the ENCODING token seems like 
bad design to me.

Why not just bless the existing generate_tokens() function as a public API, 
perhaps renaming it to something clearer like tokenize_text() or 
tokenize_text_lines() at the same time?

--
nosy: +martin.panter
stage:  -> patch review

___
Python tracker 

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

[issue9969] tokenize: add support for tokenizing 'str' objects


Martin Panter added the comment:

I left some comments. Also, it would be nice to use the new function in the 
documentation example, which currently suggests tunnelling through UTF-8 but 
not adding an encoding comment. And see the patch for Issue 12486, which 
highlights a couple of other places that would benefit from this function.

--
nosy: +martin.panter

___
Python tracker 

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

[issue25313] IDLE: gracefully handle themes (or keysets, or ...) not present


Mark Roseman added the comment:

I see the 3.4.4 is not an immediate concern, so that's good.

FYI, I get the (multiple) error messages on console consistently on Mac, but it 
probably depends how it was launched. Agree the code for future versions should 
do a better job to detect the theme isn't present and switch back to a default 
theme rather than just puking out error messages as it tries to get each 
element of the non-existent theme. :-)

I still think the approach I took may be viable. It doesn't require changes to 
old versions, and relies on the fact that a user theme with the same name as a 
default theme is effectively hidden by the default theme. 

If a 'new' theme is selected, it's always written out to config-highlight, so 
it will be present for older versions (not errors and the internal default 
colors). Given that, I need help understanding what the 'name' vs. 'name2' etc. 
solution gives us?

(Not being able to write .idlerc wouldn't be an issue, because then you 
wouldn't be able to write out the change to say that is the theme to use 
anyway).

The only drawback I see is that a user running a previous version can customize 
IDLE Dark and those changes would not appear when using a newer versions of 
IDLE that had IDLE Dark as a default.

This would negatively affect only those users who change to IDLE Dark, actually 
modify the theme, and switch back and forth between versions of IDLE. The 
consequences of this occurring are only that the changes don't show up. In 
other words, I feel this affects a very tiny number of people, in a relatively 
minor way.

The existing warning on choosing themes will be encountered by anyone who might 
switch themes in the new version, and particularly for the non-hardcore, would 
be at the least surprising if not confusing or alarming. I think it's safe to 
assume that far more people try existing themes vs. create custom themes and 
use multiple versions of IDLE.

Given the very minor consequences and how few people it would affect, vs. how 
many people would encounter that warning and the impression it would leave, 
this seems a case of I'd rather be unobtrusive and 98+% correct then obtrusive 
and 100% correct. 

If it were my product, there's no question I'd drop the warning under those 
circumstances, and if it were a choice between including the warning or not 
including a new theme, I'd personally choose to not include the new theme. 

Anyway, it seems we have time to think more about this...

--

___
Python tracker 

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

[issue15280] Don't use builtins as variable names in urllib.request


Martin Panter added the comment:

The name changes to the function parameters should be avoided without a good 
reason.

I would recommend rejecting all of the changes in this patch. They are 
basically changing one person’s coding style to another person’s style. I 
happen to prefer list() and map() over the list comprehension syntax.

I don’t have a problem with a variable named “type” in a small function. For 
instance, open_unknown() is only four lines, including signature and doc 
string! If you can’t easily predict all the variables in a larger function, 
then I suggest dividing it into smaller components. PEP 8 doesn’t seem to 
mention the issue of shadowing variable names that I can see anyway.

--
nosy: +martin.panter
stage:  -> patch review
type:  -> enhancement

___
Python tracker 

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

[issue9969] tokenize: add support for tokenizing 'str' objects


Martin Panter added the comment:

Actually maybe Issue 12486 is good enough to fix this too. With the patch 
proposed there, tokenize_basestring("source") would just be equivalent to

tokenize(StringIO("source").readline)

--

___
Python tracker 

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

[issue15280] Don't use builtins as variable names in urllib.request


R. David Murray added the comment:

I agree.  The one change that has a non-style motivation (type) is one that 
should not be made for backward compatibility reasons.

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

[issue12486] tokenize module should have a unicode API


Serhiy Storchaka added the comment:

Thank you for your review Martin.

Here is rebased patch that addresses Matin's comments.

I agree that having untokenize() changes its output type depending on the 
ENCODING token is bad design and we should change this. But this is perhaps 
other issue.

--
versions: +Python 3.6 -Python 3.4

___
Python tracker 

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

[issue12486] tokenize module should have a unicode API