[issue24018] add a Generator ABC

[Stefan Behnel]

Stefan Behnel added the comment:

> should inspect.isgenerator() be changed?

Replying to myself, one thing that speaks against this approach is that 
"inspect" also has the functions "getgeneratorlocals()" and 
"getgeneratorstate()", which depend on "gen.gi_frame". Cython could emulate 
that, but normal user code usually can't. It's definitely not part of the 
Generator protocol but an implementation detail of GeneratorType.

--

___
Python tracker 

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

[issue24018] add a Generator ABC

[Stefan Behnel]

Stefan Behnel added the comment:

Good catch with the RuntimeError. Patch updated.

--
Added file: http://bugs.python.org/file39157/generator_abc.patch

___
Python tracker 

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

[issue24018] add a Generator ABC

[Martin Panter]

Martin Panter added the comment:

I agree that there is no big reason why we should force generators to stop 
working after close(). Your new default implementation of close() is probably 
the right thing too. I added a few new comments on Reitveld.

--

___
Python tracker 

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

[issue24018] add a Generator ABC

[Stefan Behnel]

Stefan Behnel added the comment:

Next question: should inspect.isgenerator() be changed? Or should its usages be 
replaced by isinstance(obj, Generator) ?

--

___
Python tracker 

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

[issue24018] add a Generator ABC

[Stefan Behnel]

Stefan Behnel added the comment:

> Is it a problem that the check can't be done in a fast way from C code?

C code can still quickly special case the generator type in the positive case, 
and it will usually be interested in an exact type match anyway. Determining 
that an object is *not* (compatible with) a generator might lead to some 
degradation, but in most cases, at least in the interpreter core, this would be 
an error case anyway, so being slower here should rarely hurt.

--

___
Python tracker 

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

[issue24018] add a Generator ABC

[Stefan Behnel]

Stefan Behnel added the comment:

Here's a new patch that addresses the review comments. I kept throw() and 
close() non-abstract and added an example to the tests instead that implements 
a minimal generator by inheriting these methods from the Generator base class, 
using it as a mixin. It only needs to implement send().

I don't think it's unreasonable to assume that there are use cases where a 
generator that is implemented in a class instead of a yield-function does not 
require special cleanup actions in its close()/throw(). Or is it *required* 
that a generator stops working when close() is called?

There are also iterators that raise StopIteration at some point to signal that 
they are temporarily exhausted, but then eventually restart returning values 
from their __next__() method when they have received more to return. Avoids 
recreating the iterator object after each exhaustion cycle.

I extended the default implementation of close() to call throw(GeneratorExit), 
though, because that's how the protocol is defined. Unless users implement 
throw(), it won't make a difference for them. And if they do, they may even get 
away with not reimplementing close().

--
Added file: http://bugs.python.org/file39156/generator_abc.patch

___
Python tracker 

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

[issue24019] str/unicode encoding kwarg causes exceptions

[Mahmoud Hashemi]

New submission from Mahmoud Hashemi:

The encoding keyword argument to the Python 3 str() and Python 2 unicode() 
constructors is excessively constraining to the practical use of these core 
types.

Looking at common usage, both these constructors' primary mode is to convert 
various objects into text:

>>> str(2)
'2'

But adding an encoding yields:

>>> str(2, encoding='utf8')
Traceback (most recent call last):
  File "", line 1, in 
TypeError: coercing to str: need bytes, bytearray or buffer-like object, int 
found

While the error message is fine for an experienced developer, I would like to 
raise the question: is it necessary at all? Even harmlessly getting a str from 
a str is punished, but leaving off encoding is fine again:

>>> str('hi', encoding='utf8')
Traceback (most recent call last):
  File "", line 1, in 
TypeError: decoding str is not supported
>>> str('hi')
'hi'

Merging and simplifying the two modes of these constructors would yield much 
more predictable results for experienced and beginning Pythonists alike. 
Basically, the encoding argument should be ignored if the argument is already a 
unicode/str instance, or if it is a non-string object. It should only be 
consulted if the primary argument is a bytestring. Bytestrings already have a 
.decode() method on them, another, obscurer version of it isn't necessary.

Furthermore, despite the core nature and widespread usage of these types, 
changing this behavior should break very little existing code and 
understanding. unicode() and str() will simply behave as expected more often, 
returning text versions of the arguments passed to them. 

Appendix: To demonstrate the expected behavior of the proposed unicode/str, 
here is a code snippet we've employed to sanely and safely get a text version 
of an arbitrary object:

def to_unicode(obj, encoding='utf8', errors='strict'):
# the encoding default should look at sys's value
try:
return unicode(obj)
except UnicodeDecodeError:
return unicode(obj, encoding=encoding, errors=errors)

After many years of writing Python and teaching it to developers of all 
experience levels, I firmly believe that this is the right interaction pattern 
for Python's core text type. I'm also happy to expand on this issue, turn it 
into a PEP, or submit a patch if there is interest.

--
components: Unicode
messages: 241699
nosy: ezio.melotti, haypo, mahmoud
priority: normal
severity: normal
status: open
title: str/unicode encoding kwarg causes exceptions
type: behavior
versions: Python 2.7, 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

[issue8548] Building on CygWin 1.7: PATH_MAX redefined

[Masayuki Yamamoto]

Masayuki Yamamoto added the comment:

This issue resolved on default branch in #20597 .

