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 t
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
'
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
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 cr
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 t
Martin Häcker added the comment:
It really should return self.
--
___
Python tracker
<http://bugs.python.org/issue13805>
___
___
Python-bugs-list mailin
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.
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
Martin Häcker added the comment:
Jup - oh the joys of writing code in a bugtracker :)
--
___
Python tracker
<http://bugs.python.org/issue13804>
___
___
Python-bug
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:
Changes by Martin Häcker :
--
title: dict() in dict(foo='bar') raises -> dict() in dict(foo='bar').keys()
raises
___
Python tracker
<http://
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 t
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 c
13 matches
Mail list logo
