[issue10408] Denser dicts and linear probing

[INADA Naoki]

INADA Naoki added the comment:

> - make dicts denser by making the resize factor 2 instead of 4 for small dicts

This had been implemented already when I start compact dict.

> - improve cache locality on collisions by using linear probing

set does this. But dict doesn't do it for now.

In case of compact dict, liner probing only affects index table (dk_indices).
dk_indices is small (64byte when dk_size==64). One or two cache line
can contain whole dk_indices of small dicts.
So performance benefit of linear probing will be smaller than previous
dict implementation.

I'll re-evaluate it.

--

___
Python tracker 

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

[issue28606] Suspected bug in python optimizer with decorators

[R. David Murray]

R. David Murray added the comment:

The statement in question causes the compiler to make 'tags' a local variable 
in the function, and thus you get the error on the assignment.  See 
https://docs.python.org/3/faq/programming.html#id8.

--
nosy: +r.david.murray
resolution:  -> not a bug
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

[issue28605] Remove mention of LTO when referencing --with-optimization in What's New

[STINNER Victor]

STINNER Victor added the comment:

LTO was excluded of --with-optimization by the issue #28032.

--
nosy: +haypo

___
Python tracker 

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

[issue28605] Remove mention of LTO when referencing --with-optimization in What's New

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1f750fff788e by Brett Cannon in branch '3.6':
Issue #28605: Fix the help and What's New entry for --with-optimizations.
https://hg.python.org/cpython/rev/1f750fff788e

New changeset 4000de2dcd24 by Brett Cannon in branch 'default':
Merge for issue #28605
https://hg.python.org/cpython/rev/4000de2dcd24

--
nosy: +python-dev

___
Python tracker 

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

[issue28605] Remove mention of LTO when referencing --with-optimization in What's New

[Brett Cannon]

Changes by Brett Cannon :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue28607] C implementation of parts of copy.deepcopy

[Brett Cannon]

Changes by Brett Cannon :


--
components: +Extension Modules -Library (Lib)
stage:  -> test needed

___
Python tracker 

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

[issue28607] C implementation of parts of copy.deepcopy

[Rasmus Villemoes]

New submission from Rasmus Villemoes:

This is mostly an RFC patch. It compiles and passes the test suite. A somewhat 
silly microbenchmark such as

./python -m timeit -s 'import copy; x = dict([(str(x), x) for x in 
range(1)]);'  'copy.deepcopy(x)'

runs about 30x faster. In the (2.7 only) application which motivated this, the 
part of its initialization that does a lot of deepcopying drops from 11s to 3s. 
That it's so much less is presumably because the application holds on to the 
deepcopies, so there's much more allocation going on than in the 
microbenchmark, but I haven't investigated thoroughly. In any case, a 3.5x 
speedup is also nice.

--
components: Library (Lib)
files: deepcopy.patch
keywords: patch
messages: 280032
nosy: villemoes
priority: normal
severity: normal
status: open
title: C implementation of parts of copy.deepcopy
type: performance
versions: Python 3.7
Added file: http://bugs.python.org/file45344/deepcopy.patch

___
Python tracker 

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

[issue28600] asyncio: Optimize loop.call_soon

[Yury Selivanov]

Yury Selivanov added the comment:

+# Wake up the loop if the finalizer was called from
+# a different thread.
+self._write_to_self()

Yeah, looks like shutdown_asyncgens somehow ended up in 3.5 branch (there's no 
harm in it being there).  I'll sync the branches.

--

___
Python tracker 

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

[issue28600] asyncio: Optimize loop.call_soon

[Guido van Rossum]

Guido van Rossum added the comment:

PS. I noticed there are a few lines different between the "upstream" repo
and the 3.5 stdlib:

+# Wake up the loop if the finalizer was called from
+# a different thread.
+self._write_to_self()

On Thu, Nov 3, 2016 at 3:12 PM, Yury Selivanov 
wrote:

>
> Changes by Yury Selivanov :
>
>
> --
> resolution:  -> fixed
> stage: commit review -> resolved
> status: open -> closed
> type:  -> performance
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions

[Yury Selivanov]

Yury Selivanov added the comment:

> Looks like I forgot about this. My final fix still hasn't been applied, so 
> the code in Py3.4+ is incorrect now.

Left a question in code review

--

___
Python tracker 

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

[issue28604] Exception raised by python3.5 when using en_GB locale

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I suspect this issue is similar to issue25812. en_GB has non-ut8 encoding 
(likely iso8859-1). Currency symbol £ is encoded with this encoding as b'\xa3'. 
But Python tries to decode b'\xa3' with an encoding determined by other locale 
setting (LC_CTYPE).

--
nosy: +lemburg, loewis, serhiy.storchaka
versions: +Python 3.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

[issue28600] asyncio: Optimize loop.call_soon

[Yury Selivanov]

Yury Selivanov added the comment:

Guido, Andrew, thanks for reviews!

I've fixed some unittests before committing the patch.

--

___
Python tracker 

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

[issue28600] asyncio: Optimize loop.call_soon

[Yury Selivanov]

Changes by Yury Selivanov :


--
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
type:  -> performance

___
Python tracker 

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

[issue28600] asyncio: Optimize loop.call_soon

[Roundup Robot]

Roundup Robot added the comment:

New changeset 128ffe3c3eb9 by Yury Selivanov in branch '3.5':
Issue #28600: Optimize loop.call_soon().
https://hg.python.org/cpython/rev/128ffe3c3eb9

New changeset 4f570a612aec by Yury Selivanov in branch '3.6':
Merge 3.5 (issue #28600)
https://hg.python.org/cpython/rev/4f570a612aec

New changeset 46c3eede41a6 by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28600)
https://hg.python.org/cpython/rev/46c3eede41a6

