Re: print stream behavior

2009-05-27 Thread Andreas Kraemer
On May 27, 10:52 am, Peter Otten <__pete...@web.de> wrote: > This is a longstanding quirk of the CPython implementation. The > PRINT_ITEM_TO opcode triggers a PyFile_WriteObject() call which in turn does > the C equivalent of > > if isinstance(f, file): >    file.write(f, s) > else: >    write = ge

print stream behavior

2009-05-27 Thread Andreas Kraemer
I don't understand the behavior of the print statement when streaming to a "file-like" object. From the documentation at http://www.python.org/doc/2.4.4/ref/print.html I understand that the file-like object needs to have a write() method that - I assume - is called when the print statement is invok

Re: Strange behaviour with reversed()

2007-10-19 Thread Andreas Kraemer
On Oct 19, 1:49 pm, Duncan Booth <[EMAIL PROTECTED]> wrote: > Andreas Kraemer <[EMAIL PROTECTED]> wrote: > >> The only other behaviours I would regard as intuitive for iteration over > >> a mutating sequence would be to throw an exception either for mutating >

Re: Need scrip to reed rss feeds

2007-10-18 Thread Andreas Kraemer
On Oct 18, 4:39 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Hi, > Does any one know whare I can find some code to phrase a rss feeds? > Thank you, > Ted Try http://feedparser.org/ -- http://mail.python.org/mailman/listinfo/python-list

Re: Strange behaviour with reversed()

2007-10-18 Thread Andreas Kraemer
On Oct 18, 2:25 am, Duncan Booth <[EMAIL PROTECTED]> wrote: > Steven D'Aprano <[EMAIL PROTECTED]> wrote: > >> Note that the starting index is determined at creation time, not when > >> the iteration begins. So, if you create a reversed object over a list > >> containing 3 elements, the first return

Re: Strange behaviour with reversed()

2007-10-17 Thread Andreas Kraemer
On Oct 17, 9:31 pm, Steven D'Aprano <[EMAIL PROTECTED] cybersource.com.au> wrote: > I don't understand how reversed() is operating. I've read the description > in the docs: > > reversed(seq) > Return a reverse iterator. seq must be an object which supports the > sequence protocol (the __len__() met

Re: storing meta data on dictionary keys

2007-10-11 Thread Andreas Kraemer
On Oct 11, 1:42 pm, Erik Jones <[EMAIL PROTECTED]> wrote: > On Oct 11, 2007, at 2:25 PM, Andreas Kraemer wrote: > > > On Oct 11, 10:17 am, Erik Jones <[EMAIL PROTECTED]> wrote: > > >> No, duck typing and inheritance are two different things. Duck > &

Re: storing meta data on dictionary keys

2007-10-11 Thread Andreas Kraemer
On Oct 11, 10:17 am, Erik Jones <[EMAIL PROTECTED]> wrote: > No, duck typing and inheritance are two different things. Duck > typing is when you implement the same operations as another object or > class, whereas with inheritance you get the same implementation as > that of the parent class. Exc

Re: storing meta data on dictionary keys

2007-10-11 Thread Andreas Kraemer
> > [...]In fact, now that I think of it, get_key > > is probably a bad name for it, get_other_object_with_this_same_key is > > probably more apt :) > > Or more precise: > get_key_that_was_used_when_value_was_inserted_into_dictionary :-) Or even more precisely: get_key_obj

Re: storing meta data on dictionary keys

2007-10-10 Thread Andreas Kraemer
On Oct 10, 9:00 pm, Erik Jones <[EMAIL PROTECTED]> wrote: > If you're sure that 1. this use case won't grow and 2. that you'll > only be the only person ever using code, then it's your choice of > preference. Both of those points are equally important. 1 is a > manageability issue in that you ar

Re: Keeping track of subclasses and instances?

2007-10-10 Thread Andreas Kraemer
On Oct 10, 6:19 pm, Karlo Lozovina <[EMAIL PROTECTED]> wrote: > Larry Bates wrote: > > I'm not completely sure I understand the question but here goes. > > Instances of > > classes are classes can be stored in lists or dictionaries. In lists you > > reference them via their index (or iterate over

Re: storing meta data on dictionary keys

2007-10-10 Thread Andreas Kraemer
On Oct 9, 9:18 pm, Erik Jones <[EMAIL PROTECTED]> wrote: > So, do you not keep references to your nodes anywhere but the actual > graph dict? I kind of agree with Chris here in that two dicts will > work. One for the nodes, indexed by their strings. Yes, I guess that's exactly what I want. To kee

Re: storing meta data on dictionary keys

2007-10-09 Thread Andreas Kraemer
From: Chris Mellon <[EMAIL PROTECTED]> Sent: Tuesday, October 9, 2007 1:51:04 PM > Because, by definition, if you have the key then you don't need to get > it from the dict. What you're doing here is conflating 2 mappings into > one: string value->person and person->values. Use 2 explicit dicts t

storing meta data on dictionary keys

2007-10-09 Thread Andreas Kraemer
I sometimes find it useful to store meta data on dictionary keys, like in the following example: class Dict(dict): def __init__(self,*args,**kw): self.key_dict = {} super(Dict,self).__init__(*args,**kw) def __setitem__(self,k,v): self.key_dict[k] = k super(Dict,self).__setitem

mutable objects as dictionary keys

2007-10-09 Thread Andreas Kraemer
Hi everyone, I know that the subject of mutable objects as dictionary keys has been discussed a number of times in this forum (see for instance "freezing" of classes), but I would love to hear the thoughts of the experts on the approach below. The use case that I encounter frequently is the c