[issue18032] set methods should specify whether they consume iterators "lazily"

[Abafei]

New submission from Abafei:

It says here 
(http://docs.python.org/2/library/stdtypes.html#set-types-set-frozenset) that 
some of the set methods take iterables as a parameter.

Usually, the expected behavior is for a iterator consumer to consume only as 
much data as it needs. For example, for the code `any(itertools.repeat(True))`, 
the code will complete speedily, in contrast to when all() is used instead of 
any(), in which case the code will go forever.

A least some of the set methods have semantics such that they can consume only 
some of the input; for example, "issubset" only needs to make sure that all of 
the items in the set are in the iterable, and once this is the case, it can 
return "True".

However in such a case, the methods will *still* go forever.

The docs should specify that this is the case, to disambiguate the semantics.

(Tested on Python 3.2.3 and 2.7.3).

--
assignee: docs@python
components: Documentation
messages: 189806
nosy: Abafei, docs@python
priority: normal
severity: normal
status: open
title: set methods should specify whether they consume iterators "lazily"
type: behavior
versions: Python 2.7, Python 3.2

___
Python tracker 
<http://bugs.python.org/issue18032>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11381] pretending the "not" operator is a function behaves surprisingly

[Abafei]

New submission from Abafei :

I'm not sure if this is a bug per se, since I don't think pretending operators 
are callable is in the docs, but:

pretending an operator (at least the "not" operator) is callable, like so:
not(True)

can be surprising:
>>> (not 1) == 9
False

>>> not(1) == 9
True


Now, I know this is valid because Python is very lenient about whitespace (and 
the parenthenses are really just  "eval '1' first") , but, this is still 
confusing behavior to someone who does not know about that.

I think the same problem may be possible in the case of statements.

A possible solution is to make sure there is at least some white-space between 
"alphabetical" operators and statements.

--
messages: 129933
nosy: abafei
priority: normal
severity: normal
status: open
title: pretending the "not" operator is a function behaves surprisingly
type: behavior
versions: Python 2.6

___
Python tracker 
<http://bugs.python.org/issue11381>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com