[issue20190] dict() in dict(foo='bar').keys() raises
Martin Häcker added the comment: Well, if that's the case, then this bug indeed can be closed. You switched from list as the base type to set and that has to be dealt with on application side. Still this is surprising, but there's not much that can be done. :-( -- ___ Python tracker <http://bugs.python.org/issue20190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20190] dict() in dict(foo='bar').keys() raises
Martin Häcker added the comment: Sorry, I got the title wrong on the first try. (Already corrected). I think the problem is that the API of dict.keys() is surprising. One gets back something that behaves like a list, the name 'keys' suggests that it is a list and for lists there is no requirement that their containing items need to be hasheable. Now of course it makes no sense to check if a dict (not washable because it's mutable) is a key in a dictionary - but, the fact that keys() returns something else than a list is surprising and shouldn't be so. (I suspect it's a performance enhancement). Why this shouldn't be so? I think it's because of composeability. If I expect something list like from an API I want to be able to hand it around in my application to everywhere where a list is allowed, and I certainly don't want to check beforehand if something I want to check is included in that list is hasheable for a specific subset of those lists. Thats why I think it's a really bad idea to change the behavior of dict.keys() _not_ to return a list or something that at least behaves the same way as a list. Should this have been done for performance reasons, it would be easy to say in that list that anything that is not hasheable cannot be in that list and therefore to return False in that case. Contract fulfilled. -- ___ Python tracker <http://bugs.python.org/issue20190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20190] dict() in dict(foo='bar').keys() raises
Changes by Martin Häcker : -- title: dict() in dict(foo='bar') raises -> dict() in dict(foo='bar').keys() raises ___ Python tracker <http://bugs.python.org/issue20190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20190] dict() in dict(foo='bar') raises
New submission from Martin Häcker: I was quite surprised by this behavior: >>> dict() in [dict()] True >>> dict() in [] False >>> dict() in dict(foo='bar').keys() Traceback (most recent call last): File "", line 1, in TypeError: unhashable type: 'dict' >>> dict() in list(dict(foo='bar').keys()) False I think it should change. Calling dict.keys() one expects to get list like behavior and not having to ensure that everything that is checked for inclusion there has to be hasheable. If it helps, this is also a regression from python 2.6/7 where this works as expected. -- messages: 207683 nosy: dwt priority: normal severity: normal status: open title: dict() in dict(foo='bar') raises versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue20190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13804] Python library structure creates hard to read code when using higher order functions
Martin Häcker added the comment: Jup - oh the joys of writing code in a bugtracker :) -- ___ Python tracker <http://bugs.python.org/issue13804> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13804] Python library structure creates hard to read code when using higher order functions
Martin Häcker added the comment: @stutzbach: I believe you got me wrong, as the example topic.questions is meant to return a list of questions that need concatenating - thus you can't save the second step. -- ___ Python tracker <http://bugs.python.org/issue13804> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13804] Python library structure creates hard to read code when using higher order functions
Martin Häcker added the comment: Yes - however it has the same problem as the higher order version in the python libraries that to read it you need to constantly jump back and forth in the line. -- ___ Python tracker <http://bugs.python.org/issue13804> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13805] [].sort() should return self
Martin Häcker added the comment: It really should return self. -- ___ Python tracker <http://bugs.python.org/issue13805> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13805] [].sort() should return self
New submission from Martin Häcker : [].sort() returns None which means you can't chain it. So for example someDict.keys().sort()[0] doesn't work but you have to use sorted(someDict.keys())[0] instead which is harder to read as you have to read the line not from the beginning to the end but jump back and forth in it to understand it (which gets progressively harder as the individual parts of it get longer / more complex). -- messages: 151439 nosy: dwt priority: normal severity: normal status: open title: [].sort() should return self type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue13805> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13804] Python library structure creates hard to read code when using higher order functions
New submission from Martin Häcker :
Code that uses higher order methods is often the clearest description of what
you want to do. However since the higher order methods in python (filter, map,
reduce) are free functions and aren't available on collection classes as
methods, using them creates really hard to read code.
For example, if I want to get an attribute out of an array of objects and
concatenate the results it's two steps, get the attributes out of the object,
then concatenate the results.
Without higher order methods its like this. Uses three lines, intermediate
variable is quite clear, but hard to compose and hard to abstract out parts of
it.
self.questions = []
for topic in self.topics:
self.questions.append(topic.questions)
if I want to do it with higher order functions there's really two ways, do it
in one step with reduce:
self.questions = reduce(lambda memo, topic: memo + topic.questions,
self.topics, [])
Or use two steps with the operator module
self.questions = reduce(operator.add, map(operator.attrgetter('questions'),
self.topics), [])
Of these thee first still couples two steps into one lambda, while the second
one decoples everything nicely but is a total train wreck to read, as you need
to constantly jump back and forth in the line to understand what it does.
Having map and reduce defined on collections would not only make it drastically
shorter but also allows you to read it from front to back in one go. (Ok, there
is still the caveat that the assignment is in the front instead of at the end,
but hey)
self.questions = self.topics.map(attrgetter('questions')).reduce(add, [])
That would be nicely separated into individual steps that exactly describe what
each step is actually doing, is easy to abstract over and actually very
succinct.
--
messages: 151435
nosy: dwt
priority: normal
severity: normal
status: open
title: Python library structure creates hard to read code when using higher
order functions
type: enhancement
___
Python tracker
<http://bugs.python.org/issue13804>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13599] Compiled regexes don't show all attributes in dir()
Martin Häcker added the comment: Indeed, I'm on version % python --version Python 2.7.1 Sorry. -- status: pending -> closed ___ Python tracker <http://bugs.python.org/issue13599> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13599] Compiled regexes don't show all attributes in dir()
New submission from Martin Häcker :
When looking at a regex with dir() you don't get all available attributes -
which is inconvenient as some very important ones (like .pattern) are not
visible.
To demonstrate:
> import re
> re.compile('foo').pattern
'foo'
> dir(re.compile('foo'))
['__copy__',
'__deepcopy__',
'findall',
'finditer',
'match',
'scanner',
'search',
'split',
'sub',
'subn']
--
components: Regular Expressions
messages: 149428
nosy: dwt, ezio.melotti
priority: normal
severity: normal
status: open
title: Compiled regexes don't show all attributes in dir()
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue13599>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13592] repr(regex) doesn't include actual regex
New submission from Martin Häcker :
When calling repr() on a compiled regex pattern like this:
> import re
> repr(re.compile('foo'))
you don't get the pattern of the regex out of the compiled form. Also all my
research has shown no getter to allow this.
I noticed this in my application because I was unable to show good error
messages for things involving regexes, which is a shame.
So please add the actual regex to the repr() form of the compiled regex, or
alternatively provide a getter / property to get at it.
--
messages: 149382
nosy: dwt
priority: normal
severity: normal
status: open
title: repr(regex) doesn't include actual regex
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue13592>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