--
nosy: +python-dev

___
Python tracker 

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

[issue28606] Suspected bug in python optimizer with decorators

[Brian Smith]

New submission from Brian Smith:

While using decorators in python 3.5.2, I ran into a surprising bug where the 
decorator sometimes lost context of the outer scope.  The attached file 
demonstrates this problem.

In this file, we have 2 decorators.  They are identical, except that the first 
has one line (at line 11) commented out.

When I run the program, I get the following output:

dev:~/dev/route105/workspace/ir/play$ python bug.py
Trying dec1:
in dec1: {'tags': ['foo:1'], 'name': 'foo'}
inside dec1.decorator: {'tags': {'tags': ['foo:1', ['name:subsystem']], 'name': 
'foo'}, 'func': }

Trying dec2:
in dec2: {'tags': ['foo:1'], 'name': 'foo'}
inside dec2.decorator: {'func': }
Traceback (most recent call last):
  File "bug.py", line 42, in 
@dec2(name="foo", tags=["foo:1"])
  File "bug.py", line 27, in decorator
name = tags["name"]
UnboundLocalError: local variable 'tags' referenced before assignment

There are two issues here:
1) In dec1, the keyword argument 'name' exists in the outer scope, but not in 
the inner scope.  For some reason, the keyword argument 'tags' exists in both 
scopes.

2) In dec2, Adding the line 
 tags=tags["tags"]
causes the keyword argument 'tags' to disappear from the inner scope. 

The only thing I could think of was a compiler or optimizer bug.

--
components: Interpreter Core
files: bug.py
messages: 280025
nosy: Brian Smith
priority: normal
severity: normal
status: open
title: Suspected bug in python optimizer with decorators
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file45343/bug.py

___
Python tracker 

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

[issue28605] Remove mention of LTO when referencing --with-optimization in What's New

[Brett Cannon]

New submission from Brett Cannon:

The What's New doc for Python 3.6 mentions that --with-optimizations turns on 
LTO which is no longer true.

--
assignee: brett.cannon
components: Documentation
messages: 280024
nosy: brett.cannon, gregory.p.smith
priority: deferred blocker
severity: normal
status: open
title: Remove mention of LTO when referencing --with-optimization in What's New
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

[issue28604] Exception raised by python3.5 when using en_GB locale

[Guillaume Pasquet (Etenil)]

New submission from Guillaume Pasquet (Etenil):

This issue was originally reported on Fedora's Bugzilla: 
https://bugzilla.redhat.com/show_bug.cgi?id=1391280

Description of problem:
After switching the monetary locale to en_GB, python then raises an exception 
when calling locale.localeconv()

Version-Release number of selected component (if applicable):
3.5.2-4.fc25

How reproducible:
Every time

Steps to Reproduce:
1. Write a python3 script or open the interactive interpreter with "python3"
2. Enter the following
import locale
locale.setlocale(locale.LC_MONETARY, 'en_GB')
locale.localeconv()
3. Observe that python raises an encoding exception

Actual results:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.5/locale.py", line 110, in localeconv
d = _localeconv()
UnicodeDecodeError: 'locale' codec can't decode byte 0xa3 in position 0: 
Invalid or incomplete multibyte or wide character

Expected results:
A dictionary of locale data similar to (for en_US):
{'mon_thousands_sep': ',', 'currency_symbol': '$', 'negative_sign': '-', 
'p_sep_by_space': 0, 'frac_digits': 2, 'int_frac_digits': 2, 'decimal_point': 
'.', 'mon_decimal_point': '.', 'positive_sign': '', 'p_cs_precedes': 1, 
'p_sign_posn': 1, 'mon_grouping': [3, 3, 0], 'n_cs_precedes': 1, 'n_sign_posn': 
1, 'grouping': [3, 3, 0], 'thousands_sep': ',', 'int_curr_symbol': 'USD ', 
'n_sep_by_space': 0}

Note:
This was reproduced on Linux Mint 18 (python 3.5.2), and also on Fedora with 
python 3.4 and python 3.6 (compiled).

--
components: Interpreter Core
messages: 280023
nosy: Guillaume Pasquet (Etenil)
priority: normal
severity: normal
status: open
title: Exception raised by python3.5 when using en_GB locale
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

[issue28603] traceback module can't format/print unhashable exceptions

[Andreas Stührk]

New submission from Andreas Stührk:

The traceback module tries to handle loops caused by an exception's __cause__ 
or __context__ attributes when printing tracebacks. To do so, it adds already 
seen exceptions to a set. Unfortunately, it doesn't handle unhashable 
exceptions:

>>> class E(Exception): __hash__ = None
...
>>> traceback.print_exception(E, E(), None)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.5/traceback.py", line 100, in print_exception
type(value), value, tb, limit=limit).format(chain=chain):
  File "/usr/lib/python3.5/traceback.py", line 439, in __init__
_seen.add(exc_value)
TypeError: unhashable type: 'E'

