defaultdict's bug or feature?
from collections import defaultdict
d = defaultdict(set)
assert isinstance(d['a'], set)
assert isinstance(d.get('b'), set)
d['a'] is ok, and a new set object is insert to d, but d.get('b') won't.
It's a bug, or just a feature?
I think dict.get() method is just a *safe* version of dict[key], maybe it
should be:
def get(self, key, default = None):
try:
return self[key]
except KeyError:
return default
--
http://mail.python.org/mailman/listinfo/python-list
Re: defaultdict's bug or feature?
You mean 'get' method should not alter the dict, does 'dict[key]' should not
alter the dict either?
d = defaultdict(set)
assert len(d) == 0
print d[1]
assert len(d) == 1
auto insert value to dict, when value is not in dict, is what defaultdict
try to do.
On Fri, May 22, 2009 at 7:46 AM, Rhodri James
wrote:
> On Thu, 21 May 2009 13:07:50 +0100, Red Forks wrote:
>
> from collections import defaultdict
>>
>> d = defaultdict(set)
>> assert isinstance(d['a'], set)
>> assert isinstance(d.get('b'), set)
>>
>> d['a'] is ok, and a new set object is insert to d, but d.get('b') won't.
>>
>> It's a bug, or just a feature?
>>
>
> Feature. You're blaming 'get' for doing exactly what it said it would,
> both in returning None and not gratuitously altering the dictionary.
>
> --
> Rhodri James *-* Wildebeeste Herder to the Masses
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: defaultdict's bug or feature?
Yes, you maybe right. When use defaultdict, should not rely get() method
anymore, d[] is just enough. When a function return a defaultdict, but
people don't know it, so:
d = load_map()
# if she call d['a'], everything is OK but
# when call d.get('a'), she is always get None.
# Why she call d.get('a'), not d['a'], because she don't want to provider
default value herself (she didn't know it is a defaultdict)
It is just wield, call d[''a'] Ok, not get('a').
Sorry my poor english. Maybe somebody don't catch my mind, or maybe a little
rude.
I'm using and learning python about 2 weeks ago, spent me three hrs to find
the problem, almost drive me mad.
Maybe other like me, find some inconvience on this.
--
Actually, I steal defaultdict to do other things:
class OnloadDict(defaultdict):
def __init__(self, onload):
self.__onload = onload
def __missing__(self, key):
result = self.__onload(key)
if not result:
raise KeyError
self[key] = result
return result
def get(self, key, default = None):
''' defaultdict.get() won't call __missing__, so override '''
try:
return self[key]
except KeyError:
return default
OnloadDict, is like a cache. When the value is not in dict, using 'onload'
function to load the value by the key.
When no value correspond to a key, a KeyError will raised. So I need a
*safer* version 'get()' method.
On Fri, May 22, 2009 at 12:35 PM, Rhodri James
wrote:
> Please don't top-post, it makes the thread of argument hard to follow.
>
> On Fri, 22 May 2009 01:44:37 +0100, Red Forks wrote:
>
> You mean 'get' method should not alter the dict, does 'dict[key]' should
>> not
>> alter the dict either?
>>
>> d = defaultdict(set)
>> assert len(d) == 0
>> print d[1]
>> assert len(d) == 1
>>
>> auto insert value to dict, when value is not in dict, is what defaultdict
>> try to do.
>>
>
> Behaviour you are deliberately avoiding by calling `get`, since that
> explicitly behaves the same way that it does for dicts. You're doing
> two different things through two different interfaces with two different
> specs. Why are you expecting them to have the same effect?
>
>
> --
> Rhodri James *-* Wildebeeste Herder to the Masses
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: defaultdict's bug or feature?
On Sat, May 23, 2009 at 2:03 AM, Rhodri James wrote: > I asked you not to top-post. Please put your replies *below* the > messages you're quoting, not above. It's much easier to understand > the conversation that we're having if you do that, and much more > aggravating if you don't. > I misunderstand you last email, thanks. > > On Fri, 22 May 2009 09:53:04 +0100, Red Forks wrote: > > Yes, you maybe right. When use defaultdict, should not rely get() method >> anymore, d[] is just enough. >> > > Almost. You should rely on get() to do what it says, not what you think > it should do. That's generally true, by the way; when the Fine Manual > says that a class, function or method will do one thing, expecting it to > do something else is unreasonable. > > Actually, I steal defaultdict to do other things: >> >> class OnloadDict(defaultdict): >>def __init__(self, onload): >>self.__onload = onload >> >>def __missing__(self, key): >>result = self.__onload(key) >>if not result: >>raise KeyError >> >>self[key] = result >>return result >> >>def get(self, key, default = None): >>''' defaultdict.get() won't call __missing__, so override ''' >>try: >>return self[key] >>except KeyError: >>return default >> >> OnloadDict, is like a cache. When the value is not in dict, using 'onload' >> function to load the value by the key. >> When no value correspond to a key, a KeyError will raised. So I need a >> *safer* version 'get()' method. >> > > Why are you so determined to (ab)use get() on your class? You should > only be calling OnloadDict.get() if you really mean "get me the value > associated with this key, or the default I'm telling you about *right* > *now* if there isn't one." The key point is: "what key/value pairs should in defaultdict". I think any key/default pair(they'll add to dict when you ask for it), maybe you think only manual added pairs. defaultdict break dict rules, that a query method (d[key]) should not modify dict, so another query method (the get() method) break default rule is not a big deal. Never mind, my "get()" method hack works OK. > > > Aside from that, this is neat. Strictly you should call > defaultdict.__init__(self) in your __init__() function just in case > defaultdict needs any setup that you aren't doing (which it does, but > you override __missing__() so it never notices that it doesn't have > a default_factory). You get away with it here, but it's not a good > habit to get into. > I'm new to python, adding 'defaultdict.__init__()' call would be nice. In other languages, base class's default constructor is automaticlly called. > > -- > Rhodri James *-* Wildebeeste Herder to the Masses > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: multi-core software
Single - thread programming is great! clean, safe!!! I'm trying schedual task to several work process (not thread). On Fri, Jun 5, 2009 at 4:49 AM, MRAB wrote: > Kaz Kylheku wrote: > >> ["Followup-To:" header set to comp.lang.lisp.] >> On 2009-06-04, Roedy Green wrote: >> >>> On Thu, 4 Jun 2009 09:46:44 -0700 (PDT), Xah Lee >>> wrote, quoted or indirectly quoted someone who said : >>> >>> • Why Must Software Be Rewritten For Multi-Core Processors? >>> Threads have been part of Java since Day 1. >>> >> >> Unfortunately, not sane threads designed by people who actually understand >> multithreading. >> >> The nice thing about Java is whether you are on a single core >>> processor or a 256 CPU machine (We got to run our Athena Integer Java >>> spreadsheet engine on such a beast), does not concern your code. >>> >> >> You are dreaming if you think that there are any circumstances (other than >> circumstances in which performance doesn't matter) in which you don't have >> to >> concern yourself about the difference between a uniprocessor and a 256 CPU >> machine. >> > > If you're interested in parallel programming, have a look at Flow-Based > Programming: > > http://www.jpaulmorrison.com/fbp/ > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: PYTHONPATH and multiple python versions
maybe a shell script to switch PYTHONPATH, like: start-python-2.5 start-python-2.4 ... On Fri, Jun 5, 2009 at 4:56 PM, David Cournapeau wrote: > Hi, > > As I don't have admin privileges on my main dev machine, I install a > good deal of python modules somewhere in my $HOME, using PYTHONPATH to > point my python intepreter to the right location. I think PEP370 > (per-user site-packages) does exactly what I need, but it works only > for python 2.6 and above. Am I out of luck for versions below ? > > David > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Interesting things of 'getattr' and 'setattr'
I don't know it is a feature, or implement detail: >>> class C(object): pass ... >>> c = C() >>> setattr(c, ' ', 3) >>> getattr(c, ' ') 3 >>> setattr(c, 'with blank', 4) >>> getattr(c, 'with blank') 4 getattr / setattr seems treat any string as attribute name. -- http://mail.python.org/mailman/listinfo/python-list
Re: dynamically modify help text
Read you doc file and set the __doc__ attr of the object you want to change. On Monday, June 28, 2010, Brian Blais wrote: > Hello, > > I know that the help text for an object will give a description of every > method based on the doc string. Is there a way to add something to this > text, specific to an object, but generated at run-time? I have an object > that reads a file, and I would like part of that file to be shown if one > does: help(myobject) > > > thanks, > > Brian Blais > > -- > Brian Blais > [email protected] > http://web.bryant.edu/~bblais > http://bblais.blogspot.com/ > > > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: string.Template issue
On Thu, Jul 30, 2009 at 4:17 PM, Javier Collado wrote: > Hello, > > In the string.Template documentation > (http://docs.python.org/library/string.html) it's explained that if a > custom regular expression for pattern substitution is needed, it's > possible to override idpattern class attribute (whose default value is > [_a-z][_a-z0-9]*). > > However, if the custom pattern that is needed is just uppercase > letters something like [A-Z]+ won't work because of the following line > in the _TemplateMetaclass class __init__ method: > cls.pattern = _re.compile(pattern, _re.IGNORECASE | _re.VERBOSE) derive a new class, and replace __init__ method, or replace _TemplateMetaclass.__init__() method. > > > I would say that this is an error (IGNORECASE just shouldn't be there) > and that the line above should be: > cls.pattern = _re.compile(pattern, _re.VERBOSE) > and the default value for idpattern: > [_a-zA-Z][_a-zA-Z0-9]* > > Do you agree on this? Is there any reason for the IGNORECASE option to > be passed to re.compile? > > Best regards, >Javier > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: Custom namespaces
On Sun, Aug 2, 2009 at 9:06 AM, Steven D'Aprano < [email protected]> wrote: > I was playing around with a custom mapping type, and I wanted to use it > as a namespace, so I tried to use it as my module __dict__: > > >>> import __main__ > >>> __main__.__dict__ = MyNamespace() > Traceback (most recent call last): > File "", line 1, in > TypeError: readonly attribute > > Why is __dict__ made read-only? to protect module type? Use .update() method: __main.__.__dict__.update(MyNamespace()) You can create your own Module instance: from types import ModuleType m = ModuleType('modulename') and make a sub class of ModuleType is also OK > > > I next thought I could change the type of the namespace to my class: > > >>> __main__.__dict__.__class__ = MyNamespace > Traceback (most recent call last): > File "", line 1, in > TypeError: __class__ assignment: only for heap types > > Drat, foiled again!!! > > Okay, if I can't do this at the module level, can I at least install a > custom namespace at the class level? > > >>> class MyNamespace(dict): > ... def __getitem__(self, key): > ... print "Looking up key '%s'" % key > ... return super(MyNamespace, self).__getitem__(key) > ... > >>> namespace = MyNamespace(x=1, y=2, z=3) > >>> namespace['x'] > Looking up key 'x' > 1 > >>> C = new.classobj("C", (object,), namespace) > >>> C.x > 1 > > Apparently not. It looks like the namespace provided to the class > constructor gets copied when the class is made. > > Interestingly enough, the namespace argument gets modified *before* it > gets copied, which has an unwanted side-effect: > > >>> namespace > {'y': 2, 'x': 1, '__module__': '__main__', 'z': 3, '__doc__': None} > > > Is there any way to install a custom type as a namespace? > > > > -- > Steven > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