In 3.4 branch latest, PATH_MAX seems unused already in Modules/main.c:12 and 
Python/pythonrun.c:35.
I want to cherry-pick #20597 to 3.4 branch.

--
nosy: +masamoto

___
Python tracker 

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

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

[Yury Selivanov]

Changes by Yury Selivanov :


--
assignee:  -> yselivanov

___
Python tracker 

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

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

[Yury Selivanov]

Yury Selivanov added the comment:

Attaching a revised patch (all Victor's comments but asyncio changes)

--
Added file: http://bugs.python.org/file39155/await_02.patch

___
Python tracker 

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

[issue23974] random.randrange() biased output

[Raymond Hettinger]

Raymond Hettinger added the comment:

> we *still* have no documented guarantees of reproducibility,
> so maybe it's safe to go ahead and change this.  Raymond?

It is documented here:  
https://docs.python.org/3/library/random.html#notes-on-reproducibility

The idea that is that algorithms (and the generated sequences) may change in 
between minor releases, but not in micro releases.  And random() itself if more 
restricted (guaranteed to be the same across minor releases as well).  The 
policy was new in Python 3.  It was a liberalization of the implied policy in 
Python 2 that we didn't change the sequences at all (except for flat-out 
brokenness).

Accordingly, the #9025 debiasing was intentionally not backported so we won't 
break reproducibility and adversely affect performance of existing code.

We could add a note as Mark suggests, but please keep it terse and 
affirmatively worded (perhaps something "See also:  Recipe 31xx for a way to 
eliminate rounding biases in randrange()".  The docs are not well served by 
being littered with Danger-signs and security warnings.

--

___
Python tracker 

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

[issue17445] Handle bytes comparisons in difflib.Differ

[Berker Peksag]

Changes by Berker Peksag :


--
stage: commit review -> resolved

___
Python tracker 

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

[issue9246] os.getcwd() hardcodes max path len

[William Orr]

William Orr added the comment:

I've incorporated some of the feedback from the reviews into this new patch. I 
used the PyMem_Raw* functions to do allocation to avoid having to acquire the 
GIL and also avoid complciations from the builtin memory allocator, since I'm 
not using python objects.

I have also fixed a memory leak in my original patch, as well as a case where 
OSes with a small MAX_PATH fail with ENAMETOOLONG

--
Added file: http://bugs.python.org/file39154/max_getcwd.patch

___
Python tracker 

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

[issue23987] docs about containers membership testing wrong for broken objects

[Raymond Hettinger]

Raymond Hettinger added the comment:

There is a separate report for taking care of the identity check for contains:  
https://bugs.python.org/issue23986

I think notes about crazy hashes shouldn't spill all over our docs.  At best, 
it warrants a FAQ entry about how hash tables work.

The risk here is that in an effort to be more precise, it is easy impair the 
usability of the docs.  The wording in question has been around for a very long 
time and has overall done a good job of explaining the intent of the 
in-operator to all but the most pedantic reader, "The operators 'in' and 'not 
in' test for membership. 'x in s' evaluates to true if x is a member of s, and 
false otherwise."

If you really want to be precise, the *only* thing that can be broadly stated 
about the in-operator is that it calls __contains__ on an object that that 
object can implement whatever logic it wants (hash table lookup, linear search, 
google search, random result, etc).  But then, this is no different than most 
magic methods in that regard.

--
assignee: docs@python -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue1927] raw_input behavior incorrect if readline not enabled

[Bhuvan Arumugam]

Bhuvan Arumugam added the comment:

For the record, this bug is still open. 

The proposed patch is not merged in any of branches.

The prompt for raw_input in all versions, go to stderr.

--
nosy: +bhuvan

___
Python tracker 

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

[issue24018] add a Generator ABC

[Raymond Hettinger]

Raymond Hettinger added the comment:

For the other ABCs, if you define the required abstract methods, you get 
working versions of all the mixin methods.

In the case of the Generator ABC, throw() and close() are useless empty stub 
methods.  In the other ABCs, we leave optional methods out entirely.  A user 
should expect that if isinstance(g, Generator) is true that all of the ABC 
methods will work.

Also, the return StopIteration in throw() doesn't seem correct.  Shouldn't it 
raise the exception that was thrown?

>>> def f():
yield x


>>> g = f()
>>> g.throw(KeyError)

Traceback (most recent call last):
  File "", line 1, in 
g.throw(KeyError)
  File "", line 1, in f
def f():
KeyError

Ideally, there should be a practical example of where this ABC would be useful 
with anything other than a real generator.

--
nosy: +rhettinger

___
Python tracker 

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

[issue17445] Handle bytes comparisons in difflib.Differ

[Greg Ward]

Changes by Greg Ward :


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

[issue17445] Handle bytes comparisons in difflib.Differ

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1764d42b340d by Greg Ward in branch 'default':
#17445: difflib: add diff_bytes(), to compare bytes rather than str
https://hg.python.org/cpython/rev/1764d42b340d

--
nosy: +python-dev

___
Python tracker 

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

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

[Yury Selivanov]

Changes by Yury Selivanov :


--
dependencies: +PEP 479: Change StopIteration handling inside generators

___
Python tracker 

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

[issue24018] add a Generator ABC

[Martin Panter]

Changes by Martin Panter :


--
nosy: +vadmium

___
Python tracker 

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

[issue23989] Add recommendation to use requests to the documentation, per summit

[Roundup Robot]

Roundup Robot added the comment:

