[issue31196] Blank line inconsistency between InteractiveConsole and standard interpreter

[Tom Viner]

Changes by Tom Viner :


--
nosy: +tomviner

___
Python tracker 

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

[issue31193] re.IGNORECASE strips combining character from lower case of LATIN CAPITAL LETTER I WITH DOT ABOVE

[Tom Viner]

Changes by Tom Viner :


--
nosy: +tomviner

___
Python tracker 

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

[issue26669] time.localtime(float("NaN")) does not raise a ValueError on all platforms

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +3127

___
Python tracker 

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

[issue31159] Doc: Language switch can't switch on specific cases

[STINNER Victor]

STINNER Victor added the comment:

To choose the langague, see what Wikipedia does: Wikipedia EN displays
"Français", no?

--

___
Python tracker 

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

[issue31149] Add Japanese to the language switcher

[STINNER Victor]

STINNER Victor added the comment:


New changeset fe8d9dc479a96ef490034107e7d4a6228b4be140 by Victor Stinner 
(Julien Palard) in branch '2.7':
bpo-31159: fix language switch regex on unknown yet built languages. … (#3051) 
(#3081)
https://github.com/python/cpython/commit/fe8d9dc479a96ef490034107e7d4a6228b4be140


--

___
Python tracker 

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

[issue31159] Doc: Language switch can't switch on specific cases

[STINNER Victor]

STINNER Victor added the comment:


New changeset fe8d9dc479a96ef490034107e7d4a6228b4be140 by Victor Stinner 
(Julien Palard) in branch '2.7':
bpo-31159: fix language switch regex on unknown yet built languages. … (#3051) 
(#3081)
https://github.com/python/cpython/commit/fe8d9dc479a96ef490034107e7d4a6228b4be140


--

___
Python tracker 

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

[issue31196] Blank line inconsistency between InteractiveConsole and standard interpreter

[Malcolm Smith]

New submission from Malcolm Smith:

The standard interpreter is more eager to give an error on incomplete input, 
while the InteractiveConsole will keep on prompting for more:

Python 3.5.3 (default, Apr 10 2017, 07:53:16)  [GCC 6.3.0 64 bit (AMD64)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> try:
...
  File "", line 2

^
IndentationError: expected an indented block
>>> import code
>>> code.interact()
Python 3.5.3 (default, Apr 10 2017, 07:53:16)  [GCC 6.3.0 64 bit (AMD64)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> try:
...
...
...
...

The InteractiveConsole isn't totally wrong here, because after all, a blank 
line in this position is syntactically correct. But the inconsistency is 
confusing.

--
components: Library (Lib)
messages: 300230
nosy: Malcolm Smith
priority: normal
severity: normal
status: open
title: Blank line inconsistency between InteractiveConsole and standard 
interpreter
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

[issue31158] test_pty: test_basic() fails randomly on Travis CI

[Xavier de Gaye]

Changes by Xavier de Gaye :


--
nosy: +xdegaye

___
Python tracker 

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

[issue31182] Suggested Enhancements to zipfile & tarfile command line interfaces

[Steve Barnes]

Changes by Steve Barnes :


--
pull_requests: +3126

___
Python tracker 

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

[issue31147] a suboptimal check in list_extend()

[Oren Milman]

Oren Milman added the comment:

thank you for the elaborate reply :)

do you feel the same about changing the check to
(Py_SIZE(self) < (self->allocated >> 1)) ?

--

___
Python tracker 

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

[issue31186] Support heapfix() and heapremove() APIs in heapq module

[Rajath Agasthya]

Rajath Agasthya added the comment:

And yes, both of these methods do take index as the argument as shown in my 
patch file. I should've probably specified that. 

The signatures are:

heapfix(heap, pos)
heapremove(heap, pos)

--

___
Python tracker 

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

[issue31186] Support heapfix() and heapremove() APIs in heapq module

[Rajath Agasthya]

Rajath Agasthya added the comment:

> The only hacks around that I could think of required a more complex kind of 
> heap; e.g., restricting heap items to objects usable as dict keys, using a 
> hidden dict to map heap items to their current index, and fiddling all the 
> heap operations to keep that dict up to date.

Actually, this is *exactly* how I ended up thinking about this feature. I was 
using a separate dict to track the index at which objects are inserted in a 
heap, using the index to make updates to heap directly, and fixing the heap by 
calling heapify() every time which was slightly costly. Maybe I chose the wrong 
data structure for the problem, but constant time getMin() operation was 
crucial for me. And I didn't really care if inserts (or updates) were costlier. 

But I completely agree that it's a niche use case and I understand if we don't 
want to support this :)

--

___
Python tracker 

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

[issue31195] Make any() and all() work with async generators

[Yury Selivanov]

Yury Selivanov added the comment:

> Or am I missing something subtle here?

We'll need to make any() and all() coroutines.  Not simple coroutines though, 
but weird "hybrid" functions that preserve the old semantics + implement async 
stuff.

I don't think this is a very good idea.  Maybe we should think about 
"asyncitertools" package with functions like "anext", "aiter", "async_all", 
"async_chain", etc.

--

___
Python tracker 

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

[issue31186] Support heapfix() and heapremove() APIs in heapq module

[Tim Peters]

Tim Peters added the comment:

@Rajath, I suspect Raymond may have been bamboozled because your suggested 
`heapfix()` and `heapremove()` didn't appear to take any arguments.  If the 
index is a required argument, then these are O(log N) operations.

I thought about adding them years ago, but didn't find a _plausible_ use case:  
the index at which a specific heap item appears is pretty much senseless, and 
typically varies over a heap's lifetime.  So how does the user know _which_ 
index to pass?  A linear search over the underlying list to find the index of a 
specific heap item is probably unacceptable.

The only hacks around that I could think of required a more complex kind of 
heap; e.g., restricting heap items to objects usable as dict keys, using a 
hidden dict to map heap items to their current index, and fiddling all the heap 
operations to keep that dict up to date.

So, in the absence of an obvious way to proceed, I gave up :-)

--
nosy: +tim.peters

___
Python tracker 

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

[issue31195] Make any() and all() work with async generators

[Brett Cannon]

New submission from Brett Cannon:

It would be great if I could do something like:

  if any(x for async x in aiter()): ...

But as of right now, any() complains that "TypeError: 'async_generator' object 
is not iterable". I would assume that any() and all() could be updated to look 
for __aiter__() instead of just __iter__() and do the right thing in either 
case? Or am I missing something subtle here?

--
components: Library (Lib)
messages: 300224
nosy: brett.cannon, giampaolo.rodola, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Make any() and all() work with async generators
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

[issue31186] Support heapfix() and heapremove() APIs in heapq module

[Rajath Agasthya]

Rajath Agasthya added the comment:

Thanks, Raymond. I think it's fair comment, but I'm not sure which operation is 
O(n) though. FWIW, Go supports these operations 
(https://golang.org/pkg/container/heap/), so the usage is there.

--

___
Python tracker 

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

[issue31194] Inconsistent __repr__s for _collections objects

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +rhettinger, serhiy.storchaka

___
Python tracker 

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

[issue31194] Inconsistent __repr__s for _collections objects

[Dan Snider]

New submission from Dan Snider:

With the new C implementation of collections.OrderedDict, its repr correctly 
uses the subclass's name, unlike deque and defaultdict.

class Thing(_collections.OrderedDict):
pass
>>> Thing()
Thing([])

class Thing(_collections.deque):
pass
>>> Thing()
deque([])

--
components: Library (Lib)
messages: 300222
nosy: bup
priority: normal
severity: normal
status: open
title: Inconsistent __repr__s for _collections objects
type: enhancement
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

[issue31161] Only check for print and exec parentheses cases for SyntaxError, not subclasses

[Martijn Pieters]

Changes by Martijn Pieters :


--
pull_requests: +3125

___
Python tracker 

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

[issue31161] Only check for print and exec parentheses cases for SyntaxError, not subclasses

[Martijn Pieters]

Changes by Martijn Pieters :


--
pull_requests: +3124

___
Python tracker 

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

[issue31161] Only check for print and exec parentheses cases for SyntaxError, not subclasses

[Martijn Pieters]

Martijn Pieters added the comment:

Disregard my last message, I misread Serhiy's sentence (read 'correct' for 
'incorrect').

--

___
Python tracker 

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

[issue31161] Only check for print and exec parentheses cases for SyntaxError, not subclasses

[Martijn Pieters]

Martijn Pieters added the comment:

This does not increase clarity. It creates confusion.

There are two distinct syntax errors, and they should be reported separately, 
just like `print "abc" 42` is two syntax errors; you'll hear about the second 
one once the first one is fixed.

--

___
Python tracker 

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

[issue31193] re.IGNORECASE strips combining character from lower case of LATIN CAPITAL LETTER I WITH DOT ABOVE

[David MacIver]

New submission from David MacIver:

chr(304).lower() is a two character string - a lower case i followed by a 
combining chr(775) ('COMBINING DOT ABOVE').

The re module seems not to understand the combining character and a regex 
compiled with IGNORECASE will erroneously match a single lower case i without 
the required combining character. The attached file demonstrates this. I've 
tested this on Python 3.6.1 with my locale as ('en_GB', 'UTF-8') (I don't know 
whether that matters for reproducing this, but I know it can affect how 
lower/upper work so am including it for the sake of completeness).

The problem does not reproduce on Python 2.7.13 because on that case 
chr(304).lower() is 'i' without the combining character, so it fails earlier.

This is presumably related to #12728, but as that is closed as fixed while this 
still reproduces I don't believe it's a duplicate.

--
components: Library (Lib)
files: casing.py
messages: 300219
nosy: David MacIver
priority: normal
severity: normal
status: open
title: re.IGNORECASE strips combining character from lower case of LATIN 
CAPITAL LETTER I WITH DOT ABOVE
versions: Python 3.6
Added file: http://bugs.python.org/file47080/casing.py

___
Python tracker 

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

[issue15988] Inconsistency in overflow error messages of integer argument

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Glad to see you again Oren! Maybe first finish issue28261? It looks easier.

--

___
Python tracker 

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

[issue31187] suboptimal code in Py_ReprEnter()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

PyList_GET_SIZE(list) is cheap (especially in comparison of 
_PyDict_GetItemId(), _PyDict_SetItemId() and PyList_New()), and its tiny 
overhead can be avoided at most once per thread's lifetime. I'm sure you can't 
measure the effect of this change.

If surrounding code be modified for other reasons, may be your change could be 
applied. But it alone just makes a code churn.

--
nosy: +rhettinger, serhiy.storchaka

___
Python tracker 

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

[issue31149] Add Japanese to the language switcher

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +3122

___
Python tracker 

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

[issue31159] Doc: Language switch can't switch on specific cases

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +3123

___
Python tracker 

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

[issue31149] Add Japanese to the language switcher

[Julien Palard]

Julien Palard added the comment:

Arfrever: nice catch!

Inda: What do you think? Any preference between "日本語", "Japanese", and  "日本語 
(Japanese)"?

I personally don't like much the "日本語 (Japanese)" version, but I don't care 
much between "French" and "Français" as they're using the same alphabet.

Maybe displaying "日本語" instead of "Japanese" show more commitment into 
translations? Like displaying "Japanese" meaning "OK we translated, but not 
everything, starting by your language".

Another solution would be to translate each languages in each languages, and 
display "Anglais, Japonais, Français" in the french translation, "English, 
Japanese, French" in the english one, and so on…

I think I prefer to display languages in their own language, so "English, 
"Français", "日本語" for me.

--

___
Python tracker 

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

[issue30871] Add a "python info" command somewhere to dump versions of all dependencies

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Sorry, version of what?

Versions of any external library. Python can be built with headers of one 
version, but dynamically load the library of other version.

For example TCL_VERSION and TK_VERSION are static versions (they should be 
equal in modern Tcl/Tk), and Tcl command "info patchlevel" returns the dynamic 
version. In the readline module _READLINE_VERSION is header version, 
_READLINE_RUNTIME_VERSION and _READLINE_LIBRARY_VERSION are runtime versions. 
In the zlib module ZLIB_VERSION is header version, ZLIB_RUNTIME_VERSION is 
runtime version.

--

___
Python tracker 

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

[issue31161] Only check for print and exec parentheses cases for SyntaxError, not subclasses

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The current traceback is incorrect. It mixes exception type and message from 
different errors.

--

___
Python tracker 

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

[issue31149] Add Japanese to the language switcher

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis added the comment:

There is a minor inconsistency:
For French language, name in the list is displayed in French as "Français".
For Japanese language, name in the list is displayed in English as "Japanese" 
instead of in Japanese as "日本語".

Maybe it would be best to display 2 names for each non-English language? 
Example:
 "Français (French)"
 "日本語 (Japanese)"

--
nosy: +Arfrever

___
Python tracker 

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