[issue6331] Add unicode script info to the unicode database

2015-10-17 Thread Denis Jacquerye

Changes by Denis Jacquerye :


--
nosy: +Denis Jacquerye

___
Python tracker 

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



[issue22612] Add block info to unicodedata

2015-10-17 Thread Denis Jacquerye

Changes by Denis Jacquerye :


--
nosy: +Denis Jacquerye

___
Python tracker 

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



[issue22570] Better stdlib support for Path objects

2015-10-17 Thread Torsten Bronger

Changes by Torsten Bronger :


--
nosy: +bronger

___
Python tracker 

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



[issue22570] Better stdlib support for Path objects

2015-10-17 Thread Torsten Bronger

Torsten Bronger added the comment:

Please be conservative with adding methods to Path.

FWIW, my own experiences with pathlib have shown that utility methods have the 
disadvantage of duplicating well-established Python idioms.  This reduces code 
readability in my opinion.  While it is desirable that the rather inconvenient 
os.path may be superseded by pathlib in the long run,  utility methods like 
Path.glob, Path.open, Path.mkdir, and Path.readtext have convenient stdlib 
counterparts with long tradition, and using the methods seems disruptive and 
confusing to me.

This is a further argument for having a path protocol instead IMO.

--

___
Python tracker 

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



[issue25335] ast.literal_eval fails to parse numbers with leading "+"

2015-10-17 Thread Mark Dickinson

Mark Dickinson added the comment:

> I am pretty sure the 2.x anomaly is tied up with having short ints plus the 
> anomaly of having one more negative than positive int.

Yes, that was the rationale for folding in the minus operation. It had some odd 
side-effects, though:

>>> -1j
-1j
>>> -(1j)
(-0-1j)

See issue 9011 for more discussion.

--

___
Python tracker 

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



[issue25430] speed up ipaddress __contain__ method

2015-10-17 Thread Александр Балезин

New submission from Александр Балезин:

Current check "address in network" is seems a bit odd:
int(self.network_address) <= int(other._ip) < int(self.broadcast_address)
This patch make this in bit-operation manner. Perfomace test:

import ipaddress
import timeit


class IPv6Network2(ipaddress.IPv6Network):
def __contains__(self, other):
# always false if one is v4 and the other is v6.
if self._version != other._version:
return False
# dealing with another network.
if isinstance(other, ipaddress._BaseNetwork):
return False
else:
# address
return other._ip & self.netmask._ip == self.network_address._ip

class IPv4Network2(ipaddress.IPv4Network):
def __contains__(self, other):
# always false if one is v4 and the other is v6.
if self._version != other._version:
return False
# dealing with another network.
if isinstance(other, ipaddress._BaseNetwork):
return False
# dealing with another address
else:
# address
return other._ip & self.netmask._ip == self.network_address._ip

ipv6_test_net = ipaddress.IPv6Network("::/0")
ipv6_test_net2 = IPv6Network2("::/0")
ipv4_test_net = ipaddress.IPv4Network("0.0.0.0/0")
ipv4_test_net2 = IPv4Network2("0.0.0.0/0")

dataipv6 = list()
dataipv4 = list()
for x in range(200):
dataipv6.append(ipaddress.IPv6Address(x))
dataipv4.append(ipaddress.IPv4Address(x))

def test():
for d in dataipv6:
d in ipv6_test_net

def test2():
for d in dataipv6:
d in ipv6_test_net2

def test3():
for d in dataipv4:
d in ipv4_test_net

def test4():
for d in dataipv4:
d in ipv4_test_net2

t = timeit.Timer("test()", "from __main__ import test")
print("ipv6 test origin __contains__", t.timeit(number=1))

t = timeit.Timer("test2()", "from __main__ import test2")
print("ipv6 test new __contains__", t.timeit(number=1))

t = timeit.Timer("test3()", "from __main__ import test3")
print("ipv4 test origin __contains__", t.timeit(number=1))

