Steven D'Aprano writes:
> You don't need the space between strings and the attribute access:
> "1".zfill(2) is fine. You only need it for numbers, due to the ambiguity
> between the decimal point and dotted attribute access.
Personally I prefer parentheses: (1).conjugate
--
Piet van Oostrum
On Thu, 12 Aug 2010 13:28:26 -0700, David Niergarth wrote:
> Peter Otten <__pete...@web.de> wrote:
>>
>> >>> 1 .conjugate()
>>
>>
> This is a syntax I never noticed before. My built-in complier (eyes)
> took one look and said: "that doesn't work." Has this always worked in
> Python but I never not
David Niergarth wrote:
> [Oops, now complete...]
> Peter Otten <__pete...@web.de> wrote:
>>
>> > >>> 1 .conjugate()
>>
> This is a syntax I never noticed before. My built-in complier (eyes)
> took one look and said: "that doesn't work."
(1).conjugate may hurt a little less. Anyway, the space is
[Oops, now complete...]
Peter Otten <__pete...@web.de> wrote:
>
> > >>> 1 .conjugate()
>
This is a syntax I never noticed before. My built-in complier (eyes)
took one look and said: "that doesn't work." Has this always worked in
Python but I never noticed? I see other instance examples also work.
Peter Otten <__pete...@web.de> wrote:
>
> >>> 1 .conjugate()
>
This is a syntax I never noticed before. My built-in complier (eyes)
took one look and said: "that doesn't work." Has this always worked in
Python but I never noticed? I see other instance examples also work.
>>> '1' .zfill(2)
'01
On 2010-07-31 05:47, Steven D'Aprano wrote:
> On Fri, 30 Jul 2010 08:34:52 -0400, wheres pythonmonks wrote:
> It does re-use the same underlying data.
>
> >>> from collections import defaultdict as dd
> >>> x = dd(list)
> >>> x[1].append(1)
> >>> x
> defaultdict(, {1: [1]})
> >>> y = dict(x)
> >>>
On 8/6/2010 6:24 PM, Wolfram Hinderer wrote:
This is probably nitpicking, but the patch calls __missing__ a special
method. However, unlike special methods, it is not invoked by "special
syntax" but by the dict's __getitem__ method. (len() invokes __len__
on any object - you can't do something s
On 6 Aug., 22:07, John Posner wrote:
> On 8/2/2010 11:00 PM, John Posner wrote:
>
> > On 7/31/2010 1:31 PM, John Posner wrote:
>
> >> Caveat -- there's another description of defaultdict here:
>
> >>http://docs.python.org/library/collections.html#collections.defaultdict
>
> >> ... and it's bogus.
On 8/2/2010 11:00 PM, John Posner wrote:
On 7/31/2010 1:31 PM, John Posner wrote:
Caveat -- there's another description of defaultdict here:
http://docs.python.org/library/collections.html#collections.defaultdict
... and it's bogus. This other description claims that __missing__ is a
method o
On 8/3/2010 6:48 PM, Ethan Furman wrote:
Christian Heimes wrote:
I just went and read the entry that had the bogus claim --
personally, I didn't see any confusion. I would like to point out the
__missing__ is *not* part of dicts (tested on 2.5 and 2.6 -- don't
have 2.7 installed yet).
I beg yo
Christian Heimes wrote:
Perhaps punctuation will help clarify my intent:
__missing__ is *not* part of (dict)s, as shown by dir(dict()):
Indeed, that's correct. Can we agree, that __missing__ is an optional
feature of the dict interface, that can be implemented in subclasses of
dict?
Absolute
> Perhaps punctuation will help clarify my intent:
>
> __missing__ is *not* part of (dict)s, as shown by dir(dict()):
Indeed, that's correct. Can we agree, that __missing__ is an optional
feature of the dict interface, that can be implemented in subclasses of
dict?
Christian
--
http://mail.pyt
Christian Heimes wrote:
I just went and read the entry that had the bogus claim -- personally, I
didn't see any confusion. I would like to point out the __missing__ is
*not* part of dicts (tested on 2.5 and 2.6 -- don't have 2.7 installed yet).
I beg your pardon but you are wrong. __missing__
> I just went and read the entry that had the bogus claim -- personally, I
> didn't see any confusion. I would like to point out the __missing__ is
> *not* part of dicts (tested on 2.5 and 2.6 -- don't have 2.7 installed yet).
I beg your pardon but you are wrong. __missing__ is available for al
John Posner wrote:
On 7/31/2010 1:31 PM, John Posner wrote:
Caveat -- there's another description of defaultdict here:
http://docs.python.org/library/collections.html#collections.defaultdict
... and it's bogus. This other description claims that __missing__ is a
method of defaultdict, not of
On 8/3/2010 5:47 PM, Christian Heimes wrote:
So I'd rather not mention __missing__ in the first paragraph, which
describes the functionality provided *by* the defaultdict class. How
about adding this para at the end:
defaultdict is defined using functionality that is available to *any*
sub
John Posner wrote:
On 8/3/2010 12:54 PM, Ethan Furman wrote:
I think mentioning how __missing__ plays into all this would be helpful.
Perhaps in the first paragraph, after the colon:
if a key does not currently exist in a defaultdict object, __missing__
will be called with that key, which in
> So I'd rather not mention __missing__ in the first paragraph, which
> describes the functionality provided *by* the defaultdict class. How
> about adding this para at the end:
>
> defaultdict is defined using functionality that is available to *any*
> subclass of dict: a missing-key lookup
On 8/3/2010 12:54 PM, Ethan Furman wrote:
I think mentioning how __missing__ plays into all this would be helpful.
Perhaps in the first paragraph, after the colon:
if a key does not currently exist in a defaultdict object, __missing__
will be called with that key, which in turn will call a "d
John Posner wrote:
On 7/31/2010 1:31 PM, John Posner wrote:
Caveat -- there's another description of defaultdict here:
http://docs.python.org/library/collections.html#collections.defaultdict
... and it's bogus. This other description claims that __missing__ is a
method of defaultdict, not of
On 7/31/2010 1:31 PM, John Posner wrote:
Caveat -- there's another description of defaultdict here:
http://docs.python.org/library/collections.html#collections.defaultdict
... and it's bogus. This other description claims that __missing__ is a
method of defaultdict, not of dict.
Following is
On 7/31/2010 2:00 PM, Christian Heimes wrote:
Your answer is confusing even me. ;)
Yeah, I get that a lot. :-)
Let me try an easier to understand explanation. defaultdict *implements*
__missing__() to provide the default dict behavior.
In my experience, the word *implements* is commonly u
> The truth, as Christian says above and as Raymond Hettinger recently
> pointed out [1], is that __missing__ is used to *define* defaultdict as
> a subclass of dict -- it's not used *by* defaultdict.
Your answer is confusing even me. ;)
Let me try an easier to understand explanation. defaultdi
On 7/31/2010 11:08 AM, Christian Heimes wrote:
... All you have to do is subclass dict and implement a
__missing__ method. See
http://docs.python.org/library/stdtypes.html?highlight=__missing__#mapping-types-dict
Caveat -- there's another description of defaultdict here:
http://docs.python.
Am 30.07.2010 14:34, schrieb wheres pythonmonks:
> I was hoping not to do that -- e.g., actually reuse the same
> underlying data. Maybe dict(x), where x is a defaultdict is smart? I
> agree that a defaultdict is safe to pass to most routines, but I guess
> I could imagine that a try/except block
I think of an upcast as casting to the base-class (casting up the
inheritance tree).
http://en.wiktionary.org/wiki/upcast
But really, what I am thinking of doing is overriding the virtual
methods of a derived class with the base class behavior in an object
that I can then pass into methods that are
On Sat, 31 Jul 2010 01:02:47 -0400, wheres pythonmonks wrote:
>> Hint -- what does [].append(1) return?
>>
>>
> Again, apologies from a Python beginner. It sure seems like one has to
> do gymnastics to get good behavior out of the core-python:
>
> Here's my proposed fix:
>
> m['key'] = (lambd
>
> Hint -- what does [].append(1) return?
>
Again, apologies from a Python beginner. It sure seems like one has
to do gymnastics to get good behavior out of the core-python:
Here's my proposed fix:
m['key'] = (lambda x: x.append(1) or x)(m.get('key',[]))
Yuck! So I guess I'll use defaultdic
On Fri, 30 Jul 2010 08:34:52 -0400, wheres pythonmonks wrote:
> Sorry, doesn't the following make a copy?
>
> from collections import defaultdict as dd x = dd(int)
> x[1] = 'a'
> x
>> defaultdict(, {1: 'a'})
> dict(x)
>> {1: 'a'}
>>
>>
>>
>
> I was hoping not to do that -- e.g.,
Sorry, doesn't the following make a copy?
from collections import defaultdict as dd
x = dd(int)
x[1] = 'a'
x
> defaultdict(, {1: 'a'})
dict(x)
> {1: 'a'}
>
>
I was hoping not to do that -- e.g., actually reuse the same
underlying data. Maybe dict(x), where x is a defaul
wheres pythonmonks wrote:
> Instead of defaultdict for hash of lists, I have seen something like:
>
>
> m={}; m.setdefault('key', []).append(1)
>
> Would this be preferred in some circumstances?
In some circumstances, sure. I just can't think of them at the moment.
Maybe if your code has to w
On Fri, 30 Jul 2010 07:59:52 -0400, wheres pythonmonks wrote:
> Instead of defaultdict for hash of lists, I have seen something like:
>
>
> m={}; m.setdefault('key', []).append(1)
>
> Would this be preferred in some circumstances?
Sure, why not? Whichever you prefer.
setdefault() is a venera
Instead of defaultdict for hash of lists, I have seen something like:
m={}; m.setdefault('key', []).append(1)
Would this be preferred in some circumstances?
Also, is there a way to upcast a defaultdict into a dict? I have also
heard some people use exceptions on dictionaries to catch key
existe
Peter Otten <__pete...@web.de> wrote:
> real is a property, not a method. conjugate() was the first one that
> worked that was not __special__. I think it has the added benefit that
> it's likely to confuse the reader...
>
Ah, silly me, I should have realised that.
Yes, micro-optimisations that a
Duncan Booth wrote:
> Peter Otten <__pete...@web.de> wrote:
>
> from collections import defaultdict
> d = defaultdict(1 .conjugate)
> d["x"] += 2
> d["x"]
>> 3
>>
>> Isn't that beautiful? Almost like home;)
>>
>> It is also fast:
>>
>> $ python -m timeit -s"one = lambda: 1" "on
Peter Otten <__pete...@web.de> wrote:
from collections import defaultdict
d = defaultdict(1 .conjugate)
d["x"] += 2
d["x"]
> 3
>
> Isn't that beautiful? Almost like home;)
>
> It is also fast:
>
> $ python -m timeit -s"one = lambda: 1" "one()"
> 100 loops, best of 3: 0.2
wheres pythonmonks wrote:
> How do I build an "int1" type that has a default value of 1?
> [Hopefully no speed penalty.]
> I am thinking about applications with collections.defaultdict.
>>> from collections import defaultdict
>>> d = defaultdict(1 .conjugate)
>>> d["x"] += 2
>>> d["x"]
3
Isn't t
On Thu, 29 Jul 2010 21:43:05 +0300, Nick Raptis wrote:
> On 07/29/2010 09:12 PM, wheres pythonmonks wrote:
>> How do I build an "int1" type that has a default value of 1?
> You mean something like:
> >>> x = int()
> >>> x
> 0
> >>> def myint(value=1):
> ... return int(value)
> ...
> >>> my
> Inheriting from "int" is not too helpful, because you can't assign
> to the value of the base class. "self=1" won't do what you want.
It's useful if you remember that you can set the default value by
overwriting __new__.
>>> class int1(int):
... def __new__(cls, value=1):
... retur
On 7/29/2010 11:12 AM, wheres pythonmonks wrote:
Why is the default value of an int zero?
x = int
print x
x()
0
How do I build an "int1" type that has a default value of 1?
>>> class int1(object) :
...def __init__(self) :
... self.val = 1
...def __call__(self) :
...
On 07/29/2010 09:12 PM, wheres pythonmonks wrote:
How do I build an "int1" type that has a default value of 1?
You mean something like:
>>> x = int()
>>> x
0
>>> def myint(value=1):
... return int(value)
...
>>> myint()
1
>>>
That's ugly on so many levels..
Anyway, basic types (and almost
Thanks. I presume this will work for my nested example as well. Thanks again.
On Thu, Jul 29, 2010 at 2:18 PM, Paul Rubin wrote:
> wheres pythonmonks writes:
>> How do I build an "int1" type that has a default value of 1?
>> [Hopefully no speed penalty.]
>> I am thinking about applications wit
wheres pythonmonks writes:
> How do I build an "int1" type that has a default value of 1?
> [Hopefully no speed penalty.]
> I am thinking about applications with collections.defaultdict.
You can supply an arbitary function to collections.defaultdict.
It doesn't have to be a class. E.g.
d =
Why is the default value of an int zero?
>>> x = int
>>> print x
>>> x()
0
>>>
How do I build an "int1" type that has a default value of 1?
[Hopefully no speed penalty.]
I am thinking about applications with collections.defaultdict.
What if I want to make a defaultdict of defaultdicts of lists?
Greetings,
I am using pyuniit for my test cases.
I want to change the default behavior to report the errors. I believe
it calls TextTestRunner class before calling my test_class(which is
child of TestCase class) to set up the framework for error reporting
and so on. I can see that it makes the
45 matches
Mail list logo