New changeset c9239543235e by Benjamin Peterson in branch '3.4':
recommend requests library (closes #23989)
https://hg.python.org/cpython/rev/c9239543235e

New changeset 3cf2990d19ab by Benjamin Peterson in branch '2.7':
recommend requests library (closes #23989)
https://hg.python.org/cpython/rev/3cf2990d19ab

New changeset 65ce1d9eee30 by Benjamin Peterson in branch 'default':
merge 3.4 (#23989)
https://hg.python.org/cpython/rev/65ce1d9eee30

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

[issue24001] Clinic: use raw types in types= set

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Usually converters are named by the C type of the result. May be rename the 
"str" converter to "pchar"?

--

___
Python tracker 

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

[issue10308] Modules/getpath.c bugs

[STINNER Victor]

STINNER Victor added the comment:

> Reading msg120918 and msg120940 it looks as if work has been completed so 
> this can be closed as fixed.

Attached patch contains more fixes.

--

___
Python tracker 

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

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

[STINNER Victor]

STINNER Victor added the comment:

Does the implementation depends on the implementation of the PEP 479? (issue 
#22906)

> Attaching a patch generated with mercurial

Next time, if possible, try to skip generated files. Maybe write a script for 
that, but sorry I don't know how :-(

--

___
Python tracker 

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

[issue23989] Add recommendation to use requests to the documentation, per summit

[Christian Heimes]

Changes by Christian Heimes :


--
nosy: +christian.heimes

___
Python tracker 

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

[issue6824] help for a module should list supported platforms

[Terry J. Reedy]

Terry J. Reedy added the comment:

I agree.  The resolution is that help fails for objects that do not exist on 
the platform.  We do not supply non-functional dummy objects that only exist to 
document non-support.  Any objects with undocumented platform-specific behavior 
should be handled on a case-by-case basis.

--
resolution:  -> works for me
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

[issue23989] Add recommendation to use requests to the documentation, per summit

[VanL]

VanL added the comment:

Given the generally positive comments, here are patches for 2.7, 3.3, 3.4, and 
3.5 (3.5 patch updated to also include urllib.request).

--
Added file: http://bugs.python.org/file39153/recommend_requests_2.patch

___
Python tracker 

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

[issue22619] Possible implementation of negative limit for traceback functions

[Dmitry Kazakov]

Dmitry Kazakov added the comment:

Here's the documentation patch.

--
Added file: http://bugs.python.org/file39152/traceback_limit_doc.diff

___
Python tracker 

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

[issue12606] Mutable Sequence Type works different for lists and bytearrays in slice[i:j:k]

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
stage: test needed -> patch review
versions: +Python 3.5 -Python 3.4

___
Python tracker 

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

[issue24018] add a Generator ABC

[Łukasz Langa]

Changes by Łukasz Langa :


--
assignee:  -> lukasz.langa
nosy: +lukasz.langa

___
Python tracker 

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

[issue24018] add a Generator ABC

[Antoine Pitrou]

Antoine Pitrou added the comment:

Is it a problem that the check can't be done in a fast way from C code?

Other than that, sounds good to me.

--
nosy: +pitrou

___
Python tracker 

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

[issue24018] add a Generator ABC

[Stefan Behnel]

Stefan Behnel added the comment:

Sorry, here's another doc fix.

--
Added file: http://bugs.python.org/file39151/generator_abc.patch

___
Python tracker 

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

[issue24018] add a Generator ABC

[Stefan Behnel]

Changes by Stefan Behnel :


Removed file: http://bugs.python.org/file39150/generator_abc.patch

___
Python tracker 

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

[issue24018] add a Generator ABC

[Stefan Behnel]

Stefan Behnel added the comment:

Ok, sure. Here's a new patch that adds tests and docs.

--
Added file: http://bugs.python.org/file39150/generator_abc.patch

___
Python tracker 

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

[issue16574] clarify policy on updates to final peps

[Éric Araujo]

Éric Araujo added the comment:

Patch LGTM.

--

___
Python tracker 

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

[issue24018] add a Generator ABC

[Stefan Behnel]

Changes by Stefan Behnel :


Removed file: http://bugs.python.org/file39146/generator_abc.patch

___
Python tracker 

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

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

[Yury Selivanov]

Changes by Yury Selivanov :


Removed file: http://bugs.python.org/file39149/await_01.patch

___
Python tracker 

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

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

[Yury Selivanov]

Changes by Yury Selivanov :


Added file: http://bugs.python.org/file39149/await_01.patch

___
Python tracker 

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

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

[Yury Selivanov]

Yury Selivanov added the comment:

Attaching a patch generated with mercurial

--
Added file: http://bugs.python.org/file39148/await_01.patch

___
Python tracker 

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

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

[Yury Selivanov]

Changes by Yury Selivanov :


Removed file: http://bugs.python.org/file39147/async_01.patch

___
Python tracker 

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

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

[Yury Selivanov]

New submission from Yury Selivanov:

Here's the first patch (git diff master..await). Should be easier to review and 
work from there.

--
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file39147/async_01.patch

___
Python tracker 

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

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

[STINNER Victor]

Changes by STINNER Victor :


--
hgrepos:  -306

___
Python tracker 

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

[issue24018] add a Generator ABC

[Guido van Rossum]

Guido van Rossum added the comment:

It's missing tests. :-)

Otherwise looks quite sensible.

Also, shouldn't you override __subclasshook__ so you don't inherit it from 
Iterator?

--

___
Python tracker 

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

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

[Stefan Behnel]

Changes by Stefan Behnel :


--
nosy: +scoder
type:  -> enhancement

___
Python tracker 

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

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

[Yury Selivanov]

Changes by Yury Selivanov :


--
nosy: +asvetlov, yselivanov

___
Python tracker 

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

[issue24004] avoid explicit generator type check in asyncio

[Stefan Behnel]

Stefan Behnel added the comment:

I created issue 24018 for adding a Generator ABC to collections.abc.

--

___
Python tracker 

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

[issue24018] add a Generator ABC

[Stefan Behnel]

New submission from Stefan Behnel:

Currently, CPython tends to assume that generators are always implemented by a 
Python function that uses the "yield" keyword. However, it is absolutely 
possible to implement generators as a protocol by adding send(), throw() and 
close() methods to an iterator.

The problem is that these will usually be rejected by code that needs to 
distinguish generators from other input, e.g. in asyncio, as this code will 
commonly do a type check against types.GeneratorType. Instead, it should check 
for the expected protocol. The best way to achieve this is to extend the 
existing ABCs with a Generator ABC that external generator implementations can 
register on.

Related to issue 24004 (asyncio). Asyncio could provide a backport copy of this 
for older Python versions.

I assume this is considered a new feature that cannot be added to 3.4 anymore?

--
components: Library (Lib)
files: generator_abc.patch
keywords: patch
messages: 241675
nosy: gvanrossum, haypo, scoder, yselivanov
priority: normal
severity: normal
status: open
title: add a Generator ABC
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file39146/generator_abc.patch

___
Python tracker 

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

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: haypo
priority: normal
severity: normal
status: open
title: Implemenation of the PEP 492 - Coroutines with async and await syntax
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

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

[STINNER Victor]

Changes by STINNER Victor :


--
hgrepos: +306

___
Python tracker 

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

[issue24015] timeit should start with 1 loop, not 10

[Mark Dickinson]

Mark Dickinson added the comment:

Huh.  I assumed that timeit was doing this already.  +1 from me.

Affects Python 3.4 and 3.5, too.

taniyama:~ mdickinson$ time python -m timeit "import time; time.sleep(1.0)"
10 loops, best of 3: 1 sec per loop

real0m40.165s
user0m0.040s
sys 0m0.024s

--
nosy: +mark.dickinson
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

[issue23275] Can assign [] = (), but not () = []

[Mark Dickinson]

Mark Dickinson added the comment:

> There is also no reason to break currently working code

Agreed.  To take one example, David Beazley's PyCon 2015 talk would have been 
broken by the suggested change!  (See 
https://www.youtube.com/watch?v=MCs5OvhV9S4, at around the 42:17 mark.)

If there's any code change resulting from this issue, I also think it should be 
to make assignment to `()` legal.

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue24001] Clinic: use raw types in types= set

[Larry Hastings]

Larry Hastings added the comment:

Attached is a patch implementing all my proposed changes here:

* "types" is now renamed "accept"
* it accepts a set of real Python types
* there are placeholder types for buffer, robuffer, rwbuffer
* "nullable=True" is gone, replaced with adding NoneType to accept={}

--
Added file: http://bugs.python.org/file39145/larry.clinic.use.raw.types.3.txt

___
Python tracker 

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

[issue23920] Should Clinic have "nullable" or types=NoneType?

[Larry Hastings]

Larry Hastings added the comment:

I've implemented this change in the latest patch (#3) for #24001.

--

___
Python tracker 

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

[issue23955] Add python.ini file for embedded/applocal installs

[Thomas Kluyver]

Thomas Kluyver added the comment:

Relative paths would be nice for Pynsist - I would prefer to create the config 
file at build time and then install it along with the other files. If it needed 
absolute paths, then the installer would have to write the config file after 
the user selects the installation directory. That's doable, but it's easier to 
write and test the build steps than the install steps.

--

___
Python tracker 

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

[issue23955] Add python.ini file for embedded/applocal installs

[Thomas Kluyver]

Changes by Thomas Kluyver :


--
nosy: +takluyver

___
Python tracker 

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

[issue24014] Second pass of PyCode_Optimize

[Joe Jevnik]

Joe Jevnik added the comment:

I tried bumping the magic number; however, I still cannot get consistent 
results when running benchmark locally. I guess I will close this as I cannot 
consistently show an improvement.

--
status: open -> closed

___
Python tracker 

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

[issue23994] argparse fails to detect program name when there is a slash at the end of the program's path

[Mert Bora Alper]

Mert Bora Alper added the comment:

> Thanks for the patch.  We'll want a unit test for the behavior before 
> committing this.

You're welcome. Since I have no experience in writing unit tests, I don't 
really know where to start but I will try to do my best.

I added bethard to the Nosy List, as he is the author of argparse's test.

(In addition, you may want to change cpython/Lib/test/test_argparse.py:2163 )

--
nosy: +bethard

___
Python tracker 

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

[issue23987] docs about containers membership testing wrong for broken objects

[R. David Murray]

R. David Murray added the comment:

Yes, that's what I had in mind.

--

___
Python tracker 

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

[issue24016] Add a Sprints organization/preparation section to devguide

[Carol Willing]

New submission from Carol Willing:

Based on feedback from the PyCon 2015 CPython sprints (thank you R. David 
Murray and all the CPython contributors there), a sprint organization section 
will be added to the devguide.

Here are some suggested subtopics in the Sprints organization section:
* Pre-sprint preparation (by core devs and those familiar with CPython devel)
  - Etherpad for issues and links to resources
  - Dev in a box environment preparation
  - Docker container for development (based on work done by Saul)
* At the sprint
  - Important info posted in room (IRC; etherpad; schedule)
  - Welcome talk as given by R. David
  - Introduction of core devs in attendance
  - Periodic announcements to encourage questions
* After the sprint
  - Capture feedback from the etherpad
  - Refine devguide as needed

Please suggest additional topics. Thanks!

--
assignee: willingc
components: Devguide
messages: 241666
nosy: ezio.melotti, willingc
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a Sprints organization/preparation section to devguide
type: enhancement

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[eryksun]

eryksun added the comment:

To be consistent you'd have to do the attribute check in PyObject_Call as well, 
i.e. if an object isn't callable, then trying to call it should raise a 
TypeError. I think the cost can be mitigated by only checking heap types (i.e. 
tp_flags & Py_TPFLAGS_HEAPTYPE).

It would be cleaner if slot_tp_call failed by raising TypeError instead of 
letting the AttributeError bubble up. There's a precedent in slot_tp_iter to 
raise a TypeError if lookup_method() fails. This would avoid having to change 
PyObject_Call.

--
nosy: +eryksun

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Ionel Cristian Mărieș]

Ionel Cristian Mărieș added the comment:

On Mon, Apr 20, 2015 at 5:42 PM, Raymond Hettinger 
wrote:

>
> That is clear but also isn't sufficient motivation.  The proposed change
> is unnecessary and not rooted in real use cases.  It is a semantic change
> to a long-standing view that callable() means having a __call__ method.
>

There is one use case: a lazy object proxy (there are some examples in the
earlier replies).  Eric proposed a CallableProxy/NonCallableProxy
dichtonomy but I don't really like that API (feels wrong and verbose).

> Please stop using the bug tracker to post li

​Sorry about that, I've replied through email and wasn't aware of
bugtracker etiquette.​

​The bugtracker doesn't have a nice way to reply to messages and it's
atrocious on a mobile device.​

--

___
Python tracker 

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

[issue23496] Steps for Android Native Build of Python 3.4.2

[Cyd Haselton]

Cyd Haselton added the comment:

Ryan,
Completely forgot to download and apply it, but based on what I see there are a 
few things that need to be corrected.

1) -python3.4m needs to be changed to -python3.5m...or the appropriate 
versioning variable.
2) colons at the end of the elif lines in setup.py (1950- )
3) The _crypt and readline module builds in setup.py need additional libraries 
to work...python3.5m for both and possibly ncurses for readline, I'll test and 
get back to you.

