[issue30346] Odd behavior when unpacking `itertools.groupby`
Matthew Gilson added the comment:
Tracking which group the grouper _should_ be on using an incrementing integer
seems to work pretty well.
In additional to the tests in `test_itertools.py`, I've gotten the following
tests to pass:
class TestGroupBy(unittest.TestCase):
def test_unpacking(self):
iterable = 'AB'
(_, a), (_, b) = groupby(iterable)
self.assertEqual(list(a), [])
self.assertEqual(list(b), [])
def test_weird_iterating(self):
g = groupby('AB')
_, a = next(g)
_, b = next(g)
_, aa = next(g)
self.assertEqual(list(a), [])
self.assertEqual(list(b), [])
self.assertEqual(list(aa), list('A'))
If I was to submit this as a PR,
1. where would I want to add these tests?
2. should I update the documentation for the "equivalent" python version to
match exactly?
--
keywords: +patch
Added file: http://bugs.python.org/file46860/groupby-fix.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30346>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30346] Odd behavior when unpacking `itertools.groupby`
Matthew Gilson added the comment: Oops. You don't need to pass `self.currvalue` to `_grouper`. I didn't end up using it in there... -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30346] Odd behavior when unpacking `itertools.groupby`
Matthew Gilson added the comment:
I think that works to solve the problem that I pointed out. In my stack
overflow question (http://stackoverflow.com/a/43926058/748858) it has been
pointed out that there are other opportunities for weirdness here.
Specifically, if if I skip processing 2 groups and then I process a third group
whose key is the same as the first:
inputs = [(x > 5, x) for x in range(10)]
inputs += [(False, 10), (True, 11)]
g = groupby(inputs2 + [(True, 11)], key=itemgetter(0))
_, a = next(g)
_, b = next(g)
_, c = next(g)
print(list(a))
print(list(b))
Both `a` and `b` should probably be empty at this point, but they aren't.
What if you kept track of the last iterable group and just consumed it at
whenever `next` is called? I think then you also need to keep track of whether
or not the input iterable has been completely consumed, but that's not too bad
either:
_sentinel = object()
class groupby:
# [k for k, g in groupby('BBBCCDAABBB')] --> A B C D A B
# [list(g) for k, g in groupby('BBBCCD')] --> BBB CC D
def __init__(self, iterable, key=None):
if key is None:
key = lambda x: x
self.keyfunc = key
self.it = iter(iterable)
self.last_group = self.currkey = self.currvalue = _sentinel
self.empty = False
def __iter__(self):
return self
def __next__(self):
if self.last_group is not _sentinel:
for _ in self.last_group:
pass
if self.empty:
raise StopIteration
if self.currvalue is _sentinel:
try:
self.currvalue = next(self.it)
except StopIteration:
self.empty = True
raise
self.currkey = self.keyfunc(self.currvalue)
self.last_group = self._grouper(self.currkey, self.currvalue)
return (self.currkey, self.last_group)
def _grouper(self, tgtkey, currvalue):
while self.currkey == tgtkey:
yield self.currvalue
try:
self.currvalue = next(self.it)
except StopIteration:
self.empty = True
return
self.currkey = self.keyfunc(self.currvalue)
I haven't tested this to make sure it passes the test suite -- I also don't
know if this would have major performance implications or anything. If it did
have severe performance implications, then it probably isn't worthwhile...
--
nosy: +mgilson
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30346>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27470] -3 commandline option documented differently via man
New submission from Matthew Gilson:
The man page for python says:
> Warn about Python 3.x incompatibilities that 2to3 cannot trivially fix.
The official documentation
(https://docs.python.org/2/using/cmdline.html#cmdoption-3) does not mention
2to3 at all:
> Warn about Python 3.x possible incompatibilities by emitting a
> DeprecationWarning for features that are removed or significantly changed in
> Python 3.
This seems like a pretty big oversight when the following code issues no
warnings (presumably because 2to3 can trivially handle this change):
```
from __future__ import print_function
class test(object):
def __nonzero__(self):
return False
t = test()
if t:
print('Hello')
```
--
assignee: docs@python
components: Documentation
messages: 269994
nosy: docs@python, mgilson
priority: normal
severity: normal
status: open
title: -3 commandline option documented differently via man
versions: Python 2.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27470>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21746] urlparse.BaseResult no longer exists
New submission from Matthew Gilson: The BaseResult has been replaced by namedtuple. This also opens up all of the documented methods on namedtuple which would be nice to have as part of the API. I've taken a stab and re-writing the docs here. Feel free to use it (or not)... -- files: python_doc_patch.patch keywords: patch messages: 220425 nosy: mgilson priority: normal severity: normal status: open title: urlparse.BaseResult no longer exists Added file: http://bugs.python.org/file35612/python_doc_patch.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21746 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21746] urlparse.BaseResult no longer exists
Changes by Matthew Gilson m.gils...@gmail.com: -- assignee: - docs@python components: +Documentation nosy: +docs@python versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21746 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21746] urlparse.BaseResult no longer exists
Matthew Gilson added the comment: Sorry, forgot to remove the mention of BaseResult ... -- Added file: http://bugs.python.org/file35613/python_doc_patch.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21746 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21746] urlparse.BaseResult no longer exists
Matthew Gilson added the comment: This originally came up on stackoverflow: http://stackoverflow.com/questions/24200988/modify-url-components-in-python-2/24201020?noredirect=1#24201020 Would it be helpful if I also added a simple example to the docs as in the example there? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21746 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19934] collections.Counter.most_common does not document `None` as acceptable input.
New submission from Matthew Gilson: Reading the source for collections.Counter.most_common, the docstring mentions that `n` can be `None` or omitted, but the online documentation does not mention that `n` can be `None`. -- assignee: docs@python components: Documentation messages: 205648 nosy: docs@python, mgilson priority: normal severity: normal status: open title: collections.Counter.most_common does not document `None` as acceptable input. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19934 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19934] collections.Counter.most_common does not document `None` as acceptable input.
Matthew Gilson added the comment: This is a very simple patch which addresses the issue. I am still curious whether the reported function signature should be changed from: .. method:: most_common([n]) to: .. method:: most_common(n=None) . Any thoughts? Also, while I was in there, I changed a few *None* to ``None`` for consistency with the rest of the documentation. -- keywords: +patch Added file: http://bugs.python.org/file33050/mywork.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19934 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