CPython's internal exception printing pretty much does the same, except it 
ignores any exception while operating on the seen set (see 
https://hg.python.org/cpython/file/8ee4ed577c03/Python/pythonrun.c#l813 ff).

Attached is a patch that makes the traceback module ignore TypeErrors while 
operating on the seen set. It also adds a (minimal) test.

--
components: Library (Lib)
files: unhashable_exceptions.diff
keywords: patch
messages: 280022
nosy: Trundle
priority: normal
severity: normal
status: open
title: traceback module can't format/print unhashable exceptions
Added file: http://bugs.python.org/file45342/unhashable_exceptions.diff

___
Python tracker 

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

[issue26980] The path argument of asyncio.BaseEventLoop.create_unix_connection is not documented

[Guido van Rossum]

Changes by Guido van Rossum :


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

[issue26980] The path argument of asyncio.BaseEventLoop.create_unix_connection is not documented

[Roundup Robot]

Roundup Robot added the comment:

New changeset b97b0201c2f4 by Guido van Rossum in branch '3.5':
Issue #26980: Improve docs for create_unix_connection(). By Mariatta.
https://hg.python.org/cpython/rev/b97b0201c2f4

New changeset ddbba4739ef4 by Guido van Rossum in branch '3.6':
Issue #26980: Improve docs for create_unix_connection(). By Mariatta. (3.5->3.6)
https://hg.python.org/cpython/rev/ddbba4739ef4

New changeset d6f4c1b864e6 by Guido van Rossum in branch 'default':
Issue #26980: Improve docs for create_unix_connection(). By Mariatta. (3.6->3.7)
https://hg.python.org/cpython/rev/d6f4c1b864e6

--
nosy: +python-dev

___
Python tracker 

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

[issue26980] The path argument of asyncio.BaseEventLoop.create_unix_connection is not documented

[Guido van Rossum]

Guido van Rossum added the comment:

LGTM, will apply shortly.

--

___
Python tracker 

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

[issue28600] asyncio: Optimize loop.call_soon

[Yury Selivanov]

Yury Selivanov added the comment:

> LGTM

Will commit this soon.

> maybe make dirty hack and check hasattr(callback, 'send') ?

If you schedule a coroutine object it will fail anyways, because it's not 
callable.

--

___
Python tracker 

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

[issue28600] asyncio: Optimize loop.call_soon

[Марк Коренберг]

Марк Коренберг added the comment:

> haypo added the check because people called `.call_later()` with coroutine 
> instead of callback very often

maybe make dirty hack and check hasattr(callback, 'send') ?

--
nosy: +mmarkk

___
Python tracker 

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

[issue28600] asyncio: Optimize loop.call_soon

[STINNER Victor]

STINNER Victor added the comment:

call_soon3.patch: LGTM. It enhances error messages (fix the method name) and 
should make asyncio faster.

--

___
Python tracker 

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

[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
type: crash -> behavior
versions: +Python 3.7

___
Python tracker 

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

[issue28600] asyncio: Optimize loop.call_soon

[Ned Deily]

Changes by Ned Deily :


--
stage:  -> commit review

___
Python tracker 

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

[issue28600] asyncio: Optimize loop.call_soon

[Guido van Rossum]

Guido van Rossum added the comment:

Patch 3 LGTM.

--

___
Python tracker 

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

[issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

> I can't think of a single actual downside to this change - all it does is 
> preserve the original behavior of `fromutc()`.

You've got me on the fence here.  If what you are saying is correct, it would 
make sense to make this change and better do it before 3.6 is out, but it would 
take me some effort to convince myself that an implementation that reuses 
patched fromutc() is indeed correct.

Why don't you implement tzrange.fromutc() in terms of say 
tzrange.simple_fromutc() which is your own patched version of tzinfo.fromutc(). 
 If this passes your tests and is simpler than a straightforward fromutc() that 
does not have to look at tzinfo through the needle hole of utcoffset()/dst() 
pair but knows the internals of your timezone object, we can consider promoting 
your simple_fromutc() to default stdlib implementation.

Alternatively, you can just convince Tim. :-)

--

___
Python tracker 

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

[issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation

[Paul G]

Paul G added the comment:

> After all, how much effort would it save for you in dateutil if you could 
> reuse the base class fromutc?

Realistically, this saves me nothing since I have to re-implement it anyway in 
in all versions <= Python 3.6 (basically just the exact same algorithm with 
line 997 replaced with enfold(dt, fold=1) rather than dt.replace(fold=1), but 
I'd rather it fall back to the standard `fromutc()` in fold-aware versions of 
Python 3.6.

That said, I don't see how it's a big can of worms to open. If you're going to 
provide `fromutc()` functionality, it should not be deliberately broken. As I 
mentioned above, I see no actual downside in having `fromutc()` actually work 
as advertised and as intended.

--

___
Python tracker 

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

[issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Paul G at Github:

"""
To be clear, I'm just saying that fromutc() goes from returning something 
meaningful (the correct date and time, with no indication of what side of the 
fold it's on) to something useless (an incorrect date and time) in the case 
where you're on the STD side of the divide. That change would restore the 
original behavior.

For most of the tzinfo implementations I'm providing (tzrange, tzwin, etc), 
there's no problem with an invariant standard time offset, so I'd prefer to 
fall back on the default algorithm in those cases.

Another advantage with using the standard algorithm as a starting point is that 
it all the type checking and such that's done in fromutc is done at that level, 
and I don't have to keep track of handling that.

All that said, it's not a huge deal either way.
"""

Since it is not a big issue for you, I would rather not reopen this can of 
worms.  It may be better to return a clearly erroneous result on fold-aware 
tzinfos to push the developers like you in the right direction. :-)

After all, how much effort would it save for you in dateutil if you could reuse 
the base class fromutc?

--

___
Python tracker 

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

[issue28600] asyncio: Optimize loop.call_soon

[STINNER Victor]

STINNER Victor added the comment:

I didn't review the patch, but I agree with the overall approach: expensive
checks can be made only in debug mode.

If people are concerned by the removal of the check by default, we should
repeat everywhere in the doc that async programming is hard and that the
debug mode saves a lot of time ;-)

--

___
Python tracker 

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

[issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation

[Paul G]

Paul G added the comment:

Of the `tzinfo` implementations provided by `python-dateutil`, `tzrange`, 
`tzstr` (GNU TZ strings), `tzwin` (Windows style time zones) and `tzlocal` all 
satisfy this condition. These are basically all implementations of default 
system time zone information.

With current implementations `tzfile` and `tzical` also use the invariant 
algorithm, though theoretically there are edge cases where this will cause 
problems, and those should have their `fromutc()` adjusted.

In any case, I can't think of a single actual downside to this change - all it 
does is preserve the original behavior of `fromutc()`. As currently 
implemented, the algorithm is simply wrong when `dst()` is affected by `fold`, 
and this change would have no effect on zones where `dst()` is *not* affected 
by fold.

--

___
Python tracker 

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

[issue10408] Denser dicts and linear probing

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

What is the status of this issue in the light of compact dict implementation?

--
nosy: +inada.naoki

___
Python tracker 

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

[issue28600] asyncio: Optimize loop.call_soon

[Yury Selivanov]

Changes by Yury Selivanov :


Added file: http://bugs.python.org/file45341/call_soon3.patch

___
Python tracker 

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

[issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

I don't think timezones that satisfy the invariant expected by the default  
fromutc() is common enough that we need to provide special support for them.  
Note that in most cases it is the UTC to local conversion that is 
straightforward while Local to UTC is tricky, so the code that reduces a simple 
task to a harder one has questionable utility.

--
assignee:  -> belopolsky
type: behavior -> enhancement

___
Python tracker 

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

[issue28600] asyncio: Optimize loop.call_soon

[Yury Selivanov]

Changes by Yury Selivanov :


Added file: http://bugs.python.org/file45340/call_soon2.patch

___
Python tracker 

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

[issue25264] test_marshal always crashs on "AMD64 Windows10 2.7" buildbot

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Crashes seems was fixed in issue22734 and issue27019.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> marshal needs a lower stack depth for debug builds on Windows

___
Python tracker 

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

[issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation

[Paul G]

New submission from Paul G:

After PEP-495, the default value for non-fold-aware datetimes is that they 
return the DST side, not the STD side (as was the assumption before PEP-495). 
This invalidates an assumption made in `tz.fromutc()`. See lines 991-1000 of 
datetime.py:

dtdst = dt.dst()
if dtdst is None:
raise ValueError("fromutc() requires a non-None dst() result")
delta = dtoff - dtdst
if delta:
dt += delta
dtdst = dt.dst()
if dtdst is None:
raise ValueError("fromutc(): dt.dst gave inconsistent "
 "results; cannot convert")

Line 997 
(https://github.com/python/cpython/blob/be8de928e5d2f1cd4d4c9c3e6545b170f2b02f1b/Lib/datetime.py#L997)
 assumes that an ambiguous datetime will return the STD side, not the DST side, 
and as a result, if you feed it a date in UTC that should resolve to the STD 
side, it will actually return 1 hour (or whatever the DST offset is) AFTER the 
ambiguous date that should be returned.

If 997 is changed to:

dtdst = dt.replace(fold=1).dst()

That will not affect fold-naive zones (which are instructed to ignore the 
`fold` parameter) and restore the original behavior. This will allow fold-aware 
timezones to be implemented as a wrapper around `fromutc()` rather than a 
complete re-implementation, e.g.:

class FoldAwareTzInfo(datetime.tzinfo):
def fromutc(self, dt):
dt_wall = super(FoldAwareTzInfo, self).fromutc(dt)

is_fold = self._get_fold_status(dt, dt_wall)

return dt_wall.replace(fold=is_fold)

--
messages: 280007
nosy: belopolsky, p-ganssle, tim.peters
priority: normal
severity: normal
status: open
title: `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation
type: behavior
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue28600] asyncio: Optimize loop.call_soon

[Yury Selivanov]

Yury Selivanov added the comment:

> IIRC haypo added the check because people called `.call_later()` with 
> coroutine instead of callback very often.

We'll update asyncio docs in 3.6 with a tutorial to focus on coroutines (not on 
low-level event loop).  This should leave the loop API to advanced users.

> But checking in debug mode looks very reasonable to me if it is so expensive.

Exactly.

--

___
Python tracker 

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

[issue28601] Ambiguous datetime comparisons should use == rather than 'is' for tzinfo comparison

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

See Datetime-SIG thread 
.

--
assignee:  -> belopolsky
nosy: +tim.peters
stage:  -> needs patch

___
Python tracker 

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

[issue28601] Ambiguous datetime comparisons should use == rather than 'is' for tzinfo comparison

[Paul G]

New submission from Paul G:

According to PEP495 
(https://www.python.org/dev/peps/pep-0495/#aware-datetime-equality-comparison) 
datetimes are considered not equal if they are an ambiguous time and have 
different zones. However, currently "interzone comparison" is defined / 
implemented as the zones being the same object rather than the zones comparing 
equal.

One issue with this is that it actually breaks backwards compatibility of the 
language, because there doesn't seem to be a way to provide a 
(backwards-compatible) class that implements folding behavior and has 
equivalent dates compare equal. An example using python-dateutil:

```
from datetime import datetime
from dateutil import tz

NYC = tz.gettz('America/New_York')
ET = tz.gettz('US/Eastern')

dt = datetime(2011, 11, 6, 5, 30, tzinfo=tz.tzutc()) # This is 2011-11-06 01:30 
EDT-4

dt_edt = dt.astimezone(ET)
dt_nyc = dt.astimezone(NYC)

print(dt_nyc == dt_edt)
```

In Python 3.5 that will return True, in Python 3.6 it will return False, even 
though 'US/Eastern' and 'America/New_York' are the same zone. In this case, I 
might be able to enforce that these time zones are singletons so that `is` 
always returns True (though this may have other negative consequences for 
utility), but even that solution would fall apart for things like `tzrange` and 
`tzstr`, where you can know that the `dt.utcoffset()`s are going to be 
identical for ALL values of `dt`, but you can't force the objects to be 
identical.

I would suggest that it be changed to use `__eq__` to determine whether two 
`tzinfo` objects are the same zone, as this will allow tzinfo providers to 
create `tzinfo` objects with a consistent behavior between versions in this 
edge case.

--
components: Library (Lib)
messages: 280003
nosy: belopolsky, p-ganssle
priority: normal
severity: normal
status: open
title: Ambiguous datetime comparisons should use == rather than 'is' for tzinfo 
comparison
type: behavior
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue28600] asyncio: Optimize loop.call_soon

[Andrew Svetlov]

Andrew Svetlov added the comment:

The patch looks good.
IIRC haypo added the check because people called `.call_later()` with coroutine 
instead of callback very often.

But checking in debug mode looks very reasonable to me if it is so expensive.

--

___
Python tracker 

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

[issue28600] asyncio: Optimize loop.call_soon

[Yury Selivanov]

Changes by Yury Selivanov :


--
keywords: +patch
Added file: http://bugs.python.org/file45339/call_soon.patch

___
Python tracker 

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

[issue28600] asyncio: Optimize loop.call_soon

[Yury Selivanov]

New submission from Yury Selivanov:

loop.call_soon is the central function of asyncio.  Everything goes through it.

Current design of asyncio.loop.call_soon makes the following checks:

1. [debug mode] check that the loop is not closed
2. [debug mode] check that we are calling call_soon from the proper thread
3. [always] check that callback is not a coroutine or a coroutine function

Check #3 is very expensive, because it uses an 'isinstance' check.  Moreover, 
isinstance checks against an ABC, which makes the call even slower.

Attached patch makes check #3 optional and run only in debug mode.  This is a 
very safe patch to merge.

This makes asyncio another 17% (sic!) faster.  In fact it becomes as fast as 
curio for realistic streams benchmarks.

--
assignee: yselivanov
components: asyncio
messages: 280002
nosy: asvetlov, gvanrossum, haypo, inada.naoki, ned.deily, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: Optimize loop.call_soon
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue28598] RHS not consulted in `str % subclass_of_str` case.

[Martijn Pieters]

Martijn Pieters added the comment:

Here's a proposed patch for tip; what versions would it be worth backporting 
this to?

(Note, there's no NEWS update in this patch).

--
keywords: +patch
Added file: http://bugs.python.org/file45338/issue28598.patch

___
Python tracker 

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

[issue25652] collections.UserString.__rmod__() raises NameError

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Issue28598 may be related.

--

___
Python tracker 

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

[issue28599] AboutDialog set_name is ignored

[Zachary Ware]

Changes by Zachary Ware :


--
resolution: not a bug -> third party

___
Python tracker 

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

[issue25251] Unknown MS Compiler version 1900

[Steve Dower]

Steve Dower added the comment:

That sounds like a great feature for setuptools.

Core distutils is highly focused on what is needed for the core product, and we 
are very much trying to avoid bloating it, whereas setuptools is free to add 
extensions wherever necessary and make them available on earlier versions of 
Python.

The setuptools issue tracker is at https://github.com/pypa/setuptools

--

___
Python tracker 

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

[issue28599] AboutDialog set_name is ignored

[Zachary Ware]

Zachary Ware added the comment:

That appears to be an issue with the third-party PyGObject project, please open 
an issue on the PyGObject issue tracker: 
https://bugzilla.gnome.org/page.cgi?id=browse.html=pygobject

--
nosy: +zach.ware
resolution:  -> not a bug
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

[issue28599] AboutDialog set_name is ignored

[rebelxt]

New submission from rebelxt:

Python 3.5.2 (default, Sep 10 2016, 08:21:44) [GCC 5.4.0 20160609] on linux 
Mint 18 and Gtk 3.

I run a python3 script that includes these statements:

import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk, GObject
aboutdialog = Gtk.AboutDialog()
aboutdialog.set_name('arbitrary')
aboutdialog.run()
aboutdialog.destroy()

The script name is displayed in the About dialog, while the 'arbitrary' name is 
ignored. This is inconsistent with python2/gtk2. If the set_name 
method/function exists, it should do something.

I have no way of testing this on any later version of python.

--
messages: 279998
nosy: rebelxt
priority: normal
severity: normal
status: open
title: AboutDialog set_name is ignored
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

[issue28598] RHS not consulted in `str % subclass_of_str` case.

[Xiang Zhang]

Changes by Xiang Zhang :


--
nosy: +xiang.zhang

___
Python tracker 

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

[issue28123] _PyDict_GetItem_KnownHash ignores DKIX_ERROR return

[INADA Naoki]

INADA Naoki added the comment:

LGTM.

--

___
Python tracker 

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

[issue28494] is_zipfile false positives

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka

___
Python tracker 

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

[issue28597] f-string behavior is conflicting with its documentation

[Eric V. Smith]

Eric V. Smith added the comment:

This is a duplicate of issue 28590.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> fstring's '{' from escape sequences does not start an expression

___
Python tracker 

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

[issue28597] f-string behavior is conflicting with its documentation

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> docs@python
components: +Documentation -Interpreter Core
nosy: +docs@python, eric.smith
type:  -> behavior
versions: +Python 3.7

___
Python tracker 

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

[issue28387] double free in io.TextIOWrapper

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue28387] double free in io.TextIOWrapper

[Roundup Robot]

Roundup Robot added the comment:

New changeset 91f024fc9b3a by Serhiy Storchaka in branch '2.7':
Issue #28387: Fixed possible crash in _io.TextIOWrapper deallocator when
https://hg.python.org/cpython/rev/91f024fc9b3a

New changeset 89f7386104e2 by Serhiy Storchaka in branch '3.5':
Issue #28387: Fixed possible crash in _io.TextIOWrapper deallocator when
https://hg.python.org/cpython/rev/89f7386104e2

New changeset c4319c0d0131 by Serhiy Storchaka in branch '3.6':
Issue #28387: Fixed possible crash in _io.TextIOWrapper deallocator when
https://hg.python.org/cpython/rev/c4319c0d0131

New changeset 36af3566b67a by Serhiy Storchaka in branch 'default':
Issue #28387: Fixed possible crash in _io.TextIOWrapper deallocator when
https://hg.python.org/cpython/rev/36af3566b67a

--
nosy: +python-dev

___
Python tracker 

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

[issue28598] RHS not consulted in `str % subclass_of_str` case.

[Martijn Pieters]

New submission from Martijn Pieters:

The `BINARY_MODULO` operator hardcodes a test for `PyUnicode`:

TARGET(BINARY_MODULO) {
PyObject *divisor = POP();
PyObject *dividend = TOP();
PyObject *res = PyUnicode_CheckExact(dividend) ?
PyUnicode_Format(dividend, divisor) :
PyNumber_Remainder(dividend, divisor);

This means that a RHS subclass of str can't override the operator:

>>> class Foo(str):
... def __rmod__(self, other):
... return self % other
...
>>> "Bar: %s" % Foo("Foo: %s")
'Bar: Foo %s'

The expected output there is "Foo: Bar %s".

This works correctly for `bytes`:

>>> class FooBytes(bytes):
... def __rmod__(self, other):
... return self % other
...
>>> b"Bar: %s" % FooBytes(b"Foo: %s")
b'Foo: Bar: %s'

and for all other types where the RHS is a subclass.

Perhaps there should be a test to see if `divisor` is a subclass, and in that 
case take the slow path?

--
components: Interpreter Core
messages: 279993
nosy: mjpieters
priority: normal
severity: normal
status: open
title: RHS not consulted in `str % subclass_of_str` case.
type: behavior
versions: Python 2.7, Python 3.3, 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

[issue28597] f-string behavior is conflicting with its documentation

[Fabio Zadrozny]

New submission from Fabio Zadrozny:

The file:

/Doc/reference/lexical_analysis.rst says that things as:

f"abc {a[\"x\"]} def"  # workaround: escape the inner quotes
f"newline: {ord('\\n')}"  # workaround: double escaping
fr"newline: {ord('\n')}"  # workaround: raw outer string

are accepted in f-strings, yet, all those examples raise a:

SyntaxError: f-string expression part cannot include a backslash

The current Python version where this was tested is: 3.6.0b4

So, either those cases should be supported or lexical_analysis.rst should be 
updated to say that '\' is not valid in the expression part of f-strings.

--
components: Interpreter Core
messages: 279992
nosy: fabioz
priority: normal
severity: normal
status: open
title: f-string behavior is conflicting with its documentation
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

[issue28123] _PyDict_GetItem_KnownHash ignores DKIX_ERROR return

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

LGTM. I'll commit the patch soon if there are no comments from other core 
developers.

--
stage: patch review -> commit review

___
Python tracker 

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

[issue28498] tk busy command

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Updated patch skips tests with the cursor option on OSX/Aqua.

--
Added file: http://bugs.python.org/file45337/tk_busy_6.diff

___
Python tracker 

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

[issue23262] webbrowser module broken with Firefox 36+

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I don't understand with what you disagree. I can imagine old Python 2.7 with 
old browser, old Python 2.7 with new browser, new Python 2.7 with new browser, 
and even new Python 2.7 with old browser on the same computer (but the latter 
is very unlikely).

Old Python 2.7 don't work with new browser and we can't do anything with this. 
We can make new Python 2.7.12 working with new browser. But I'm not sure that 
we can break the compatibility with old browser that could be installed when 
Python 2.7 was first installed on the same computer.

--

___
Python tracker 

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

[issue27779] Sync-up docstrings in C version of the the decimal module

[Stefan Krah]

Changes by Stefan Krah :


--
keywords:  -easy, patch

___
Python tracker 

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

[issue27779] Sync-up docstrings in C version of the the decimal module

[Stefan Krah]

Changes by Stefan Krah :


--
keywords: +patch

___
Python tracker 

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

[issue27779] Sync-up docstrings in C version of the the decimal module

[Stefan Krah]

Stefan Krah added the comment:

Okay great.  I think it's probably best to produce an initial patch with the 
verbatim Python docstrings (you can of course address the comments that I 
already made), then we mark the passages that are clearly not valid for 
_decimal or outdated for _pydecimal, then we go for extra clarity.

--

___
Python tracker 

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

[issue28123] _PyDict_GetItem_KnownHash ignores DKIX_ERROR return

[Xiang Zhang]

Xiang Zhang added the comment:

> If _PyDict_GetItem_KnownHash() returns an error, it is very likely that 
> following insertdict() with same key will return an error.

Make sense.

--
assignee: haypo -> serhiy.storchaka
Added file: http://bugs.python.org/file45336/issue28123_v6.patch

___
Python tracker 

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

[issue28385] Bytes objects should reject all formatting codes with an error message

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The proposition of making default __format__ equivalent to str() will be 
addressed in separate issue. Python-Dev thread: 
https://mail.python.org/pipermail/python-dev/2016-October/146765.html.

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

[issue28123] _PyDict_GetItem_KnownHash ignores DKIX_ERROR return

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

If _PyDict_GetItem_KnownHash() returns an error, it is very likely that 
following insertdict() with same key will return an error. I would prefer to 
return an error right after _PyDict_GetItem_KnownHash() is failed. This would 
look more straightforward.

--

___
Python tracker 

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

[issue26935] android: test_os fails

[Xavier de Gaye]

Xavier de Gaye added the comment:

This new patch takes into account Martin comment in msg265099 and fixes a call 
to getpwall() as Android does not have getpwall().

--
assignee:  -> xdegaye
stage: patch review -> commit review
versions: +Python 3.7
Added file: http://bugs.python.org/file45335/test_urandom_fd_reopened_2.patch

___
Python tracker 

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

[issue26865] Meta-issue: support of the android platform

[Xavier de Gaye]

Xavier de Gaye added the comment:

issue #28596: on Android _bootlocale on startup relies on too many library 
modules

--
dependencies: +on Android _bootlocale on startup relies on too many library 
modules

___
Python tracker 

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

[issue26928] _bootlocale imports locale at startup on Android, causing test_site to fail

[Xavier de Gaye]

Xavier de Gaye added the comment:

This patch fixes test_startup_imports when the platform does not have 
langinfo.h.

Entered new issue 28596: "on Android _bootlocale on startup relies on too many 
library modules".

--
assignee:  -> xdegaye
components: +Tests -Cross-Build, Library (Lib)
stage:  -> patch review
versions: +Python 3.7
Added file: http://bugs.python.org/file45334/skip_test.patch

___
Python tracker 

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

[issue28596] on Android _bootlocale on startup relies on too many library modules

[Xavier de Gaye]

New submission from Xavier de Gaye:

Android does not have langinfo.h and this results in _bootlocale importing 
locale on startup (see issue 26928).

IMHO it is not acceptable to fallback to locale.py if CODESET is not available 
(in answer to Victor question in msg199367), because there are now two code 
paths to investigate weird bugs such as the one described by Antoine in issue 
9548. Also note that Android platforms have a slow processor and limited RAM 
size, so they would strongly benefit from a startup sequence avoiding the 
imports made by the locale module. Since there is already a _bootlocale module, 
what are now the objections to implement the patch Antoine has proposed in 
issue 9548 ?

Nosying people from issue 9548.

--
components: Interpreter Core
messages: 279981
nosy: Arfrever, barry, benjamin.peterson, brett.cannon, christian.heimes, 
eric.araujo, eric.snow, flox, haypo, lemburg, mark.dickinson, ncoghlan, 
orsenthil, pitrou, python-dev, rhettinger, xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: on Android _bootlocale on startup relies on too many library modules
type: behavior
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue28595] shlex.split should not augment wordchars

[Evan]

New submission from Evan:

The changes to shlex due to land in 3.6 use a predefined set of characters to 
"augment" wordchars, however this set is incomplete. For example, 'foo,bar' 
should be parsed as a single token, but it is split on the comma:

$ echo foo,bar
foo,bar

>>> import shlex
>>> list(shlex.shlex('foo,bar', punctuation_chars=True))
['foo', ',', 'bar']

(For context on where this was encountered, see 
https://github.com/kislyuk/argcomplete/issues/161)

Instead of trying to enumerate all possible wordchars, I think a more robust 
solution is to use whitespace_split to include *all* characters not otherwise 
considered special.

Ideally this would be fixed before 3.6 is released to avoid needing to maintain 
backwards compatibility with the current behaviour, although I understand the 
timeline may make this difficult.

I've attached a patch with proposed changes, including updates to the tests to 
demonstrate the effective difference. I can make the corresponding 
documentation changes if we want this merged.

(I've added everyone to the nosy list from http://bugs.python.org/issue1521950 
where these changes originated.)

--
components: Library (Lib)
files: without_augmenting_chars.diff
keywords: patch
messages: 279980
nosy: Andrey.Kislyuk, cvrebert, eric.araujo, eric.smith, evan_, ezio.melotti, 
python-dev, r.david.murray, robodan, vinay.sajip
priority: normal
severity: normal
status: open
title: shlex.split should not augment wordchars
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file45333/without_augmenting_chars.diff

___
Python tracker 

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

[issue28594] List define and Change result

[saeed]

saeed added the comment:

OK,
I found My problem, 
Thank so much,

There is any way to define them shortly??

--

___
Python tracker 

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

[issue25677] Syntax error caret confused by indentation

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

LGTM.

--
stage: patch review -> commit review
versions: +Python 3.7

___
Python tracker 

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

[issue28580] Optimize iterating split table values

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

v4 LGTM.

--

___
Python tracker 

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

[issue28580] Optimize iterating split table values

[Xiang Zhang]

Changes by Xiang Zhang :


Added file: http://bugs.python.org/file45332/iterate_splittable_v4.patch

___
Python tracker 

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

[issue28594] List define and Change result

[Xiang Zhang]

Xiang Zhang added the comment:

In your last example, after x=y=[], you reassign a new list to y, so x and y 
are different. In your my.py, you are altering the same list. Please read the 
link Martin gives.

--
nosy: +xiang.zhang
status: open -> closed

___
Python tracker 

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

[issue28580] Optimize iterating split table values

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

In current code there is no UB in _PyDict_Next().

--

___
Python tracker 

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

[issue25251] Unknown MS Compiler version 1900

[Sam Miller]

Sam Miller added the comment:

Hi disutils. I got this bug when trying to pip install pomegranate to python 
3.5. There is now a m2w64-toolchain 
(https://github.com/ContinuumIO/anaconda-issues/issues/561)that allows 
installing the notoriously windows-challenged theano, so I thought this error 
could be resolved with a new class m2w64Compiler(CygwinCCompiler) or maybe just 
updating the old Mingw32CCompiler(CygwinCCompiler) class.

--
nosy: +Sam Miller

___
Python tracker 

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

[issue28580] Optimize iterating split table values

[Xiang Zhang]

Xiang Zhang added the comment:

> I would suggest just remove assert() from your patch and address undefined 
> behavior in other issue.

That's what v2 does. If there is another issue, let's also leave _PyDict_Next 
to it.

--

___
Python tracker 

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

[issue28594] List define and Change result

[saeed]

Changes by saeed :


--
status: closed -> open

___
Python tracker 

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

[issue28594] List define and Change result

[saeed]

saeed added the comment:

Thank for attention,but see this:

>>> x=y=[]
>>> x=y=[0]*3
>>> x
[0, 0, 0]
>>> y
[0, 0, 0]
>>> y=[0, 1, 1]
>>> x
[0, 0, 0]
>>> y
[0, 1, 1]
>>> y[1]+=1
>>> y
[0, 2, 1]
>>> x
[0, 0, 0]
>>> x[0]+=5
>>> x
[5, 0, 0]
>>> y
[0, 2, 1]

then must my code work and there is another problem :/

*

notice: I don't write like this: 
>>> x=[]
>>> y=x

--

___
Python tracker 

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

[issue28580] Optimize iterating split table values

[Xiang Zhang]

Xiang Zhang added the comment:

Currently dict iterator does not allow size changed during iteration. This is 
more strict than list iterator but still allow modification during iteration. 
Maybe we could deny all modification by checking dict->ma_version_tag. But 
that's irrelevant to this issue.

Serhiy, this means the iternext* functions all get UB. These codes existed even 
in 3.3. Do we really need to eliminate them now?

--

___
Python tracker 

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

[issue28580] Optimize iterating split table values

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

It is appropriate if iterating modifying dict raises RuntimeError, produces 
less items or even produce some items multiple times. What is not appropriate 
-- crash, hang and infinite iteration. There was a proposition about making 
this behavior more consistent (issue19332), but it was rejected.

I would suggest just remove assert() from your patch and address undefined 
behavior in other issue.

--

___
Python tracker 

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

[issue28594] List define and Change result

[Martin Panter]

Martin Panter added the comment:

I haven’t looked at your code, but I think you may have misunderstood how 
variable assignments work in Python. See 
.

When you assign an object such as [0, 0] to a variable name, the name is 
“bound” to the object. When you assign to a second name, the second name is 
bound to exactly the same object. When you alter the object through one name, 
the change is visible from any of the bound names.

Closing this, but let me know if I got it wrong.

--
nosy: +martin.panter
resolution:  -> 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

[issue28580] Optimize iterating split table values

[Xiang Zhang]

Xiang Zhang added the comment:

Hmm, the resolution could be simple. But how about

>>> d = dict.fromkeys(range(100))
>>> for k in range(98):
... del d[k]
... 
>>> it = iter(d)
>>> next(it)
98
>>> d.clear()
>>> d[0] = 1
>>> d[1] = 2
>>> next(it)
Traceback (most recent call last):
  File "", line 1, in 
StopIteration

Actually we haven't exhaust the dict yet. Is it reasonable for me to expect the 
second next returning 0? I actually mean is it reasonable for me to expect 
len(dict) elements returned before StopIteration raised even if the dict is 
changed?

--

___
Python tracker 

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

[issue28594] List define and Change result

[saeed]

New submission from saeed:

Hi,
I define multi List in a line such as this:
smoke= exercise  = cholesterol = angina = stroke = attack = [0] * 2
and This work bad!
if I define later line such this, problem has been solve:
smoke=[0]*2
exercise  = [0]*2
cholesterol = [0]*2
angina = [0]*2
stroke = [0]*2

I just change this line in my project but result changed!

Is this a bug?

*
*

notice to "Smoke" change in follow,
"Smoke" changed from [0, 1] to [0 ,6] in a one state, for what??!!

*
out put before change:

> $ python3.5 ./my.py
smoke=  [0, 0]
  before income: [0, 0, 0, 0, 0, 0, 0, 0]
income[ 5 ] += 1   after income: [0, 0, 0, 0, 0, 1, 0, 0]
  before smoke: [0, 0]
2
smoke[ 1 ] += 1   after smoke: [0, 1]
stop in step
  before income: [0, 0, 0, 0, 0, 1, 0, 0]
income[ 1 ] += 1   after income: [0, 1, 0, 0, 0, 1, 0, 0]
  before smoke: [0, 6]
2
smoke[ 1 ] += 1   after smoke: [0, 7]
stop in step
  before income: [0, 1, 0, 0, 0, 1, 0, 0]
income[ 5 ] += 1   after income: [0, 1, 0, 0, 0, 2, 0, 0]
  before smoke: [2, 10]
1
smoke[ 0 ] += 1   after smoke: [3, 10]
stop in step   

*

out put after change:
>$ python3.5 my1.py 
smoke=  [0, 0]
  before income: [0, 0, 0, 0, 0, 0, 0, 0]
income[ 5 ] += 1   after income: [0, 0, 0, 0, 0, 1, 0, 0]
  before smoke: [0, 0]
2
smoke[ 1 ] += 1   after smoke: [0, 1]
stop in step
  before income: [0, 0, 0, 0, 0, 1, 0, 0]
income[ 1 ] += 1   after income: [0, 1, 0, 0, 0, 1, 0, 0]
  before smoke: [0, 1]
2
smoke[ 1 ] += 1   after smoke: [0, 2]
stop in step
  before income: [0, 1, 0, 0, 0, 1, 0, 0]
income[ 5 ] += 1   after income: [0, 1, 0, 0, 0, 2, 0, 0]
  before smoke: [0, 2]
1
smoke[ 0 ] += 1   after smoke: [1, 2]
stop in step

*

:/

Thanks

--
files: my.tar.7z
messages: 279967
nosy: ezio.melotti, saeed
priority: normal
severity: normal
status: open
title: List define and Change result
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file45331/my.tar.7z

___
Python tracker 

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

[issue28580] Optimize iterating split table values

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Following example causes a crash in debug build:

d = dict.fromkeys(range(100))
for k in range(99):
del d[k]

it = iter(d)
assert next(it) == 99
d.clear()
d[0] = None
next(it)

--

___
Python tracker 

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