[issue22687] horrible performance of textwrap.wrap() with a long word
Changes by Ben Roberts bjr.robe...@gmail.com: -- nosy: +roippi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22687 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19119] duplicate test name in Lib/test/test_heapq.py
Ben Roberts added the comment: Any thoughts/reviews on the patch? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19119 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19119] duplicate test name in Lib/test/test_heapq.py
Ben Roberts added the comment: That is one approach, of course, but imo pretty incomplete. A test that is named test_get_only presumably would be expected to test __getitem__, not __cmp__. Confusingly there is still a GetOnly item declared in the module, but it is not used. Compare to test_len_only, which has a paired LenOnly class and test name. Either GetOnly should be completely excised from the module and the test renamed to test_cmp_only (alternately test_cmp_err), or the GetOnly class should be fixed as in my patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19119 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22454] Adding the opposite function of shlex.split()
Ben Roberts added the comment: ' '.join(shlex.quote(x) for x in split_command) -- nosy: +roippi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22454 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22454] Adding the opposite function of shlex.split()
Ben Roberts added the comment: For the record I am on board with a shlex.join. Even though the implementation is simple: - It is not obvious to many users if there are any gotchas by doing a ' '.join yourself, /even if/ you know that strings with spaces in them need to pass through shlex.quote first. - The symmetry of shlex.split and shlex.join is obvious - I don't need to read any documentation to know that they are inverse operations. - batteries included, one obvious way, and all that. -- versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22454 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19119] duplicate test name in Lib/test/test_heapq.py
Ben Roberts added the comment: The major issue (there are other issues as well but not so difficult) is whether nlargest and nsmallest should support iterator that could be endless iterator or reject it (by checking __len__ attribute) straight away. Well, failing with an exception isn't right. I can imagine doing (and probably have done, at some point) nlargest on any number of generators, streams of data, etc. So unless anyone can solve the halting problem (:-)) the behavior of nlargest is correct as possible; nlargest(2, GetOnly()) behaves just like list(GetOnly()) - they both hang forever. The proper action here is just a fix in the tests: make GetOnly raise IndexError at some point so that it is a proper sequence. (also rename the second test to get_cmp_only) -- nosy: +roippi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19119 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19119] duplicate test name in Lib/test/test_heapq.py
Ben Roberts added the comment: Attached patch fixes the tests. -- Added file: http://bugs.python.org/file36683/fix_heapq_tests.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19119 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22192] dict_values objects are hashable
Ben Roberts added the comment: Going to close this down - implementing rich comparisons for values() does feel like the correct solution... but I don't think it's possible to implement __eq__ in better than nlogn time (and possibly space). So nothing can realistically be done, yeah. -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22192 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2527] Pass a namespace to timeit
Ben Roberts added the comment: Thanks Antoine. Cheers :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2527 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2527] Pass a namespace to timeit
Ben Roberts added the comment: I did sign one right after I submitted the patch. Takes a few days for the asterisks to propagate I guess :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2527 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2527] Pass a namespace to timeit
Ben Roberts added the comment: Ah yes. New patch improves the docs. -- Added file: http://bugs.python.org/file36432/timeit_global_arg_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2527 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2527] Pass a namespace to timeit
Ben Roberts added the comment: Attached is a patch that adds a 'global' kwarg to the Timeit constructor, which does pretty much what it says on the tin: specifies a global namespace that exec() will use. I originally had a 'locals' arg as well (to mirror the signature of eval/exec), but realized that the local vars I was passing to exec were not available to the inner function. Reason: the timeit module compiles/execs a *closure*, and closed-over variables and exec() simply do not play nicely. Possible workarounds were to munge locals() into the globals() dict, or to somehow inject the variables in the locals dict into the closure. I found neither of these options superior to simply not including a locals argument, for reasons of Least Surprise and maintainability. Patch includes some basic tests and documentation. I am particularly uncomfortable with writing docs so those very likely need some polish. -- keywords: +patch Added file: http://bugs.python.org/file36409/timeit_global_arg.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2527 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2527] Pass a namespace to timeit
Ben Roberts added the comment: Correction, the name of the argument is 'globals', not 'global'. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2527 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2527] Pass a namespace to timeit
Changes by Ben Roberts bjr.robe...@gmail.com: -- nosy: +roippi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2527 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22192] dict_values objects are hashable
Ben Roberts added the comment: I have a patch with tests for this (running the test suite now) but I am increasingly unsure if python isn't doing the right thing already. Intuitively, it feels wrong (to me) to allow a dict_values view to be hashable since the mapping onto which it provides a view is certainly mutable. And mutable things shouldn't be hashable, everyone knows that. However the dict_values object /itself/ doesn't violate the contract of hashability - its hash (which just uses its id()) doesn't change across its lifetime, and some_values_view == foo will only be true iff foo is some_values_view whereas e.g. some_keys_view == some_other_keys_view CAN change across the lifetime of those objects - so the asymmetry here does make sense. It is taking me a while to wrap my brain around this because I often think in terms of mutable/immutable but the only thing that's important is the hashability contract, which is not currently violated by dict_values objects. I'm certainly willing to be talked out of my change of opinion here :-), my intuition hasn't fully caught up with my logic. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22192 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22192] dict_values objects are hashable
New submission from Ben Roberts:
In python 3.4 these result in a TypeError:
hash({}.keys())
hash({}.items())
But this succeeds:
hash({}.values())
The 2.7 backports of these - viewkeys, viewitems, and viewvalues respectively -
behave equivalently.
See more discussion on StackOverflow:
http://stackoverflow.com/questions/25293912/why-are-some-dict-views-hashable
The cause appears to be that key and item views implement rich comparisons,
whereas values views do not. Therefore dict_view objects use the default
id()-based __hash__ implementation.
Possible fix: explicitly set tp_hash to PyObject_HashNotImplemented for
PyDictValues_Type - and perhaps for the other two view types as well, for
symmetry.
--
components: Interpreter Core
messages: 225287
nosy: roippi
priority: normal
severity: normal
status: open
title: dict_values objects are hashable
type: behavior
versions: Python 2.7, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22192
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