With #1 and #2 added, the build and install completes successfully, although 
you obviously can't import readline and _crypt.

--

___
Python tracker 

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

[issue24014] Second pass of PyCode_Optimize

[Yury Selivanov]

Yury Selivanov added the comment:

> Does the benchmark tool recompile the code every run?

Make sure you've bumped magic number in importlib/bootstrap; then make clean; 
make

--

___
Python tracker 

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

[issue23987] docs about containers membership testing wrong for broken objects

[Ethan Furman]

Ethan Furman added the comment:

So something like:

For container types such as list, tuple, or collections.deque, the expression 
'x in y' is equivalent to 'any(x is e or x == e for e in y)'.  For container 
types such as set, frozenset, and dict, this equivalence expression is modified 
by the addition of 'if hash(x) == hash(e)'.

?

--

___
Python tracker 

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

[issue24014] Second pass of PyCode_Optimize

[Joe Jevnik]

Joe Jevnik added the comment:

I am actually getting inconsistent results from running benchmark; I am pretty 
surprised by this. I could look into making the second pass only happen if the 
code has the CO_OPTIMIZED bit set; however, based on the results I am seeing 
from the benchmark runs, I am not sure it is worth it. Does the benchmark tool 
recompile the code every run?

--

___
Python tracker 

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