t = timeit.Timer("test4()", "from __main__ import test4")
print("ipv4 test new __contains__", t.timeit(number=1))

Output:

ipv6 test origin __contains__ 4.265904285013676
ipv6 test new __contains__ 1.551749340025708
ipv4 test origin __contains__ 3.689626455074176
ipv4 test new __contains__ 2.0175559649942443

--
components: Library (Lib)
files: ipaddress_contains.patch
keywords: patch
messages: 253126
nosy: Александр.Балезин
priority: normal
severity: normal
status: open
title: speed up ipaddress __contain__ method
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file40801/ipaddress_contains.patch

___
Python tracker 

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



[issue25411] SMTPHandler in the logging module fails with unicode strings

2015-10-17 Thread simon04

simon04 added the comment:

I omitted the date header w/o intent. Basically because I couldn't quickly 
figure out how to set it.

--

___
Python tracker 

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



[issue25431] implement address in network in ipaddress module

2015-10-17 Thread Александр Балезин

New submission from Александр Балезин:

Current realization of _BaseNetwork.__contains__ always returns False if other 
is _BaseNetwork. This patch implements proper comparison of _BaseNetwork 
objects.

--
components: Library (Lib)
files: ipaddress_contains_network.patch
keywords: patch
messages: 253128
nosy: Александр.Балезин
priority: normal
severity: normal
status: open
title: implement address in network in ipaddress module
versions: Python 3.5
Added file: http://bugs.python.org/file40802/ipaddress_contains_network.patch

___
Python tracker 

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



[issue12873] 2to3 incorrectly handles multi-line imports from __future__

2015-10-17 Thread Jos de Kloe

Jos de Kloe added the comment:

still having this issue with 2to3 from python-tools-2.7.8-11 as packaged by 
Fedora 21.
Any progress since 2011?

--
nosy: +jdekloe

___
Python tracker 

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



[issue16182] readline: Wrong tab completion scope indices in Unicode terminals

2015-10-17 Thread Serhiy Storchaka

Changes by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

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



[issue25432] isinstance documentation doesn't explain what happens when type is tuple

2015-10-17 Thread Michael Crouch

New submission from Michael Crouch:

In the section on isinstance() in the Python Standard Library documentation 
Chapter 2 (https://docs.python.org/3.6/library/functions.html#isinstance) , it 
says that classinfo "may be a tuple of type objects", but it doesn't explain 
what the semantics are in that case (e.g., that it will return true iff it is 
an instance of any of the types in the tuple).

--
assignee: docs@python
components: Documentation
messages: 253130
nosy: Michael Crouch, docs@python
priority: normal
severity: normal
status: open
title: isinstance documentation doesn't explain what happens when type is tuple
versions: Python 2.7, Python 3.6

___
Python tracker 

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



[issue25411] SMTPHandler in the logging module fails with unicode strings

2015-10-17 Thread Roundup Robot

Roundup Robot added the comment:

New changeset eb843115e052 by Vinay Sajip in branch '3.4':
Closes #25411: Improved Unicode support in SMTPHandler.
https://hg.python.org/cpython/rev/eb843115e052

New changeset b99b3ddd0ac4 by Vinay Sajip in branch '3.5':
Closes #25411: Merged fix from 3.4.
https://hg.python.org/cpython/rev/b99b3ddd0ac4

New changeset 522b5cdffd42 by Vinay Sajip in branch 'default':
Closes #25411: Merged fix from 3.5.
https://hg.python.org/cpython/rev/522b5cdffd42

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

___
Python tracker 

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



[issue25419] Readline completion of module names in import statements

2015-10-17 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

Added few cursory comments on Rietveld.

"sys" and "os.path" cases are not critical and we can ignore them if it 
complicates the code. But preserving Completer independence from readline looks 
more important to me. We can just add methods get_line_buffer(), get_begidx(), 
get_endidx() and get_completion_type() to Completer, but may be better to add 
more high level methods.

--

___
Python tracker 

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



[issue25410] Clean up and fix OrderedDict

2015-10-17 Thread Eric Snow

Eric Snow added the comment:

Regarding Py_TYPE(od) vs. od.__class__, there is a difference for subclasses, 
as you demonstrated in your example. [1]  Thanks for explaining your rationale. 
 I now understand your argument about using PyTYPE() for repr and pickle in C 
types.  I still have concerns, though, regarding parity between the two 
OrderedDict implementations.

The key difference is that we're talking about an after-the-fact C port of an 
existing pure Python implementation.  The two implementations should behave 
identically in nearly every case.  The only place I would expect a deviation to 
not matter is for anything where Python-as-a-whole does not guarantee behavior. 
 However there are *very* few of those when all is said and done.  Any other 
variation should not be made casually and only if we are willing to accept that 
there may be code out there that relies on the pure Python behavior which the C 
implementation will break.

So like I said before, as a rule I'm absolutely okay with changing the behavior 
as long as the pure Python implementation is changed to match and OrderedDict 
remains backward-compatible (and the change is meaningful, e.g. efficiency, 
consistency).  Otherwise my concerns remain and we have to have sufficient 
justification for the change.

It may be worth taking this to python-dev to get a clearer consensus on both 
"Py_TYPE(obj) vs. obj.__class__", as well as about parity between dual 
pure-Python/C implementations in the stdlib, regardless of the outcome of this 
issue.  Both are points about which we should be consistent throughout Python.  
The type() vs. __class__ question may deserve an entry in the language 
reference and both may deserve a PEP.  

-

For this particular case, I think we should still aim for compatibility with 
the pure Python implementation.  To that effect, we could use Py_TYPE(od) only 
if PyODict_CheckExact() returns true (as a fast path) and use od.__class__ 
otherwise.  That fast path would be safe for the C implementation since code 
can't change OrderedDict().__class__ (due to #24912).

That particular difference in the implementations (i.e. you *can* change 
od.__class__ for the pure Python one) is an acceptable compatibility break 
since it's unlikely anyone is changing od.__class__ *and* if they are then they 
can just switch to a simple subclass that wraps OrderedDict:

# before:
from collections import OrderedDict
od = OrderedDict()
od.__class__ = SomethingElse

# after:
import collections
class OrderedDict(collections.OrderedDict):
pass
od = OrderedDict()
od.__class__ = SomethingElse

If we *do* continue supporting "type(od) != od.__class__" in repr then I'd say 
why bother with a fast path for PyOdict_CheckExact().  That sort of efficiency 
isn't necessary for repr.  If we stop supporting a differing od.__class__ then 
I'm fine simply using Py_TYPE() throughout.

Likewise, if this is not a case we want to support then we must accept that we 
may break some code out there, however unlikely that is.  In that case perhaps 
we could be more clear in the documentation that OrderedDict().__class__ should 
not be changed, though such an addition to the OrderedDict docs might just be 
clutter.  A general FAQ or other broader doc entry about not assigning to 
obj.__class__ for stdlib types might be more appropriate.  But that is where 
clarification from python-dev would help.


[1] There is also a difference between type(obj) and obj.__class__ in the case 
of proxies (e.g. see #16251), but that is less of an issue here.

--

___
Python tracker 

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



[issue25410] Clean up and fix OrderedDict

2015-10-17 Thread Eric Snow

Eric Snow added the comment:

Regarding #5, you're right about OrderedDict().__dict__ being empty for the C 
implementation.  (Nice observation!)  So I'm okay with ripping all that code 
out of odict_reduce().  Since we're still accessing od.__dict__ through 
_PyObject_GetAttrId() that should not impact subclassing.

--

___
Python tracker 

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



[issue25405] User install of 3.5 removes py.exe from C:\Windows

2015-10-17 Thread Vinay Sajip

Changes by Vinay Sajip :


--
nosy: +vinay.sajip

___
Python tracker 

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



[issue25430] speed up ipaddress __contain__ method

2015-10-17 Thread Aleksandr Balezin

Changes by Aleksandr Balezin :


--
versions: +Python 3.4, Python 3.6

___
Python tracker 

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



[issue25431] implement address in network in ipaddress module

2015-10-17 Thread Aleksandr Balezin

Changes by Aleksandr Balezin :


--
versions: +Python 3.4, Python 3.6

___
Python tracker 

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



[issue25410] Clean up and fix OrderedDict

2015-10-17 Thread Eric Snow

Eric Snow added the comment:

Regarding #7, I see what you did now.  That looks fine to me.

--

___
Python tracker 

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



[issue25432] isinstance documentation doesn't explain what happens when type is tuple

2015-10-17 Thread R. David Murray

R. David Murray added the comment:

I don't see any ambiguity here.  There are other Python APIs with the same 
behavior, and all we say is that it can be a tuple (eg: str.startswith).  That 
is, I don't see any other way a tuple could be interpreted that would make any 
sense.

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



[issue25429] Can segfault Python with itertools.chain.from_iterable

2015-10-17 Thread Zachary Ware

Changes by Zachary Ware :


--
stage:  -> resolved

___
Python tracker 

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



[issue25410] Clean up and fix OrderedDict

2015-10-17 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

> Regarding Py_TYPE(od) vs. od.__class__, there is a difference for
> subclasses, as you demonstrated in your example. [1]  Thanks for explaining
> your rationale.  I now understand your argument about using PyTYPE() for
> repr and pickle in C types.  I still have concerns, though, regarding
> parity between the two OrderedDict implementations.
> 
> The key difference is that we're talking about an after-the-fact C port of
> an existing pure Python implementation.

There is no a difference. io, pickle, ElementTree, bz2, virtually all 
accelerator classes was created as replacements of pure Python 
implementations. All C implementations use Py_TYPE(self) for repr() and 
pickling. I think this deviation is common and acceptable.

Backward compatibility related to __class__ assignment was already broken in C 
implementation. In 3.4 following code works:

>>> from collections import *
>>> class foo(OrderedDict):
... def bark(self): return "spam"
... 
>>> class bar(OrderedDict):
... pass
... 
>>> od = bar()
>>> od.__class__ = foo
>>> od.bark()
'spam'

In 3.5 it doesn't.

> That particular difference in the implementations (i.e. you *can* change
> od.__class__ for the pure Python one) is an acceptable compatibility break
> since it's unlikely anyone is changing od.__class__ *and* if they are then
> they can just switch to a simple subclass that wraps OrderedDict:
> 
> # before:
> from collections import OrderedDict
> od = OrderedDict()
> od.__class__ = SomethingElse
> 
> # after:
> import collections
> class OrderedDict(collections.OrderedDict):
> pass
> od = OrderedDict()
> od.__class__ = SomethingElse

No, this assignment is forbidden (due to #24912). You can't set __class_ for 
an instance of a subclass of non-heap type.

> It may be worth taking this to python-dev to get a clearer consensus on both
> "Py_TYPE(obj) vs. obj.__class__", as well as about parity between dual
> pure-Python/C implementations in the stdlib, regardless of the outcome of
> this issue.  Both are points about which we should be consistent throughout
> Python.  The type() vs. __class__ question may deserve an entry in the
> language reference and both may deserve a PEP.

Could you please raise a discussion on Python-Dev? You will formulate the 
problem better.

--

___
Python tracker 

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



[issue25432] isinstance documentation doesn't explain what happens when type is tuple

2015-10-17 Thread eryksun

eryksun added the comment:

Since Python has multiple inheritance, it could be misconstrued as a 
conjunctive test. For example, if c is an instance of C, which subclasses both 
A and B, then someone might think isinstance(c, (A, B)) requires c to be an 
instance of both A and B. The description could clarify that it's a disjunctive 
test with short circuiting.

class MetaA(type):
def __instancecheck__(self, other):
print('MetaA.__instancecheck__')
return False

class A(metaclass=MetaA): pass

>>> isinstance(1, (A, int))
MetaA.__instancecheck__
True
>>> isinstance(1, (int, A))
True

--
keywords: +easy
nosy: +eryksun

___
Python tracker 

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



[issue25431] implement address in network in ipaddress module

2015-10-17 Thread Serhiy Storchaka

Changes by Serhiy Storchaka :


--
dependencies: +speed up ipaddress __contain__ method
nosy: +ncoghlan, pmoody
stage:  -> patch review
type:  -> enhancement
versions:  -Python 3.4, Python 3.5

___
Python tracker 

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



[issue25430] speed up ipaddress __contain__ method

2015-10-17 Thread Serhiy Storchaka

Changes by Serhiy Storchaka :


--
nosy: +ncoghlan, pmoody
stage:  -> patch review
versions:  -Python 3.4, Python 3.5

___
Python tracker 

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



[issue25410] Clean up and fix OrderedDict

2015-10-17 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

Updated patch addresses Eric's comments. Changes related to #3 are reverted. We 
will return to this after discussing on Python-Dev.

--

___
Python tracker 

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



[issue25410] Clean up and fix OrderedDict

2015-10-17 Thread Serhiy Storchaka

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file40803/odict_cleanup_2.patch

___
Python tracker 

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



[issue25410] Clean up and fix OrderedDict

2015-10-17 Thread Eric Snow

Eric Snow added the comment:

new patch LGTM

--

___
Python tracker 

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



[issue25410] Clean up and fix OrderedDict

2015-10-17 Thread Eric Snow

Eric Snow added the comment:

> Backward compatibility related to __class__ assignment was already broken in C
> implementation. In 3.4 following code works:
[snip]
> In 3.5 it doesn't.

Depending on what feedback we get from python-dev, that may need to be
fixed.  I'd be inclined to not worry about it. :)

> No, this assignment is forbidden (due to #24912). You can't set __class_ for
> an instance of a subclass of non-heap type.

Ah, I see.  So the solution to that issue has *forced* a compatibility break.

> Could you please raise a discussion on Python-Dev? You will formulate the
> problem better.

I will.

--

___
Python tracker 

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



[issue25410] Clean up and fix OrderedDict

2015-10-17 Thread Eric Snow

Eric Snow added the comment:

Posted to python-dev:

https://mail.python.org/pipermail/python-dev/2015-October/141953.html

https://mail.python.org/pipermail/python-dev/2015-October/141954.html

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



[issue25395] SIGSEGV using json.tool: highly nested OrderedDict

2015-10-17 Thread Martin Panter

Martin Panter added the comment:

The following simplified code produces the crash:

from collections import OrderedDict
obj = []
for _ in range(33):
obj = OrderedDict(((None, obj),))
for _ in range(17):
obj = [obj]
print("Still alive, crash happens at interpreter finalization")

This crashes at the same line as in Serhiy’s backtrace. In 
_PyTrash_thread_destroy_chain(), Py_TYPE(op) is a bad pointer 
(0xdbdbdbdbdbdbdbdb); I have enabled --with-pydebug.

--
components: +Interpreter Core -Library (Lib)
nosy: +martin.panter
title: SIGSEGV using json.tool -> SIGSEGV using json.tool: highly nested 
OrderedDict

___
Python tracker 

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



[issue25410] Clean up and fix OrderedDict

2015-10-17 Thread Roundup Robot

Roundup Robot added the comment:

New changeset b6e33798f82a by Serhiy Storchaka in branch '3.5':
Issue #25410: Cleaned up and fixed minor bugs in C implementation of 
OrderedDict.
https://hg.python.org/cpython/rev/b6e33798f82a

New changeset 741ef17e9b86 by Serhiy Storchaka in branch 'default':
Issue #25410: Cleaned up and fixed minor bugs in C implementation of 
OrderedDict.
https://hg.python.org/cpython/rev/741ef17e9b86

--
nosy: +python-dev

___
Python tracker 

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