[issue24014] Second pass of PyCode_Optimize

[Brett Cannon]

Brett Cannon added the comment:

Just FYI, http://bugs.python.org/issue11549 can act as a tracking issue for an 
AST optimization path that runs prior to the peepholer.

--
nosy: +brett.cannon

___
Python tracker 

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

[issue23863] Fix EINTR Socket Module issues in 2.7

[STINNER Victor]

STINNER Victor added the comment:

See also issue #20611 "socket.create_connection() doesn't handle EINTR 
properly" which was closed as duplicated of this issue.

I'm not sure that #20611 is a duplicate.

--

___
Python tracker 

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

[issue23496] Steps for Android Native Build of Python 3.4.2

[Ryan Gonzalez]

Ryan Gonzalez added the comment:

Nevermind. I was just being stupid. I kept searching the "Python" directory
for references to get_codec_name and _PyMem_RawStrdup and completely missed
the Programs directory. Sorry.

Did the updated kbox_fix.patch work?

--

___
Python tracker 

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

[issue23998] PyImport_ReInitLock() doesn't check for allocation error

[Christian Heimes]

Christian Heimes added the comment:

Thanks, Brett!

--
resolution:  -> fixed
stage: commit 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

[issue23917] please fall back to sequential compilation when concurrent doesn't exist

[Brett Cannon]

Brett Cannon added the comment:

LGTM

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

[issue24014] Second pass of PyCode_Optimize

[Christian Heimes]

Christian Heimes added the comment:

How about restricting double pass optimization to code objects that have the 
CO_OPTIMIZED bit set? It doesn't affect normal code execution.

--
nosy: +christian.heimes

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Raymond Hettinger]

Raymond Hettinger added the comment:

> My point was about consistency in descriptor handling, not consistency
> of fault (eg: broken everywhere). I don't understand why that's not 
> clear here.

That is clear but also isn't sufficient motivation.  The proposed change is 
unnecessary and not rooted in real use cases.  It is a semantic change to a 
long-standing view that callable() means having a __call__ method.

> The big idea here is to harmonize capability checking with descriptor 
> handling.

That isn't what Guido intended when he designed the capability checking.  He 
has a remarkably good instinct for avoiding language complexity when there 
aren't clear-cut benefits.

> http://blog.ionelmc.r

Please stop using the bug tracker to post links to your blog.

--

___
Python tracker 

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

[issue24015] timeit should start with 1 loop, not 10

[Martin Panter]

Changes by Martin Panter :


--
nosy: +vadmium

___
Python tracker 

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

[issue24014] Second pass of PyCode_Optimize

[Raymond Hettinger]

Raymond Hettinger added the comment:

I would like to keep the time spent in the optimizer itself to a minimum.  
Also, it should keep focused on patterns that actually occur in code as opposed 
to contrived bits of code.   Tim and Guido let us put it the optimizer only on 
the condition that it be kept simple and with low overhead.   The work that has 
been needed for a long time was to move a number of the optimizations (such as 
constant folding) out of the peepholer optimizer and replace them with AST 
manipulations just upstream from code generation (to reduce the need for the 
peepholer to partially disassemble and re-interpret the bytecode).

--
nosy: +rhettinger

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Eric Snow]

Eric Snow added the comment:

FYI, I'll re-iterate something I said before, there is a different approach you 
can take here if this is just an issue of proxying.  Use two different proxy 
types depending on if the proxied object is callable or not:


class Proxy:
# all the proxy stuff...


class CallableProxy(Proxy):
def __call__(self, *args, **kwargs):
...


def proxy(obj):
if callable(obj):
return CallableProxy(obj)
else:
return Proxy(obj)


If that isn't a viable alternative then please explain your use case in more 
detail.  I'm sure we can find a solution that works for you.

--

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Eric Snow]

Eric Snow added the comment:

> Ionel Cristian Mărieș added the comment:
> Also, descriptors are a core mechanism in new-style classes - you can't
> have methods without descriptors. Why would you even consider removing
> descriptors from the special method lookup if that's part of the object
> model design?

Also, we are not changing anything here and we are not considering
removing descriptors from special method lookup.  This is the way it
has been for a long time for code that *checks* for special method
capability.  As RDM and I have both said, changing that would break
backward compatibility.  As I've already explained, I also think it is
wrong.

--

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[R. David Murray]

R. David Murray added the comment:

Because special methods are special.

--

___
Python tracker 

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

[issue24014] Second pass of PyCode_Optimize

[Yury Selivanov]

Yury Selivanov added the comment:

Is there any noticeable performance increase with the patch?

Please attach results from https://hg.python.org/benchmarks

--
nosy: +yselivanov

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Ionel Cristian Mărieș]

Ionel Cristian Mărieș added the comment:

Also, descriptors are a core mechanism in new-style classes - you can't
have methods without descriptors. Why would you even consider removing
descriptors from the special method lookup if that's part of the object
model design?

On Monday, April 20, 2015, Ionel Cristian Mărieș 
wrote:

>
> Ionel Cristian Mărieș added the comment:
>
> My point was about consistency in descriptor handling, not consistency of
> fault (eg: broken everywhere). I don't understand why that's not clear
> here.
>
> The big idea here is to harmonize capability checking with descriptor
> handling. Justifying breakage in callable with breakage in
> collections.Callable serves it no justice.
>
> On Monday, April 20, 2015, R. David Murray  > wrote:
>
> >
> > R. David Murray added the comment:
> >
> > I in case it wasn't clear, I closed this not because of my "case closed"
> > statement, but because as Eric pointed out we *do* have consistency here:
> > things which check *capabilities* (as opposed to actually *using* the
> > special methods), like callable and Iterable, only look for the existence
> > of the method, consistently.  The fact that you can then get an
> > AttributeError later when actually using the method is unfortunate, but
> > there really isn't anything sensible to be done about it, due to backward
> > compatibility concerns.
> >
> > --
> >
> > ___
> > Python tracker  >
> > 
> > ___
> >
>
> --
>
> Thanks,
> -- Ionel Cristian Mărieș, http://blog.ionelmc.ro
>
> --
>
> ___
> Python tracker >
> 
> ___
>

-- 

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

--

___
Python tracker 

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

[issue23863] Fix EINTR Socket Module issues in 2.7

[R. David Murray]

R. David Murray added the comment:

Is there a bug being fixed here? I mean other than socket not handling EINTR, 
where I think we agree that handling it is a feature, given the PEP.

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

[issue23990] Callable builtin doesn't respect descriptors

[Ionel Cristian Mărieș]

Ionel Cristian Mărieș added the comment:

My point was about consistency in descriptor handling, not consistency of
fault (eg: broken everywhere). I don't understand why that's not clear
here.

The big idea here is to harmonize capability checking with descriptor
handling. Justifying breakage in callable with breakage in
collections.Callable serves it no justice.

On Monday, April 20, 2015, R. David Murray  wrote:

>
> R. David Murray added the comment:
>
> I in case it wasn't clear, I closed this not because of my "case closed"
> statement, but because as Eric pointed out we *do* have consistency here:
> things which check *capabilities* (as opposed to actually *using* the
> special methods), like callable and Iterable, only look for the existence
> of the method, consistently.  The fact that you can then get an
> AttributeError later when actually using the method is unfortunate, but
> there really isn't anything sensible to be done about it, due to backward
> compatibility concerns.
>
> --
>
> ___
> Python tracker >
> 
> ___
>

-- 

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

--

___
Python tracker 

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

[issue24015] timeit should start with 1 loop, not 10

[Joachim Breitner]

New submission from Joachim Breitner:

The docs for the timeit command line interface specify

If -n is not given, a suitable number of loops is calculated by trying 
successive powers of 10 until the total time is at least 0.2 seconds.

This sounds as if it it first tries 1, then 10, then 100 etc. But the code 
starts with 10 iterations. So even if the tested code already takes long enough 
(e.g. because it is a suitable loop itself), timit will by default test 10 
loops.

I propose to change that, and replace

# determine number so that 0.2 <= total time < 2.0
for i in range(1, 10):
number = 10**i

with

# determine number so that 0.2 <= total time < 2.0
for i in range(0, 10):
number = 10**i

in Lib/timeit.py.

--
components: Library (Lib)
messages: 241643
nosy: nomeata
priority: normal
severity: normal
status: open
title: timeit should start with 1 loop, not 10
versions: Python 2.7

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[R. David Murray]

R. David Murray added the comment:

I in case it wasn't clear, I closed this not because of my "case closed" 
statement, but because as Eric pointed out we *do* have consistency here: 
things which check *capabilities* (as opposed to actually *using* the special 
methods), like callable and Iterable, only look for the existence of the 
method, consistently.  The fact that you can then get an AttributeError later 
when actually using the method is unfortunate, but there really isn't anything 
sensible to be done about it, due to backward compatibility concerns.

--

___
Python tracker 

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

[issue23496] Steps for Android Native Build of Python 3.4.2

[Cyd Haselton]

Cyd Haselton added the comment:

FYI, I'm on commit c917493dc4ea2c32371da861aca2235f0a08e68e

--

___
Python tracker 

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

[issue24014] Second pass of PyCode_Optimize

[Eric Snow]

Eric Snow added the comment:

> Also, Python/importlib.h blew up in the diff; should this be included in
the patch?

Yes.  It is the frozen bytecode for bootstrapping importlib as the import
system.  So changes to bytecode generation like this will propagate there.

--
nosy: +eric.snow

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[R. David Murray]

R. David Murray added the comment:

The only 'consistency' fix that would make any sense, IMO, would be to disallow 
special methods to be descriptors.  We can't do that for backward compatibility 
reasons, so that's pretty much case closed.

Eric already mentioned one of the other 'capability' helpers:

rdmurray@pydev:~/python/p35>./python 
Python 3.5.0a3+ (default:5612dc5e6af9+, Apr 16 2015, 11:29:58) 
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo:
... @property
... def __iter__(self):
... raise AttributeError
... 
>>> f = Foo
>>> from collections.abc import Iterable
>>> issubclass(Foo, Iterable)
True

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

[issue23975] numbers.Rational implements __float__ incorrectly

[Wolfgang Maier]

Wolfgang Maier added the comment:

> Is it not reasonable to simply say that implementations of numbers.Rational 
> which allow the numerator and denominator to have types for which true 
> division doesn't return a float, have to provide their own implementation of 
> __float__()?

Unfortunately, the Rational type cannot always know what its numerator or 
denominator supports.
Look at fractions.Fraction: its only requirement for numerator and denominator 
is that they both should be Rational instances.
So a hypothetical MyInt like Mark describes it could be perfectly acceptable 
for Fraction except that it would fail to convert it to float.
 
> It's certainly less convenient, and probably surprising for users, but the 
> alternative is trying to work around broken integer types - after all 
> numbers.Complex.__truediv__ says "Should promote to float when necessary" in 
> the docstring, which to me says that a type where a/b doesn't return a float 
> doesn't conform to the numeric tower.
> 

I do read this docstring differently. To me, it means should promote to float 
if there is no other way to express the result (like when your custom type 
system does not define its own Float type).
It would, in fact, be really bad for custom type implementors if they would be 
forced to leave their type system when doing divisions.

> Alternatively, return int(self.numerator) / int(self.denominator). After all, 
> a fraction whose numerator can't be represented as a Python (unlimited 
> precision) integer is a pretty odd sort of fraction...

The problem here is that self.numerator and/or self.denominator could both be 
Rational instances again, which are not expressible as a Python integer and, 
thus, are not enforced to provide __int__ by the numbers ABC.

--

___
Python tracker 

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

[issue23975] numbers.Rational implements __float__ incorrectly

[Paul Moore]

Paul Moore added the comment:

Alternatively, return int(self.numerator) / int(self.denominator). After all, a 
fraction whose numerator can't be represented as a Python (unlimited precision) 
integer is a pretty odd sort of fraction...

--

___
Python tracker 

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

[issue23975] numbers.Rational implements __float__ incorrectly

[Paul Moore]

Paul Moore added the comment:

Is it not reasonable to simply say that implementations of numbers.Rational 
which allow the numerator and denominator to have types for which true division 
doesn't return a float, have to provide their own implementation of __float__()?

It's certainly less convenient, and probably surprising for users, but the 
alternative is trying to work around broken integer types - after all 
numbers.Complex.__truediv__ says "Should promote to float when necessary" in 
the docstring, which to me says that a type where a/b doesn't return a float 
doesn't conform to the numeric tower.

--
nosy: +paul.moore

___
Python tracker 

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

[issue23975] numbers.Rational implements __float__ incorrectly

[Wolfgang Maier]

Wolfgang Maier added the comment:

Good point.

If the numbers ABC guaranteed numerator and denominator to be Integral numbers, 
this could be solved by:

return float(int(self.numerator) / int(self.denominator))

but since both could be Rationals again that does not seem to be an option 
either.
What could be done is trying to multiply out the numerator and denominator pair 
until both *are* Integrals, like:

num = self.numerator
den = self.denominator
while not (isinstance(num, Integral) and isinstance(den, Integral)):
num = num.numerator * den.denominator
den = den.numerator * num.denominator
return float(int(num) / int(den))

Clearly that's more complicated, but, more importantly, has the disadvantage 
that the loop will run forever if the final numerator or denominator is not 
registered correctly in the numeric tower.
So some kind of check for this situation would be required, but I do not have 
an idea right now what that should look like.

--

___
Python tracker 

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

[issue20362] longMessage attribute is ignored in unittest.TestCase.assertRegexpMatches etc

[Ilia Kurenkov]

Ilia Kurenkov added the comment:

Hi Berker!

I hope all's well on your end. Let me know if you have questions about the 
reasoning behind my changes.

--

___
Python tracker 

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

[issue23496] Steps for Android Native Build of Python 3.4.2

[Cyd Haselton]

Cyd Haselton added the comment:

Ryan,
There's not a python.c in the ./Programs file?

--

___
Python tracker 

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

[issue6824] help for a module should list supported platforms

[Mark Lawrence]

Mark Lawrence added the comment:

As there was no reply to msg109130 (nearly five years ago) can we close this as 
won't fix?

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue10308] Modules/getpath.c bugs

[Mark Lawrence]

Mark Lawrence added the comment:

Reading msg120918 and msg120940 it looks as if work has been completed so this 
can be closed as fixed.

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue7018] Recommend "*" over "#" in getargs.c typecodes

[Mark Lawrence]

Mark Lawrence added the comment:

The 3.x arg.html seems a great improvement to my eye compared to the 2.x 
version so I'd guess this can be closed as out of date.

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue16840] Tkinter doesn't support large integers

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8ab077c22fbf by Serhiy Storchaka in branch '2.7':
Issue #16840: Turn on support of bignums only in final release of Tcl 8.5.
https://hg.python.org/cpython/rev/8ab077c22fbf

New changeset 7f1622478d17 by Serhiy Storchaka in branch '3.4':
Issue #16840: Turn on support of bignums only in final release of Tcl 8.5.
https://hg.python.org/cpython/rev/7f1622478d17

New changeset 7a7f09528866 by Serhiy Storchaka in branch 'default':
Issue #16840: Turn on support of bignums only in final release of Tcl 8.5.
https://hg.python.org/cpython/rev/7a7f09528866

--

___
Python tracker 

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

[issue23908] Check path arguments of os functions for null character

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The patch for 2.7 should be different and more complex. First at all, "s" and 
"u" format units don't check for null character (but "et" and "es" used in Unix 
implementations of os functions do).

--
stage: patch review -> needs patch
versions: +Python 2.7 -Python 3.4, Python 3.5

___
Python tracker 

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

[issue16840] Tkinter doesn't support large integers

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

There is at least one buildbot that now fails to build _tkinter.

http://buildbot.python.org/all/builders/x86%20FreeBSD%206.4%202.7/builds/2457/steps/test/logs/stdio
building '_tkinter' extension
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes 
-DWITH_APPINIT=1 -I/usr/local/include/tcl8.5 -I/usr/local/include/tk8.5 
-I/usr/X11R6/include -I. -IInclude -I./Include -I/usr/local/include 
-I/usr/home/db3l/buildarea/2.7.bolen-freebsd/build/Include 
-I/usr/home/db3l/buildarea/2.7.bolen-freebsd/build -c 
/usr/home/db3l/buildarea/2.7.bolen-freebsd/build/Modules/_tkinter.c -o 
build/temp.freebsd-6.4-RELEASE-i386-2.7-pydebug/usr/home/db3l/buildarea/2.7.bolen-freebsd/build/Modules/_tkinter.o
/usr/home/db3l/buildarea/2.7.bolen-freebsd/build/Modules/_tkinter.c:101:24: 
tclTomMath.h: No such file or directory

--
status: closed -> open

___
Python tracker 

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

[issue23863] Fix EINTR Socket Module issues in 2.7

[koobs]

Changes by koobs :


--
nosy: +koobs

___
Python tracker 

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

[issue23882] unittest discovery doesn't detect namespace packages when given no parameters

[Alex Shkop]

Alex Shkop added the comment:

Thanks. I understand the code pretty well and I saw issue17457 that fixes 
discovery for explicitly specified namespace package.

What I need is to know how discovery has to work. Do we need to discover 
namespace packages inside discovery path? And should we do that recursively? 
I.e. should we pick namespace packages inside namespace packages? This will 
lead to recursive scan of all directories under discovery path.

--

___
Python tracker 

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