Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Glenn Linderman]

On approximately 3/3/2009 11:22 PM, came the following characters from 
the keyboard of Raymond Hettinger:



Perhaps the terminology should be

  ordereddict -- what we have here

  sorteddict -- hypothetical future type that keeps
itself sorted in key order


+1


-1

Introducing the hypothetical sorteddict would serve to reduce the 
likelihood of ordereddict being interpreted as sorteddict among the 
small percentage of people that actually read the two lines that might 
mention it in the documentation, but wouldn't significantly aid the 
intuition of people who first encounter it in someone else's code.


And without an implementation, it would otherwise be documentation 
noise, not signal.




FIFOdict ?  Yeah, that blows the capitalization scheme, way, way out.


Issues:
* The popitem() method is LIFO.



But traversal starts at the other end, if I understand correctly. 
popitem seems gratuitous (but handy and cheap)




* In a non-popping context, there is no OUT.  It just stores.
* FIFO is more suggestive of queue behavior which does not apply here.



It is suggestive of queue behavior, and the items are a queue if looked 
at from insertion, and traversal perspectives, if I understand 
correctly.  But without OUT, FIFO is a bit too aggressively suggestively 
 of queues... but not more so than ordereddict is a bit too suggestive 
of sorted behavior... And at least FIFO doesn't have the sorting 
connotation.



* Stores to existing keys don't go at the end; they leave the order 
unchanged.


FWIW, PEP 372 has links to seven other independent implementations and 
they all have names that are some variant spelling OrderedDict except 
for one which goes by the mysterious name of StableDict.



Well, just because six other independent implementations use a name with 
connotations that they don't live up to is no reason to perpetuate such 
foolishness, nor introduce it into the Python stdlib.


StableDict, eh?  That's not so mysterious, perhaps, if you think of 
stable sorts^H^H^H^H^H (whoops, there's the wrong connotation rearing 
its ugly head again, sorry).



Am still +1 on painting the class green with pink polka dots, but I'm 
starting to appreciate why others are insisting on pink with green polka 
dots ;-)



Sure.  I didn't expect FIFOdict to be an extremely useful suggestion, 
but I wanted to make the point that if the name has an erroneous 
connotation, use a name that doesn't.  And to get the discussion above 
flowing, to find out more about your thinking in the matter.


InputOrderedDict might be more descriptive, yet not as long as that 
other atrocity I alluded to that you rightfully refused to quote :)


From tree-walking, perhaps people would intuit the right connotations 
from InOrderDict which is no longer than ordereddict, but usually the 
tree is kept sorted too, so I'm afraid it might not be sufficient.


Maybe  SequenceDict ?  SeqPreservingDict ?  SeqDict ?  All of these talk 
about sequences, which are generally not implied to be sorted.  I like 
these well enough, and it is late enough, that I'm not going to think of 
more right now.


C'mon folks, brainstorm, don't complain about ordereddict if you can't 
come up with some alternatives for discussion!!!  (and some reasons why 
the suggestions might be good or bad)  Even your bad ideas might trigger 
a good name in someone else's head...



--
Glenn -- http://nevcal.com/
===
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Steven D'Aprano]

On Wed, 4 Mar 2009 05:23:33 pm Glenn Linderman wrote:
> The problem with the ordereddict/OrderedDict/odict is that there
> are way too many possible orderings, and without being more
> specific (InsertionSequenceOrderPreservingDictionary) people are
> doing to think "sort" when they hear "ordered".

For what it's worth, the first time I heard the term "ordered 
dictionary", I assumed it would be a dict where the keys are kept in 
sorted order.

But so what? Making things easy is an admirable goal, but we shouldn't 
lose sight of the fact that Python is a programming language, not a 
door handle. There's no requirement that every last feature is easy 
to intuit for a naive user. It's okay if people sometimes guess 
wrong, so long as they have opportunity to learn better.

Speaking as an ignorant and lazy programmer, being user-friendly is 
one thing, but molly-coddling the ignorant and lazy is another. 
Especially when it takes just a few seconds to type "import 
collections; help(collections.odict)" and learn that the O stands for 
ordered, and that the order is specifically order of insertion rather 
than lexicographic order. Having good help text is user-friendly. 
Naming the class InsertionSequenceOrderPreservingDictionary is just 
dumbing down at the cost of usability. I trust this wasn't a serious 
suggestion, but just in case it was, I'll point out that we have dict 
instead of UnorderedKeyValueMapping. Does anyone think that people 
find Python harder to learn because of that choice?


> I think FIFOdict is a reasonable abbreviation for 
> InsertionSequenceOrderPreservingDictionary :)

I see your smiley, but in my opinion, the sort of programmer who can't 
work out what an OrderedDict (or odict) is, given the name, the doc 
string and the Internet, is going to have even more trouble working 
out what FIFOdict means.


I have no strong feelings either way between odict and OrderedDict. 
PEP 8 seems to demand OrderedDict, but I actually prefer odict on the 
basis that an ordered dictionary feels like a fundamental data 
structure like str, list and dict rather than a specialist class like 
HTTPBasicAuthHandler. (I realise that "fundamental data structure" is 
not a well-defined category.) I look forward to the day OrderedDict 
becomes a built-in so it can be renamed odict :)



-- 
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Gisle Aas]

On Mar 4, 2009, at 9:01 , Glenn Linderman wrote:

On approximately 3/3/2009 11:22 PM, came the following characters  
from the keyboard of Raymond Hettinger:

Perhaps the terminology should be

 ordereddict -- what we have here

 sorteddict -- hypothetical future type that keeps
   itself sorted in key order

+1


-1

Introducing the hypothetical sorteddict would serve to reduce the  
likelihood of ordereddict being interpreted as sorteddict among the  
small percentage of people that actually read the two lines that  
might mention it in the documentation, but wouldn't significantly  
aid the intuition of people who first encounter it in someone else's  
code.


And without an implementation, it would otherwise be documentation  
noise, not signal.


Instead of introducing a sorteddict I would instead suggest that the  
future should bring an odict with a sort method; possibly also  
keys_sorted and items_sorted methods.


I think this would simplify things and putting these methods into the  
odict documentation makes it clearer how it actually behaves for  
people that just scan the method index to get an impression of what  
the object is about.


Regards,
Gisle

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Tennessee Leeuwenburg]

Hello all,

First a comment on-thread:
  I can't wait to get an ordered dictionary in the stdlib! The discussion
regarding suggestions for the name appears to be ongoing. What about the
name 'orderdict' instead of 'ordereddict'?. It doesn't contain the double-d,
is slightly shorter, and I think a little more typo-friendly. Just my 2c,
please feel free to ignore. OrderDict would of course be the
alternative-casing version.

Secondly, regarding this list:
  I couldn't find a lot of documentation regarding list culture, so I'm
quite nervous about the potential for stepping in where I'm not welcome
before I have spent a lot of time 'spinning up' on this issues of this list.
I am interested in learning more about how Python is written and, if I can,
providing some assistance to that task. However it's going to be a long,
slow process for me. At the same time, I do have firsthand knowledge of how
hard it can be to get people to contribute to anything to any degree, and as
such don't want to be a part of the problem by being too tentative in
introducing myself.

I would appreciate any pointers regarding what is appreciated on this list
and what is not. Hopefully, over time I will be able to make some form of
useful, concrete code contributions in the form of patches or documentation,
but I do realise it will take a lot of hands-on learning first. Trying to
grok the discussions on this list seems like a big part of that.

Thanks,
-Tennessee
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Steven D'Aprano]

Gisle Aas wrote:

Instead of introducing a sorteddict I would instead suggest that the 
future should bring an odict with a sort method; possibly also 
keys_sorted and items_sorted methods.


Instead of odict.sorted(), that can be spelled:

sorted(odict)  # sort the keys
sorted(odict.values())  # sort the items
sorted(odict.items())  # sort the (key, value) pairs

More complex variations are also possible.

The idea of a SortedDict is that it should be sorted at all times, 
without needing an explicit sort method, e.g.:


D = SortedDict(d=1, a=1, b=1)
print D
=> SortedDict(a=1, b=1, d=1)
D['c'] = 1
print D
=> SortedDict(a=1, b=1, c=1, d=1)

If you need to call a sort method on the dict to generate the sorted 
version, you might as well just pass the values you want to sorted(). 
That's more flexible, as you can sort whatever you want by anything you 
like.


I only know one use-case for a SortedDict: doctests. It's hard to use 
dicts in doctests, because when you print the dict, the items appear in 
arbitrary order. If you had a SortedDict, you could always predict what 
the dict would look like and use it in a doctest. Possibly there are 
other use-cases, but if so I don't know what they are.




--
Steven

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform

[Nick Coghlan]

Benjamin Peterson wrote:
> Yes, I'm already looking forward to Py4k now. :)

Shh, Guido will need at least 5 years before he's ready to contemplate
going through something like this again.

Or maybe a decade to be on the safe side ;)

Cheers,
Nick.


-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Raymond Hettinger]

Beware, deleting an item from an OrderedDict (in the current
implementation) is O(N).


Am I correct in presuming that that would not be true of .popitem?


Yes.  The popitem() method is O(1).


Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Steve Holden]

Raymond Hettinger wrote:
[...]
> FWIW, PEP 372 has links to seven other independent implementations and
> they all have names that are some variant spelling OrderedDict except
> for one which goes by the mysterious name of StableDict.
> 
> Am still +1 on painting the class green with pink polka dots, but I'm
> starting to appreciate why others are insisting on pink with green polka
> dots ;-)
> 
This will be no surprise to those who have seen the many discussions on
ordered dicts that c.l.py has spawned over the years.

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Hrvoje Niksic]

Steven D'Aprano wrote:

Gisle Aas wrote:

Instead of introducing a sorteddict I would instead suggest that the 
future should bring an odict with a sort method; possibly also 
keys_sorted and items_sorted methods.


Instead of odict.sorted(), that can be spelled:

sorted(odict)  # sort the keys
sorted(odict.values())  # sort the items
sorted(odict.items())  # sort the (key, value) pairs


All of these are useful, but not when you want to sort the odict 
in-place.  Since ordered dict is all about order, a method for changing 
the underlying key order seems quite useful.  An odict.sort() would be 
easy to implement both in the current code (where it would delegate to 
self._keys.sort()) and in an alternative implementation using a linked 
list of keys (variants of mergesort work very nicely with linked lists).



The idea of a SortedDict is that it should be sorted at all times,


A SortedDict would be nice to have, but we might rather want to use a 
balanced tree for the its C implementation, i.e. not inherit from dict 
at all.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Steven D'Aprano]

Glenn Linderman wrote:


FIFOdict ?  Yeah, that blows the capitalization scheme, way, way out.

[...]
It is suggestive of queue behavior, and the items are a queue if looked 
at from insertion, and traversal perspectives, if I understand 
correctly.


Why is this relevant? Insertion and traversal are only two parts of dict 
behaviour, whether ordered, sorted or otherwise. You can lookup, delete 
or modify items anywhere in the dict, not just at the ends. Doesn't 
sound very queue-like to me.



[...]
FWIW, PEP 372 has links to seven other independent implementations and 
they all have names that are some variant spelling OrderedDict except 
for one which goes by the mysterious name of StableDict.



Well, just because six other independent implementations use a name with 
connotations that they don't live up to is no reason to perpetuate such 
foolishness, nor introduce it into the Python stdlib.


I don't believe the name is any more misleading than "dict" itself, or 
"str". It is a standard well-known name. From Google:


Results 1 - 10 of about 264 for StableDict
Results 1 - 10 of about 6,880 for OrderedDict
Results 1 - 10 of about 21,700 for ODict

(I have made no effort to exclude false positives.)

Yes, if you are a Martian or somebody learning to program for the first 
time, you have to learn what an ordered dict is. So what? You had to 
learn what a "str" was the first time you came across one too.



StableDict, eh?  That's not so mysterious, perhaps, if you think of 
stable sorts^H^H^H^H^H (whoops, there's the wrong connotation rearing 
its ugly head again, sorry).


What does it mean to say a dict is stable? That is doesn't decay and rot 
away if you leave it alone? Do items evaporate out of ordinary dicts if 
you leave them alone for long enough? That once you add an item, you 
can't remove it or mutate it? It's not clear what the Stable in 
StableDict could mean.



I didn't expect FIFOdict to be an extremely useful suggestion, 
but I wanted to make the point that if the name has an erroneous 
connotation, use a name that doesn't.


FIFOdict is *far* more misleading, as it erroneously suggests that you 
can't (or at least shouldn't) access elements in the middle of the dict.



From tree-walking, perhaps people would intuit the right connotations 
from InOrderDict which is no longer than ordereddict, but usually the 
tree is kept sorted too, so I'm afraid it might not be sufficient.


No, I'm sorry, that's wrong. Inorder traversal of a binary tree is 
nothing like order-of-insertion traversal of a dict.


node = 'a'
node.right = 'c'
node.left = 'b'
Inorder traversal of node gives: b, a, c.
Order-of-insertion traversal gives: a, c, b.


C'mon folks, brainstorm, don't complain about ordereddict if you can't 
come up with some alternatives for discussion!!!


There are two good alternatives: OrderedDict and odict, or as Raymond 
puts it, green with pink polka dots versus pink with green polka dots. I 
don't think there's much point in suggesting fluorescent orange with 
brown and grey stripes as well.




--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Nick Coghlan]

Tennessee Leeuwenburg wrote:
> Hello all,
> 
> First a comment on-thread:
>   I can't wait to get an ordered dictionary in the stdlib! The
> discussion regarding suggestions for the name appears to be ongoing.
> What about the name 'orderdict' instead of 'ordereddict'?. It doesn't
> contain the double-d, is slightly shorter, and I think a little more
> typo-friendly. Just my 2c, please feel free to ignore. OrderDict would
> of course be the alternative-casing version.

The naming discussion is largely shooting the breeze at this point - the
OrderedDict naming follows PEP 8 and has a decent history of use in this
context, and I don't believe the objections and alternatives are
compelling enough to get anyone to write the code necessary to change
it. For such a recent patch the "status quo wins by default" argument
isn't as strong as it can sometimes be, but it still carries some weight.

Someone might surprise me and come forward with a patch to change the
name, but I really doubt it at this point.

> Secondly, regarding this list:
> I would appreciate any pointers regarding what is appreciated on this
> list and what is not. Hopefully, over time I will be able to make some
> form of useful, concrete code contributions in the form of patches or
> documentation, but I do realise it will take a lot of hands-on learning
> first. Trying to grok the discussions on this list seems like a big part
> of that.

I'd say you're off to a good start - wanting to learn and understand the
existing culture rather than demanding that the current list members
adapt to *your* style is a great first step :)

As for the culture itself... 'respect' is the main word that comes to my
mind:
- respect for other people's time in trying to post messages that are
concise and to the point
- respect for other people's points of view in trying to resolve design
disagreements
- respect for other people's abilities in assuming that errors are
inadvertent mistakes or due to a small misunderstanding rather than a
result of sheer incompetence
- respect for Python's users in ensuring a variety of perspectives are
taken into account when considering changes

Also, you may have looked at this already, but if not, the developer
page has some useful pointers:
http://www.python.org/dev/
http://www.python.org/dev/culture/

Hope that helps!

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Steve Holden]

Tennessee Leeuwenburg wrote:
> Hello all,
> 
> First a comment on-thread:
>   I can't wait to get an ordered dictionary in the stdlib! The
> discussion regarding suggestions for the name appears to be ongoing.
> What about the name 'orderdict' instead of 'ordereddict'?. It doesn't
> contain the double-d, is slightly shorter, and I think a little more
> typo-friendly. Just my 2c, please feel free to ignore. OrderDict would
> of course be the alternative-casing version.
> 
> Secondly, regarding this list:
>   I couldn't find a lot of documentation regarding list culture, so I'm
> quite nervous about the potential for stepping in where I'm not welcome
> before I have spent a lot of time 'spinning up' on this issues of this
> list. I am interested in learning more about how Python is written and,
> if I can, providing some assistance to that task. However it's going to
> be a long, slow process for me. At the same time, I do have firsthand
> knowledge of how hard it can be to get people to contribute to anything
> to any degree, and as such don't want to be a part of the problem by
> being too tentative in introducing myself.
> 
> I would appreciate any pointers regarding what is appreciated on this
> list and what is not. Hopefully, over time I will be able to make some
> form of useful, concrete code contributions in the form of patches or
> documentation, but I do realise it will take a lot of hands-on learning
> first. Trying to grok the discussions on this list seems like a big part
> of that.
> 
Just dive in. We'll savage you when you get out of line :^).

Seriously, as long as it's about development *of* rather than *with*
Python, you should be OK. A couple of weeks lurking (or reading the list
history) will tell you most things you need to know.

regards
 Steve

takes-all-sorts-to-make-a-world-ly y'rs  - steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Lie Ryan]

Gisle Aas wrote:

On Mar 4, 2009, at 9:01 , Glenn Linderman wrote:

On approximately 3/3/2009 11:22 PM, came the following characters from 
the keyboard of Raymond Hettinger:

Perhaps the terminology should be

 ordereddict -- what we have here

 sorteddict -- hypothetical future type that keeps
   itself sorted in key order

+1


-1

Introducing the hypothetical sorteddict would serve to reduce the 
likelihood of ordereddict being interpreted as sorteddict among the 
small percentage of people that actually read the two lines that might 
mention it in the documentation, but wouldn't significantly aid the 
intuition of people who first encounter it in someone else's code.


And without an implementation, it would otherwise be documentation 
noise, not signal.


Instead of introducing a sorteddict I would instead suggest that the 
future should bring an odict with a sort method; possibly also 
keys_sorted and items_sorted methods.


I think this would simplify things and putting these methods into the 
odict documentation makes it clearer how it actually behaves for people 
that just scan the method index to get an impression of what the object 
is about.


How about making odict ordered by insertion order, then provide an 
optional argument for defining sorter? This optional argument must be a 
function/lambda/callable object and must be the first argument.


a = odict(bloh='foo', blah='faa')
a # odict([('bloh', 'foo'), ('blah', 'faa')])

b = odict(lambda a, b: (a[0] < b[0]), bloh='foo', blah='faa')
b # sorted by key: odict([('blah', 'faa'), ('bloh', 'foo')])

c = odict(lambda a, b: (a[1] < b[1]), bloh='foo', blah='faa')
c # sorted by value: odict([('blah', 'faa'), ('bloh', 'foo')])

b = odict(lambda a, b: (a[0] > b[0]), bloh='foo', blah='faa')
b # sorted by key, descending: odict([('bloh', 'foo'), ('blah', 'faa')])

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Steve Holden]

Raymond Hettinger wrote:
> 
>>> Perhaps the terminology should be
>>>
>>>   ordereddict -- what we have here
>>>
>>>   sorteddict -- hypothetical future type that keeps
>>> itself sorted in key order
> 
> +1
> 
> 
>> FIFOdict ?  Yeah, that blows the capitalization scheme, way, way out.
> 
> Issues:
> * The popitem() method is LIFO.
> * In a non-popping context, there is no OUT.  It just stores.
> * FIFO is more suggestive of queue behavior which does not apply here.
> * Stores to existing keys don't go at the end; they leave the order
> unchanged.
> 
> FWIW, PEP 372 has links to seven other independent implementations and
> they all have names that are some variant spelling OrderedDict except
> for one which goes by the mysterious name of StableDict.
> 
> Am still +1 on painting the class green with pink polka dots, but I'm
> starting to appreciate why others are insisting on pink with green polka
> dots ;-)
> 
historydict?

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Nick Coghlan]

Lie Ryan wrote:
 How about making odict ordered by insertion order, then provide an
> optional argument for defining sorter? This optional argument must be a
> function/lambda/callable object and must be the first argument.

As the PEP mentions (and Hrvoje brought up again already in this
thread), a hash table (i.e. dict) probably isn't the right data
structure to use as the basis for an "always sorted" container.
In-memory databases, balanced trees, etc, etc.

Further, unlike a more general "sorted" dictionary, an insertion ordered
dict already has specific use cases in the standard library.
ConfigParser will use it by default in 2.7/3.1 and namedtuple._asdict()
is being changed in those versions to return an OrderedDict so that
iterating over the result of _asdict() will process the fields in the
same order as iterating over the tuple itself.

It is also being added because an insertion ordered dictionary was the
primary example for the new metaclass __prepare__ method introduced by
PEP 3115. Adapting the example from that PEP:

  # The metaclass
  class OrderedClass(type):

@classmethod
def __prepare__(metacls, name, bases): # No keywords in this case
  return collections.OrderedDict()

def __new__(cls, name, bases, classdict):
  # Note that we replace the classdict with a regular
  # dict before passing it to the superclass, so that we
  # don't continue to record the order after the class
  # has been created.
  result = type.__new__(cls, name, bases, dict(classdict))
  result.member_names = list(classdict.keys())
  return result

  # An instance of the metaclass
  class StructDef(metaclass=OrderedClass):
# This dummy example uses types directly, but something
# like struct module format codes may make more sense
field1 = int
field2 = float
field3 = customType
trailingField = str

Unlike a normal class definition, the order of the field definitions in
structure matters, and in the example above, this information is
preserved by the metaclass. This can greatly simplify the process of
defining types where the order of the fields matters (e.g. so the values
can be serialised in the correct order for a binary translation of some
kind).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Lie Ryan]

Steve Holden wrote:

Raymond Hettinger wrote:

Perhaps the terminology should be

  ordereddict -- what we have here

  sorteddict -- hypothetical future type that keeps
itself sorted in key order

+1



FIFOdict ?  Yeah, that blows the capitalization scheme, way, way out.

Issues:
* The popitem() method is LIFO.
* In a non-popping context, there is no OUT.  It just stores.
* FIFO is more suggestive of queue behavior which does not apply here.
* Stores to existing keys don't go at the end; they leave the order
unchanged.

FWIW, PEP 372 has links to seven other independent implementations and
they all have names that are some variant spelling OrderedDict except
for one which goes by the mysterious name of StableDict.

Am still +1 on painting the class green with pink polka dots, but I'm
starting to appreciate why others are insisting on pink with green polka
dots ;-)


historydict?


agedict?

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[rdmurray]

On Wed, 4 Mar 2009 at 23:37, Lie Ryan wrote:

Steve Holden wrote:

 Raymond Hettinger wrote:
> > >  Perhaps the terminology should be
> > > 
> > >ordereddict -- what we have here
> > > 
> > >sorteddict -- hypothetical future type that keeps

> > >  itself sorted in key order
>  +1
> 
> 
> >  FIFOdict ?  Yeah, that blows the capitalization scheme, way, way out.

>  Issues:
>  * The popitem() method is LIFO.
>  * In a non-popping context, there is no OUT.  It just stores.
>  * FIFO is more suggestive of queue behavior which does not apply here.
>  * Stores to existing keys don't go at the end; they leave the order
>  unchanged.
> 
>  FWIW, PEP 372 has links to seven other independent implementations and

>  they all have names that are some variant spelling OrderedDict except
>  for one which goes by the mysterious name of StableDict.
> 
>  Am still +1 on painting the class green with pink polka dots, but I'm

>  starting to appreciate why others are insisting on pink with green polka
>  dots ;-)
>
 historydict?


agedict?


I actually like StableDict best.  When I hear that I think, "ah, the
key order is stable in the face of insertions, unlike a regular dict".
Nor can I at the moment think of an alternative explanation of what a
"StableDict" might be.

That said, I have no problem with keeping OrderedDict as the name.
("Ordered does not mean sorted, it means insertion order preserving"
may become a FQA (Frequent Question Answer :), but it is short and
clear and takes no longer than explaining what a StableDict _is_.)

Although, that might be another argument in favor of StableDict: since
unless you think what I wrote above you aren't going to have a clue what
it is, someone reading code and encountering it would be more likely to
look it up, whereas with OrderedDict someone is more likely to assume they
know what it is and get confused for a little while before looking it up.

Do I feel strongly enough about this to write a patch?  No :)

--RDM
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ABCs and MRO

[Paul Moore]

2009/3/3 Jeffrey Yasskin :
> Unfortunately, I think overloading functions on Number or Iterable
> would be really useful, and constraining it to only look at base
> classes would be unfortunate.

That could well be the case. So the question is, I guess, how would
you write such a function now? Because you could always continue to
write it like that, but make it generic for the other special cases
you didn't think of:

@simplegeneric
def foo(x, y):
if isinstance(x, Iterable):
do iterable processing
else:
do standard base processing

@foo.register(int)
def foo_int(x, y):
do int processing

It's unfortunate that you have to cover it in the base processing, but
certainly no worse than at present.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] svn (403 Forbidden)

[Luis Saavedra]

Hi,

when I run:

$ mkdir NewDir
$ cd NewDir
$ svn checkout http://svn.python.org/projects/python/trunk python
svn: Server sent unexpected return value (403 Forbidden) in response to 
REPORT request for '/projects/!svn/vcc/default'


how to fix this problem?, on another machine I don't have this problem...,

regards,

Luis.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Benji York]

On Wed, Mar 4, 2009 at 3:01 AM, Glenn Linderman  wrote:

> C'mon folks, brainstorm, don't complain about ordereddict if you can't come
> up with some alternatives for discussion!!!  (and some reasons why the
> suggestions might be good or bad)  Even your bad ideas might trigger a good
> name in someone else's head...

TemporalDict -- Since the order of insertion is important
SerialDict -- From Websters: of, relating to, consisting of, or
arranged in a series, rank, or row 
-- 
Benji York
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Antoine Pitrou]

 bitdance.com> writes:
> 
> I actually like StableDict best.  When I hear that I think, "ah, the
> key order is stable in the face of insertions, unlike a regular dict".
> Nor can I at the moment think of an alternative explanation of what a
> "StableDict" might be.
> 
> That said, I have no problem with keeping OrderedDict as the name.
> ("Ordered does not mean sorted, it means insertion order preserving"
> may become a FQA (Frequent Question Answer :), but it is short and
> clear and takes no longer than explaining what a StableDict _is_.)

Thanks to Python (and Raymond :-)), I now know what polka dots are.

Python-improves-my-English-skills'ly yours,

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Lie Ryan]

Nick Coghlan wrote:

Lie Ryan wrote:
 How about making odict ordered by insertion order, then provide an

optional argument for defining sorter? This optional argument must be a
function/lambda/callable object and must be the first argument.


or better yet, in the spirit of dumping cmp comparison like in list, the 
first optional argument would be a function that returns the sorting key 
of the object. If the optional argument is not specified, the current 
ordereddict semantic (by insertion order) will be used.



As the PEP mentions (and Hrvoje brought up again already in this
thread), a hash table (i.e. dict) probably isn't the right data
structure to use as the basis for an "always sorted" container.
In-memory databases, balanced trees, etc, etc.


Isn't ordered dictionary essentially also an "always sorted" container? 
It is always sorted depending on the order of insertion? I can't see any 
technical reason why the data structure can't accommodate them both. Can 
you point me to a discussion on this?


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

[Chris Withers]

Vaibhav Mallya wrote:
We do have HTMLParser, but that doesn't handle malformed pages well, and 
just isn't as nice as BeautifulSoup.


Interesting, given that BeautifulSoup is built on HTMLParser ;-)

Chris

--
Simplistix - Content Management, Zope & Python Consulting
   - http://www.simplistix.co.uk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] svn (403 Forbidden)

[Leif Walsh]

On Wed, Mar 4, 2009 at 8:18 AM, Luis Saavedra  wrote:
> how to fix this problem?, on another machine I don't have this problem...,

Which machines does it work/fail on?

I probably can't help you, but maybe that will help someone else figure it out.

-- 
Cheers,
Leif
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Leif Walsh]

On Wed, Mar 4, 2009 at 7:53 AM,   wrote:
> I actually like StableDict best.  When I hear that I think, "ah, the
> key order is stable in the face of insertions, unlike a regular dict".
> Nor can I at the moment think of an alternative explanation of what a
> "StableDict" might be.

+1

-- 
Cheers,
Leif
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Leif Walsh]

On Wed, Mar 4, 2009 at 7:53 AM,   wrote:
> I actually like StableDict best.  When I hear that I think, "ah, the
> key order is stable in the face of insertions, unlike a regular dict".
> Nor can I at the moment think of an alternative explanation of what a
> "StableDict" might be.

Hmm, perhaps a better explanation than a hasty +1:

"stabledict" makes me think of merge sort, being a stable sort.  In
the same way that merge sort doesn't needlessly swap elements while
sorting, stabledict might be thought to not "needlessly" swap elements
while {inserting, deleting}.  I also can't think of an alternative
explanation, so thus far, it's resistant to false positive semantics.

-- 
Cheers,
Leif
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Terry Reedy]

Lie Ryan wrote:

Isn't ordered dictionary essentially also an "always sorted" container? 
It is always sorted depending on the order of insertion? I can't see any 
technical reason why the data structure can't accommodate them both. Can 
you point me to a discussion on this?


Appending an item at the end of a sequence is O(1), no search required. 
 Inserting an item at a random 'sorted' point requires at best an 
O(logN) search.  Insertion itself is O(1) to O(N) depending on the 
structure.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Steven D'Aprano]

Leif Walsh wrote:

On Wed, Mar 4, 2009 at 7:53 AM,   wrote:

I actually like StableDict best.  When I hear that I think, "ah, the
key order is stable in the face of insertions, unlike a regular dict".
Nor can I at the moment think of an alternative explanation of what a
"StableDict" might be.


Hmm, perhaps a better explanation than a hasty +1:

"stabledict" makes me think of merge sort, being a stable sort.


Why merge sort in particular? Why not bubble sort, heap sort, insertion 
sort or any one of many other stable sorts?


Is this analogy really simpler than merely learning the fact that the 
dict keys are kept in the order they are inserted? It's not a very 
difficult concept. Why are we complicating it by inventing obscure, 
complicated analogies with utterly unrelated functions?




> In

the same way that merge sort doesn't needlessly swap elements while
sorting, stabledict might be thought to not "needlessly" swap elements
while {inserting, deleting}.


You're drawing an awfully long bow here. One might equally argue that in 
the same way that bubble sort does lots and lots of swapping, stabledict 
might be thought to be horribly inefficient and slow.




I also can't think of an alternative
explanation, so thus far, it's resistant to false positive semantics.


"The keys don't expire with time."
"It's stable against accidental deletions."
"It's stable against accidentally over-writing values."



--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Dennis Benzinger]

Am 04.03.2009 14:25, Benji York schrieb:
> On Wed, Mar 4, 2009 at 3:01 AM, Glenn Linderman  wrote:
> 
>> C'mon folks, brainstorm, don't complain about ordereddict if you can't come
>> up with some alternatives for discussion!!!  (and some reasons why the
>> suggestions might be good or bad)  Even your bad ideas might trigger a good
>> name in someone else's head...
> 
> TemporalDict -- Since the order of insertion is important
> SerialDict -- From Websters: of, relating to, consisting of, or
> arranged in a series, rank, or row 

Because the class is designed to only support insertion order and not
any other sorting why choose a generic name that could also describe a
class that supports a different order?

I'd prefer encoding the order in the class name, therefore I suggest
(Ins|Insertion)(Order|Ordered)Dict, e.g. InsOrderDict. Abbreviating the
first group to simply I probably is too confusing because of the use of
I as a prefix for interfaces.


Dennis Benzinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

[James Y Knight]

On Mar 4, 2009, at 9:56 AM, Chris Withers wrote:


Vaibhav Mallya wrote:
We do have HTMLParser, but that doesn't handle malformed pages  
well, and just isn't as nice as BeautifulSoup.


Interesting, given that BeautifulSoup is built on HTMLParser ;-)


I think html5lib would be a better candidate for an imrpoved HTML  
parser in the stdlib than BeautifulSoup.


James
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

[Tony Nelson]

At 2:56 PM + 3/4/09, Chris Withers wrote:
>Vaibhav Mallya wrote:
>> We do have HTMLParser, but that doesn't handle malformed pages well, and
>> just isn't as nice as BeautifulSoup.
>
>Interesting, given that BeautifulSoup is built on HTMLParser ;-)

In BeautifulSoup >= 3.1, yes.  Before that (<= 3.07a), it was based on the
more robust sgmllib.SGMLParser.  The current BeautifulSoup can't handle
'', while the earlier SGMLParser versions can.  I don't
know quite how common that missing space is in the wild, but I've
personally made HTML with that problem.  Maybe this is the only problem
with using HTMLParser instead of SGMLParser; I don't know.  In the mean
time, if I have a need for BeautifulSoup in Python3.x, I'll port sgmllib
and use the older BeautifulSoup.
-- 

TonyN.:'   
  '  
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Guido van Rossum]

On Tue, Mar 3, 2009 at 9:31 PM,   wrote:
>
> On 3 Mar, 10:20 pm, gu...@python.org wrote:
>>
>> On Tue, Mar 3, 2009 at 1:17 PM,   wrote:
>
>>> At the very least, this might serve as a basis for an abstract API for
>>> asyncore:
>>>
>>>
>>> http://twistedmatrix.com/documents/8.2.0/api/twisted.internet.interfaces.IProtocol.html
>
>> I hope we have learned from asyncore that a future-proof and maximally
>> flexible design of such an API is not easy. This is one of those cases
>> where I believe thinking hard up front will really pay off. In this
>> case I would recommend going through a full-blown PEP process before
>> committing to an API, to avoid making the same mistake twice. (I don't
>> mean this as a dig at Twisted, just as an observation about this
>> particular design problem. If Twisted solves all the problems already,
>> writing the PEP should be easy.)
>
> I didn't see it as a dig at Twisted; you're right, this is a hard problem.
>  Twisted doesn't solve all the problems perfectly, either; much has been
> made of some rather unfortunate nuances of the IProducer and IConsumer
> interfaces.
>
> I also regret that no Twisted people (myself included) seem to have the time
> to go through the PEP process and get something accepted.

Same here.

> Even if Twisted's interfaces aren't perfect, there's a lot of working
> application code which demonstrates that they are sufficient.  Perhaps more
> importantly, they are future-proof.  Every proposal we've come up with for
> addressing the more subtle shortcomings of these APIs has been completely
> backwards-compatible; there are no APIs with vague or broken semantics, just
> sub-optimal spellings.  The fact that there are already multiple reactor
> implementations which share very little code helps.

Sounds like it's not so much the code that's future proof but the
process used for evolving it. That seems to be missing for asyncore.
:-(

> If someone who has PEP-writing skills and some free time is updating
> asyncore to be more modern, I'd be very happy to walk that person through
> Twisted's API design and explain how either portions of our implementation
> could be lifted for the stdlib, or how a "high level" layer could be written
> into asyncore so that the author of a particular chunk of low-level
> networking code could ignore whether they're using the stdlib mainloop or
> one of the Twisted ones.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform

[Guido van Rossum]

On Wed, Mar 4, 2009 at 3:23 AM, Nick Coghlan  wrote:
> Benjamin Peterson wrote:
>> Yes, I'm already looking forward to Py4k now. :)
>
> Shh, Guido will need at least 5 years before he's ready to contemplate
> going through something like this again.
>
> Or maybe a decade to be on the safe side ;)

Actually Py4k will have to be on the next BDFL's watch. :)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Sidnei da Silva]

On Wed, Mar 4, 2009 at 3:04 PM, Guido van Rossum  wrote:
> Sounds like it's not so much the code that's future proof but the
> process used for evolving it. That seems to be missing for asyncore.
> :-(

Turning the issue around a bit, has anyone considered polishing up the
current fix to restore it's backwards compatibility, instead of
starting a discussion about a full-blown replacement?

I think that would be enough for most asyncore users (or even the
couple few affected) for the moment, and then we can think about a
possible future replacement.

-- 
Sidnei da Silva
Canonical Ltd.
 Landscape · Changing the way you manage your systems
http://landscape.canonical.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

[Georg Brandl]

James Y Knight schrieb:
> On Mar 4, 2009, at 9:56 AM, Chris Withers wrote:
> 
>> Vaibhav Mallya wrote:
>>> We do have HTMLParser, but that doesn't handle malformed pages  
>>> well, and just isn't as nice as BeautifulSoup.
>>
>> Interesting, given that BeautifulSoup is built on HTMLParser ;-)
> 
> I think html5lib would be a better candidate for an imrpoved HTML  
> parser in the stdlib than BeautifulSoup.

I second that.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Guido van Rossum]

On Wed, Mar 4, 2009 at 10:14 AM, Sidnei da Silva
 wrote:
> On Wed, Mar 4, 2009 at 3:04 PM, Guido van Rossum  wrote:
>> Sounds like it's not so much the code that's future proof but the
>> process used for evolving it. That seems to be missing for asyncore.
>> :-(
>
> Turning the issue around a bit, has anyone considered polishing up the
> current fix to restore it's backwards compatibility, instead of
> starting a discussion about a full-blown replacement?
>
> I think that would be enough for most asyncore users (or even the
> couple few affected) for the moment, and then we can think about a
> possible future replacement.

If it can be done while maintaining backwards compatibility with both
the 2.6 version and the pre-2.6 version, that would be great of
course! But can it?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Jean-Paul Calderone]

On Wed, 4 Mar 2009 10:21:26 -0800, Guido van Rossum  wrote:

On Wed, Mar 4, 2009 at 10:14 AM, Sidnei da Silva
 wrote:

On Wed, Mar 4, 2009 at 3:04 PM, Guido van Rossum  wrote:

Sounds like it's not so much the code that's future proof but the
process used for evolving it. That seems to be missing for asyncore.
:-(


Turning the issue around a bit, has anyone considered polishing up the
current fix to restore it's backwards compatibility, instead of
starting a discussion about a full-blown replacement?

I think that would be enough for most asyncore users (or even the
couple few affected) for the moment, and then we can think about a
possible future replacement.


If it can be done while maintaining backwards compatibility with both
the 2.6 version and the pre-2.6 version, that would be great of
course! But can it?



Is it really necessary to retain compatibility with the Python 2.6
version?  Python 2.6.0 and Python 2.6.1 contain a regression (as
compared to basically all previous versions of Python) which prevents
asyncore-based programs which are years old from working on them.
Restoring the pre-2.6 behavior will fix these old, presumably stable,
widely used programs for users who install 2.6.2 and newer.

The downside (which you were imagining, I'm sure) is that any new
software developed against the Python 2.6.0 or 2.6.1 behavior will
then break in 2.6.2 and later.  While this is unfortunate, it is
clearly the far lesser of two evils.  The choice must be made, though.
Either leave old software broken or break new software.  Just because
the "leave old software broken" choice is made through inaction doesn't
make it the better choice (though obviously since it requires action,
someone will have to do it, and I'm not volunteering - if inaction is
the choice because no one wants to do the work, fine, but that's a
different motivation than avoiding breaking newly written software).

So, as a disinterested party in this specific case, I'd say revert to
the pre-2.6 behavior.  It does less harm than leaving the current
behavior.

Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Guido van Rossum]

On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone  wrote:
> - Show quoted text -
> On Wed, 4 Mar 2009 10:21:26 -0800, Guido van Rossum 
> wrote:
>>
>> On Wed, Mar 4, 2009 at 10:14 AM, Sidnei da Silva
>>  wrote:
>>>
>>> On Wed, Mar 4, 2009 at 3:04 PM, Guido van Rossum 
>>> wrote:

 Sounds like it's not so much the code that's future proof but the
 process used for evolving it. That seems to be missing for asyncore.
 :-(
>>>
>>> Turning the issue around a bit, has anyone considered polishing up the
>>> current fix to restore it's backwards compatibility, instead of
>>> starting a discussion about a full-blown replacement?
>>>
>>> I think that would be enough for most asyncore users (or even the
>>> couple few affected) for the moment, and then we can think about a
>>> possible future replacement.
>>
>> If it can be done while maintaining backwards compatibility with both
>> the 2.6 version and the pre-2.6 version, that would be great of
>> course! But can it?
>>
>
> Is it really necessary to retain compatibility with the Python 2.6
> version?  Python 2.6.0 and Python 2.6.1 contain a regression (as
> compared to basically all previous versions of Python) which prevents
> asyncore-based programs which are years old from working on them.
> Restoring the pre-2.6 behavior will fix these old, presumably stable,
> widely used programs for users who install 2.6.2 and newer.
>
> The downside (which you were imagining, I'm sure) is that any new
> software developed against the Python 2.6.0 or 2.6.1 behavior will
> then break in 2.6.2 and later.  While this is unfortunate, it is
> clearly the far lesser of two evils.  The choice must be made, though.
> Either leave old software broken or break new software.  Just because
> the "leave old software broken" choice is made through inaction doesn't
> make it the better choice (though obviously since it requires action,
> someone will have to do it, and I'm not volunteering - if inaction is
> the choice because no one wants to do the work, fine, but that's a
> different motivation than avoiding breaking newly written software).
>
> So, as a disinterested party in this specific case, I'd say revert to
> the pre-2.6 behavior.  It does less harm than leaving the current
> behavior.

Sorry, but I really do think that we should maintain backward
compatibility *within* the 2.6 series as well. If that makes it
impossible to also maintain the 2.5 behavior, perhaps some flag could
be added to restore 2.5 compatibility, e.g.

import asyncore
asyncore.python_25_compat = True

Note that this "API" is designed to work in 2.5 as well. :-)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Jean-Paul Calderone]

On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum  wrote:

On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone  wrote:
[snip]


So, as a disinterested party in this specific case, I'd say revert to
the pre-2.6 behavior.  It does less harm than leaving the current
behavior.


Sorry, but I really do think that we should maintain backward
compatibility *within* the 2.6 series as well. If that makes it
impossible to also maintain the 2.5 behavior, perhaps some flag could
be added to restore 2.5 compatibility, e.g.

import asyncore
asyncore.python_25_compat = True

Note that this "API" is designed to work in 2.5 as well. :-)



But why?  The argument I made had the objective of minimizing developer
effort.  What's the objective of maintaining backward compatibility within
the 2.6 series in this case (sorry if it appeared earlier in this thread
and I missed it)?

Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Guido van Rossum]

On Wed, Mar 4, 2009 at 10:51 AM, Jean-Paul Calderone  wrote:
> On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum 
> wrote:
>>
>> On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone 
>> wrote:
>> [snip]
>>>
>>> So, as a disinterested party in this specific case, I'd say revert to
>>> the pre-2.6 behavior.  It does less harm than leaving the current
>>> behavior.
>>
>> Sorry, but I really do think that we should maintain backward
>> compatibility *within* the 2.6 series as well. If that makes it
>> impossible to also maintain the 2.5 behavior, perhaps some flag could
>> be added to restore 2.5 compatibility, e.g.
>>
>> import asyncore
>> asyncore.python_25_compat = True
>>
>> Note that this "API" is designed to work in 2.5 as well. :-)

> But why?  The argument I made had the objective of minimizing developer
> effort.  What's the objective of maintaining backward compatibility within
> the 2.6 series in this case (sorry if it appeared earlier in this thread
> and I missed it)?

The same as always. We don't change APIs in bugfix releases.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Jean-Paul Calderone]

On Wed, 4 Mar 2009 10:54:19 -0800, Guido van Rossum  wrote:

On Wed, Mar 4, 2009 at 10:51 AM, Jean-Paul Calderone  wrote:

On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum 
wrote:


On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone 
wrote:
[snip]


So, as a disinterested party in this specific case, I'd say revert to
the pre-2.6 behavior.  It does less harm than leaving the current
behavior.


Sorry, but I really do think that we should maintain backward
compatibility *within* the 2.6 series as well. If that makes it
impossible to also maintain the 2.5 behavior, perhaps some flag could
be added to restore 2.5 compatibility, e.g.

import asyncore
asyncore.python_25_compat = True

Note that this "API" is designed to work in 2.5 as well. :-)



But why?  The argument I made had the objective of minimizing developer
effort.  What's the objective of maintaining backward compatibility within
the 2.6 series in this case (sorry if it appeared earlier in this thread
and I missed it)?


The same as always. We don't change APIs in bugfix releases.



Okay.  Thanks for explaining.

Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Steve Holden]

Guido van Rossum wrote:
> On Wed, Mar 4, 2009 at 10:51 AM, Jean-Paul Calderone  
> wrote:
>> On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum 
>> wrote:
>>> On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone 
>>> wrote:
>>> [snip]
 So, as a disinterested party in this specific case, I'd say revert to
 the pre-2.6 behavior.  It does less harm than leaving the current
 behavior.
>>> Sorry, but I really do think that we should maintain backward
>>> compatibility *within* the 2.6 series as well. If that makes it
>>> impossible to also maintain the 2.5 behavior, perhaps some flag could
>>> be added to restore 2.5 compatibility, e.g.
>>>
>>> import asyncore
>>> asyncore.python_25_compat = True
>>>
>>> Note that this "API" is designed to work in 2.5 as well. :-)
> 
>> But why?  The argument I made had the objective of minimizing developer
>> effort.  What's the objective of maintaining backward compatibility within
>> the 2.6 series in this case (sorry if it appeared earlier in this thread
>> and I missed it)?
> 
> The same as always. We don't change APIs in bugfix releases.
> 
Which unfortunately stops us from categorizing API breakages as bugs.

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[glyph]

On 06:51 pm, exar...@divmod.com wrote:
On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum  
wrote:
On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone 
 wrote:



So, as a disinterested party in this specific case, I'd say revert to
the pre-2.6 behavior.



Sorry, but I really do think that we should maintain backward
compatibility *within* the 2.6 series as well.



But why?  The argument I made had the objective of minimizing developer
effort.  What's the objective of maintaining backward compatibility 
within
the 2.6 series in this case (sorry if it appeared earlier in this 
thread

and I missed it)?


Python's compatibility policy dictates that compatibility between micro- 
version releases be maintained *extremely* carefully.


As you all well know, normally I'd be strongly in favor of adhering to 
such a policy.  However, the ostensible purpose of the policy here is 
that users can *always* install micro-version upgrades to get bugfixes 
and security fixes, without worrying about compatibility upgrades.


Maintaining compatibility with the 2.6.x version of asyncore presupposes 
that *someone* has written some software against that version of 
asyncore and it might break if they installed an upgrade, though.  If 
that's the case - if there's even one person who has written or run any 
asyncore software against the version in 2.6 - then I think maintaining 
bug-for-bug compatibility is important.


However, my guess - and I'm assuming that JP was thinking the same thing 
- is that literally nobody has done that, or even *would* ever do that, 
so there's no software anywhere in the world that would break.  asyncore 
is relatively unpopular (thanks in part to the excellent alternatives 
:-)); its major users are the same people who have already complained.


Maybe it's too late to do something like this for 2.6, or even 3.0, but 
I've thought on a few occasions that projects (both Python and Twisted, 
at least) could use a special very-low-traffic policy-deviations mailing 
list for "We *REALLY* don't think this is going to ever break anything 
anyone has actually done, but just to be sure..." notifications for 
situations like this.  The implications being that (A) _everyone_ who 
uses the software should subscribe, and (B) if anyone ever responded to 
a message, the deviation wouldn't take place.


Anyway, I'm also a disinterested observer, so please don't take this as 
a strong endorsement of doing the fix in 2.6; the set-an-attribute-to- 
fix-it idea is fine by me too.  I thought I'd lay out the reasoning for 
violating an otherwise extremely reasonable policy, though.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mar 4, 2009, at 2:44 PM, gl...@divmod.com wrote:

Maintaining compatibility with the 2.6.x version of asyncore  
presupposes that *someone* has written some software against that  
version of asyncore and it might break if they installed an upgrade,  
though.  If that's the case - if there's even one person who has  
written or run any asyncore software against the version in 2.6 -  
then I think maintaining bug-for-bug compatibility is important.


However, my guess - and I'm assuming that JP was thinking the same  
thing - is that literally nobody has done that, or even *would* ever  
do that, so there's no software anywhere in the world that would  
break.  asyncore is relatively unpopular (thanks in part to the  
excellent alternatives :-)); its major users are the same people who  
have already complained.


FWIW, I use smtpd.py and a few of the asyncore APIs  
(.loop(), .socket_map.clear(), and .close_all()) in the Mailman 3 test  
suite.  That only works on Python 2.6 and I don't recall even a hiccup  
when moving from 2.5 to 2.6.


Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSa7kiXEjvBPtnXfVAQI2BQP/XD71ipSv5OhtdOJt+OF2jbfOyFU/2vPR
iJ33g9JJ2A0CvDWXmc81t9hMH3U8waagkXaDUF4r2MNM3JbONSjQGGZqX6X/1UOB
XCT+jNOrbRw2VQR0qjrweQ5A8u0Y1zsDo/rD4CXe0K1pFFWLubaU3lVgqEBMBL8r
xvf77EMoUuA=
=vmM5
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Bill Janssen]

Guido van Rossum  wrote:

> On Wed, Mar 4, 2009 at 10:51 AM, Jean-Paul Calderone  
> wrote:
> > On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum 
> > wrote:
> >>
> >> On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone 
> >> wrote:
> >> [snip]
> >>>
> >>> So, as a disinterested party in this specific case, I'd say revert to
> >>> the pre-2.6 behavior.  It does less harm than leaving the current
> >>> behavior.
> >>
> >> Sorry, but I really do think that we should maintain backward
> >> compatibility *within* the 2.6 series as well. If that makes it
> >> impossible to also maintain the 2.5 behavior, perhaps some flag could
> >> be added to restore 2.5 compatibility, e.g.
> >>
> >> import asyncore
> >> asyncore.python_25_compat = True
> >>
> >> Note that this "API" is designed to work in 2.5 as well. :-)
> 
> > But why?  The argument I made had the objective of minimizing developer
> > effort.  What's the objective of maintaining backward compatibility within
> > the 2.6 series in this case (sorry if it appeared earlier in this thread
> > and I missed it)?
> 
> The same as always. We don't change APIs in bugfix releases.

OK, seems reasonable.

But in this case, isn't the broken API the bug that's being fixed?  Do
we need a different way to fix broken APIs in bugfix releases?

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Daniel Stutzbach]

On Wed, Mar 4, 2009 at 12:54 PM, Guido van Rossum  wrote:

> The same as always. We don't change APIs in bugfix releases.
>

This question is actually for the Zope folks and others who have had
problems with the 2.6 asyncore/asynchat:

Are any of the problems due to a change in the documented API... or are they
all due to changes in undocumented internals that your code relied on?

Myself, the only change that I noticed going from 2.5 to 2.6 was that the
undocumented signature of asynchat.__init__() changed from taking a
parameter called "conn" to one with the same meaning called "sock".

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Ivan Krstić]

Glyph,

On Mar 4, 2009, at 12:31 AM, gl...@divmod.com wrote:
If someone who has PEP-writing skills and some free time is updating  
asyncore to be more modern, I'd be very happy to walk that person  
through Twisted's API design and explain how either portions of our  
implementation could be lifted for the stdlib, or how a "high level"  
layer could be written into asyncore so that the author of a  
particular chunk of low-level networking code could ignore whether  
they're using the stdlib mainloop or one of the Twisted ones.


I spent about a half hour sometime in the last month talking this  
through with Itamar, though not in great detail. I'd be interested in  
sitting down with both of you and trying to establish more precisely  
how much work is necessary to get something to actually happen here. I  
won't outright promise a PEP, but I'll promise at the very least to  
write down elaborate notes that someone could turn into a PEP  
relatively straightforwardly. Deal?


Cheers,

--
Ivan Krstić  | http://radian.org

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

[Ivan Krstić]

On Mar 4, 2009, at 12:32 PM, James Y Knight wrote:
I think html5lib would be a better candidate for an imrpoved HTML  
parser in the stdlib than BeautifulSoup.



While we're talking about alternatives, Ian Bicking appears to swear  
by lxml:





Cheers,

--
Ivan Krstić  | http://radian.org

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Nick Coghlan]

Lie Ryan wrote:
> Isn't ordered dictionary essentially also an "always sorted" container?
> It is always sorted depending on the order of insertion? I can't see any
> technical reason why the data structure can't accommodate them both. Can
> you point me to a discussion on this?

My phrasing was a little ambiguous - "always sorted for an arbitrary key
function" is better handled with something other than a hash map +
additional bookkeeping due to the effect on the speed of insertion and
deletion.

With a specifically insertion-ordered dict, only deletion is really
slowed down by the additional bookkeeping: it drops to O(n) due to the
need to find and remove the key being deleted from the sequence of keys
as well as from the hash map).

As Terry noted, supporting arbitrary sort orders would slow down
insertion as well.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Chris McDonough]

Daniel Stutzbach wrote:
> On Wed, Mar 4, 2009 at 12:54 PM, Guido van Rossum  wrote:
> 
>> The same as always. We don't change APIs in bugfix releases.
>>
> 
> This question is actually for the Zope folks and others who have had
> problems with the 2.6 asyncore/asynchat:
> 
> Are any of the problems due to a change in the documented API... or are they
> all due to changes in undocumented internals that your code relied on?

As far as I can tell, asyncore/asynchat is all "undocumented internals".  Any
use of asyncore in anger will use internals; there never was any well-understood
API to these modules.  Medusa itself (from which asyncore and asynchat were
derived) appears to itself break with the changes to asyncore/asynchat in 2.6
(at least it appears to use attributes like "ac_out_buffer" which were removed
in 2.6; this is not "Zope's version"; there is no such animal; this is plain old
Medusa 0.5.4).

Count me in as one who believes that it would be the lesser of two evils to
revert to the older (2.5 and prior) asyncore/asynchat implementations in 2.6.2
rather than soldiering on with the 2.6 and 2.6.1 implementation (which almost
certainly has fewer, if any, consumers); somebody messed up in 2.6 by making its
asyncore/asynchat more forward compatible with 3.0's than backwards compatible
with 2.5's and prior; this was just a mistake and keeping old code running
should trump any theoretical or puritanical benefit in a dot release.

- C

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Guido van Rossum]

On Wed, Mar 4, 2009 at 1:27 PM, Chris McDonough  wrote:
> Daniel Stutzbach wrote:
>> On Wed, Mar 4, 2009 at 12:54 PM, Guido van Rossum  wrote:
>>
>>> The same as always. We don't change APIs in bugfix releases.
>>>
>>
>> This question is actually for the Zope folks and others who have had
>> problems with the 2.6 asyncore/asynchat:
>>
>> Are any of the problems due to a change in the documented API... or are they
>> all due to changes in undocumented internals that your code relied on?
>
> As far as I can tell, asyncore/asynchat is all "undocumented internals".  Any
> use of asyncore in anger will use internals; there never was any 
> well-understood
> API to these modules.  Medusa itself (from which asyncore and asynchat were
> derived) appears to itself break with the changes to asyncore/asynchat in 2.6
> (at least it appears to use attributes like "ac_out_buffer" which were removed
> in 2.6; this is not "Zope's version"; there is no such animal; this is plain 
> old
> Medusa 0.5.4).
>
> Count me in as one who believes that it would be the lesser of two evils to
> revert to the older (2.5 and prior) asyncore/asynchat implementations in 2.6.2
> rather than soldiering on with the 2.6 and 2.6.1 implementation (which almost
> certainly has fewer, if any, consumers); somebody messed up in 2.6 by making 
> its
> asyncore/asynchat more forward compatible with 3.0's than backwards compatible
> with 2.5's and prior; this was just a mistake and keeping old code running
> should trump any theoretical or puritanical benefit in a dot release.

Then I'd like to hear from the folks who made and reviewed those
changes to asyncore in 2.6. I can't imagine the changes were done
without good intentions.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Nick Coghlan]

Dennis Benzinger wrote:
> I'd prefer encoding the order in the class name, therefore I suggest
> (Ins|Insertion)(Order|Ordered)Dict, e.g. InsOrderDict. Abbreviating the
> first group to simply I probably is too confusing because of the use of
> I as a prefix for interfaces.

Except I just don't see this proliferation of dict types with different
sort orders ever happening.

The distinction between OrderedDict and dict is that the order of
keys()/values()/items() isn't arbitrary the way it is in a regular dict
- there's a defined order that will always be used. That's all the name
tells you - if someone assumes they know what that ordering is without
actually looking at the documentation (and gets it wrong as a result),
then I don't see how that is any different from the fact that someone
might mistakenly assume that list.sort() puts the items in descending
order instead of ascending order.

For other sort orders, it seems far more likely to me that a
collections.SortedMap type would be added at some point in the future
that accepts a key function like the one accepted by sorted() and
list.sort(). Such a data type would make different trade-offs between
insertion, deletion and lookup speeds than those made in the hash map
based OrderedDict.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Daniel Stutzbach]

On Wed, Mar 4, 2009 at 3:14 PM, Ivan Krstić <
krs...@solarsail.hcs.harvard.edu> wrote:

> I spent about a half hour sometime in the last month talking this through
> with Itamar, though not in great detail. I'd be interested in sitting down
> with both of you and trying to establish more precisely how much work is
> necessary to get something to actually happen here. I won't outright promise
> a PEP, but I'll promise at the very least to write down elaborate notes that
> someone could turn into a PEP relatively straightforwardly. Deal?
>

Will any or all of you be at PyCon?  I'd be willing to put in the extra work
to turn your notes into a PEP.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Greg Ewing]

rdmur...@bitdance.com wrote:


I actually like StableDict best.  When I hear that I think, "ah, the
key order is stable in the face of insertions, unlike a regular dict".


But it still doesn't convey what the ordering actually *is*.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Guido van Rossum]

On Wed, Mar 4, 2009 at 1:44 PM, Greg Ewing  wrote:
> rdmur...@bitdance.com wrote:
>
>> I actually like StableDict best.  When I hear that I think, "ah, the
>> key order is stable in the face of insertions, unlike a regular dict".
>
> But it still doesn't convey what the ordering actually *is*.

Please, stick with OrderedDict. That's the name used historically by
most people who independently reinvented this functionality.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform

[Paul Moore]

2009/3/4 Guido van Rossum :
> On Wed, Mar 4, 2009 at 3:23 AM, Nick Coghlan  wrote:
>> Benjamin Peterson wrote:
>>> Yes, I'm already looking forward to Py4k now. :)
>>
>> Shh, Guido will need at least 5 years before he's ready to contemplate
>> going through something like this again.
>>
>> Or maybe a decade to be on the safe side ;)
>
> Actually Py4k will have to be on the next BDFL's watch. :)

Somebody warn Orlijn now!!! :-)

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

[Raymond Hettinger]

Just notices that the empty() and full() methods were still there.
IIRC, we agreed to take them out (but leaving qsize() exposed).
The docs entries and test cases were taken out, but the actual
methods were accidentally left in.

Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

[Benjamin Peterson]

2009/3/4 Raymond Hettinger :
> Just notices that the empty() and full() methods were still there.
> IIRC, we agreed to take them out (but leaving qsize() exposed).
> The docs entries and test cases were taken out, but the actual
> methods were accidentally left in.

If so, the only thing to do is deprecate it in 3.1 for removal in 3.2.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

[Tennessee Leeuwenburg]

That code doesn't look t scary... is trying to add a DeprecationWarning
something that I could try to learn how to do and try my hand at? Maybe if
someone else would like to address that more quickly, they'd be able to keep
me in the loop so I can start learning how Things are Done?

It looks as though all that is required is to add a warn message indicating
the planned removal?

I'm not sure if it's better for me to have a go at things quietly or to be
more interactive about getting to grips with the code...

Cheers,
-T

On Thu, Mar 5, 2009 at 12:04 PM, Benjamin Peterson wrote:

> 2009/3/4 Raymond Hettinger :
> > Just notices that the empty() and full() methods were still there.
> > IIRC, we agreed to take them out (but leaving qsize() exposed).
> > The docs entries and test cases were taken out, but the actual
> > methods were accidentally left in.
>
> If so, the only thing to do is deprecate it in 3.1 for removal in 3.2.
>
>
>
> --
> Regards,
> Benjamin
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/tleeuwenburg%40gmail.com
>



-- 
--
Tennessee Leeuwenburg
http://myownhat.blogspot.com/
"Don't believe everything you think"
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

[Raymond Hettinger]

Just noticed that the empty() and full() methods were still there.
IIRC, we agreed to take them out (but leaving qsize() exposed).
The docs entries and test cases were taken out, but the actual
methods were accidentally left in.


If so, the only thing to do is deprecate it in 3.1 for removal in 3.2.


I recommend adding a warning to 3.0.2 and removing in 3.1.
Waiting for more 3.x uptake doesn't serve our users well.
IIRC, that was the rationale for cmp() removal in 3.0.1.
Even in 2.x, these methods were documented as being 
unreliable and were removed from the 3.0 docs entirely.
We discussed removing them and most of the work was done.  



Guido, any thoughts?


Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

[Tennessee Leeuwenburg]

Hi all, just FYI... sorry for any list pollution

I went ahead and tried adding a warning to my local checkout. The test suite
raised a DeprecationWarning -- it appears those methods are currently in use
by other Lib code:


test_multibytecodec_support
test_multiprocessing
/home/tjl/python3/lib/python3.1/queue.py:98: DeprecationWarning:
Queue.empty() is deprecated, and won't be in 3.2.
  DeprecationWarning)
/home/tjl/python3/lib/python3.1/queue.py:109: DeprecationWarning:
Queue.full() is deprecated, and won't be in 3.2.
  DeprecationWarning)
/home/tjl/python3/lib/python3.1/queue.py:98: DeprecationWarning:
Queue.empty() is deprecated, and won't be in 3.2.
  DeprecationWarning)
/home/tjl/python3/lib/python3.1/queue.py:109: DeprecationWarning:
Queue.full() is deprecated, and won't be in 3.2.
  DeprecationWarning)
test_mutants
test_netrc
test_nis

Regards,
-T

On Thu, Mar 5, 2009 at 12:30 PM, Raymond Hettinger  wrote:

> Just noticed that the empty() and full() methods were still there.
>>> IIRC, we agreed to take them out (but leaving qsize() exposed).
>>> The docs entries and test cases were taken out, but the actual
>>> methods were accidentally left in.
>>>
>>
>> If so, the only thing to do is deprecate it in 3.1 for removal in 3.2.
>>
>
> I recommend adding a warning to 3.0.2 and removing in 3.1.
> Waiting for more 3.x uptake doesn't serve our users well.
> IIRC, that was the rationale for cmp() removal in 3.0.1.
> Even in 2.x, these methods were documented as being unreliable and were
> removed from the 3.0 docs entirely.
> We discussed removing them and most of the work was done.
>
> Guido, any thoughts?
>
>
> Raymond
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/tleeuwenburg%40gmail.com
>



-- 
--
Tennessee Leeuwenburg
http://myownhat.blogspot.com/
"Don't believe everything you think"
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

[jnoller]

Yup, I'd need to remove support in multiprocessing too.

On Mar 4, 2009 8:39pm, Tennessee Leeuwenburg  wrote:

Hi all, just FYI... sorry for any list pollution


I went ahead and tried adding a warning to my local checkout. The test  
suite raised a DeprecationWarning -- it appears those methods are  
currently in use by other Lib code:





test_multibytecodec_support
test_multiprocessing
/home/tjl/python3/lib/python3.1/queue.py:98: DeprecationWarning:  
Queue.empty() is deprecated, and won't be in 3.2.

DeprecationWarning)
/home/tjl/python3/lib/python3.1/queue.py:109: DeprecationWarning:  
Queue.full() is deprecated, and won't be in 3.2.



DeprecationWarning)
/home/tjl/python3/lib/python3.1/queue.py:98: DeprecationWarning:  
Queue.empty() is deprecated, and won't be in 3.2.

DeprecationWarning)
/home/tjl/python3/lib/python3.1/queue.py:109: DeprecationWarning:  
Queue.full() is deprecated, and won't be in 3.2.



DeprecationWarning)
test_mutants
test_netrc
test_nis



Regards,
-T



On Thu, Mar 5, 2009 at 12:30 PM, Raymond Hettinger pyt...@rcn.com> wrote:





Just noticed that the empty() and full() methods were still there.



IIRC, we agreed to take them out (but leaving qsize() exposed).



The docs entries and test cases were taken out, but the actual



methods were accidentally left in.







If so, the only thing to do is deprecate it in 3.1 for removal in 3.2.







I recommend adding a warning to 3.0.2 and removing in 3.1.



Waiting for more 3.x uptake doesn't serve our users well.



IIRC, that was the rationale for cmp() removal in 3.0.1.


Even in 2.x, these methods were documented as being unreliable and were  
removed from the 3.0 docs entirely.



We discussed removing them and most of the work was done.





Guido, any thoughts?







Raymond




___



Python-Dev mailing list



Python-Dev@python.org



http://mail.python.org/mailman/listinfo/python-dev


Unsubscribe:  
http://mail.python.org/mailman/options/python-dev/tleeuwenburg%40gmail.com








--
--
Tennessee Leeuwenburg
http://myownhat.blogspot.com/
"Don't believe everything you think"


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

[Raymond Hettinger]

Yup, I'd need to remove support in multiprocessing too.


ahead and tried adding a warning to my local checkout. 


Thanks for quickly checking this out.

Will be nice to get the API cleaned-up.
Leaving out part of the clean-up was a mistake.


Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] What to do about failing tests

[Tennessee Leeuwenburg]

On my local checkout I notice a number of failing tests (test_fileio
test_grp test_io test_urllib2_localnet). Is there anything that I should
attempt to do regarding these?

-Tennessee
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] forgive my patch submission

[Tennessee Leeuwenburg]

I am trying to learn the systems... I'm not trying to force a particular
approach to the solution but I want to learn how to correctly follow the
process. Please feel free to reject this -- I'm not trying to jump the gun
given there isn't even an agreed requirement at this stage.

Regards,
-Tennessee

-- 
--
Tennessee Leeuwenburg
http://myownhat.blogspot.com/
"Don't believe everything you think"
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What to do about failing tests

[Benjamin Peterson]

2009/3/4 Tennessee Leeuwenburg :
> On my local checkout I notice a number of failing tests (test_fileio
> test_grp test_io test_urllib2_localnet). Is there anything that I should
> attempt to do regarding these?

Try "svn up". Those should be fixed now.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Lie Ryan]

Steven D'Aprano wrote:

I also can't think of an alternative
explanation, so thus far, it's resistant to false positive semantics.


"The keys don't expire with time."
"It's stable against accidental deletions."
"It's stable against accidentally over-writing values."


Add to that:
"The StableDict is stable because it has no bugs, unlike the buggy dict"

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Lie Ryan]

Terry Reedy wrote:

Lie Ryan wrote:

Isn't ordered dictionary essentially also an "always sorted" 
container? It is always sorted depending on the order of insertion? I 
can't see any technical reason why the data structure can't 
accommodate them both. Can you point me to a discussion on this?


Appending an item at the end of a sequence is O(1), no search required. 
 Inserting an item at a random 'sorted' point requires at best an 
O(logN) search.  Insertion itself is O(1) to O(N) depending on the 
structure.


Yeah, but with a proper algorithm[1] it is possible to get a O(1) append 
(which is the characteristic we want for insertion order dictionary, 
while falling back to O(log n) if we explicitly give comparer function 
(or comparison key extractor).


[1] The insertion algorithm will test for where to insert from the end 
of the list. This way, insertion-order dict will still be O(1) (with an 
increased constant), else if custom order is specified insertion it will 
be O(n)


#UNTESTED BECAUSE I DON'T HAVE PYTHON CURRENTLY

# Note that it derives from OrderDict
class MyOrderDict(OrderDict):
def __init__(*args, **kwds):
if len(args) > 2:
raise TypeError('expected at most 2 arguments')
if len(args) == 2:
self._cmp, args = args[0], args[1:]
else:
self._cmp = lambda a, b: True
if not hasattr(self, '_keys'):
self._keys = []
self.update(*args, **kwds)

def __setitem__(self, key, value):
if key not in self:
self._key.append(None)
for i, k in enumerate(reversed(self._key)):
i = -i - 1
if self._cmp((k, self[k]), (key, value)):
self._key[i], self._key[i - 1] = k, key
else:
self._key[i] = k
dict.__setitem__(self, key, value)

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Steve Holden]

Daniel Stutzbach wrote:
> On Wed, Mar 4, 2009 at 3:14 PM, Ivan Krstić
>  > wrote:
> 
> I spent about a half hour sometime in the last month talking this
> through with Itamar, though not in great detail. I'd be interested
> in sitting down with both of you and trying to establish more
> precisely how much work is necessary to get something to actually
> happen here. I won't outright promise a PEP, but I'll promise at the
> very least to write down elaborate notes that someone could turn
> into a PEP relatively straightforwardly. Deal?
> 
> 
> Will any or all of you be at PyCon?  I'd be willing to put in the extra
> work to turn your notes into a PEP.
> 
OPEN SPACE!
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

[Tennessee Leeuwenburg]

Hi Jesse,

I'm not sure what the most appropriate thing to do is. I could:
  (a) leave any multiprocessing changes to you,
  (b) alter the functioning of the method queue_empty inside
test_multiprocessing to test for emptiness in a different manner

I'm happy to go ahead and try my hand at making the appropriate changes but
I don't want to tread in areas of the code that other people have ownership
of.

It appears as though the only place in multiprocessing which uses the
deprecated call is in the test_multiprocessing file.

I also found a call to Queue.empty in wsgui.py. I don't see any authorship
tags at the top of this file but the last commiter was Andrew Kuchling. Do I
need to contact him regarding this or is it appropriate for me to make the
appropriate modifications without consulting him?

Apologies to anyone if I appear to be overly tentative OR overly pushy -- I
am aware that some people take a great deal of personal ownership of their
works, while others are impatient with a soft approach.

Regards,
-Tennessee

On Thu, Mar 5, 2009 at 12:41 PM,  wrote:

> Yup, I'd need to remove support in multiprocessing too.
>
>
> On Mar 4, 2009 8:39pm, Tennessee Leeuwenburg 
> wrote:
> > Hi all, just FYI... sorry for any list pollution
> >
> > I went ahead and tried adding a warning to my local checkout. The test
> suite raised a DeprecationWarning -- it appears those methods are currently
> in use by other Lib code:
> >
> >
> >
> > test_multibytecodec_support
> > test_multiprocessing
> > /home/tjl/python3/lib/python3.1/queue.py:98: DeprecationWarning:
> Queue.empty() is deprecated, and won't be in 3.2.
> >   DeprecationWarning)
> > /home/tjl/python3/lib/python3.1/queue.py:109: DeprecationWarning:
> Queue.full() is deprecated, and won't be in 3.2.
> >
> >   DeprecationWarning)
> > /home/tjl/python3/lib/python3.1/queue.py:98: DeprecationWarning:
> Queue.empty() is deprecated, and won't be in 3.2.
> >   DeprecationWarning)
> > /home/tjl/python3/lib/python3.1/queue.py:109: DeprecationWarning:
> Queue.full() is deprecated, and won't be in 3.2.
> >
> >   DeprecationWarning)
> > test_mutants
> > test_netrc
> > test_nis
> >
> > Regards,
> > -T
> >
> > On Thu, Mar 5, 2009 at 12:30 PM, Raymond Hettinger pyt...@rcn.com>
> wrote:
> >
> >
> >
> > Just noticed that the empty() and full() methods were still there.
> >
> > IIRC, we agreed to take them out (but leaving qsize() exposed).
> >
> > The docs entries and test cases were taken out, but the actual
> >
> > methods were accidentally left in.
> >
> >
> >
> >
> >
> > If so, the only thing to do is deprecate it in 3.1 for removal in 3.2.
> >
> >
> >
> >
> >
> > I recommend adding a warning to 3.0.2 and removing in 3.1.
> >
> > Waiting for more 3.x uptake doesn't serve our users well.
> >
> > IIRC, that was the rationale for cmp() removal in 3.0.1.
> >
> > Even in 2.x, these methods were documented as being unreliable and were
> removed from the 3.0 docs entirely.
> >
> > We discussed removing them and most of the work was done.
> >
> >
> >
> > Guido, any thoughts?
> >
> >
> >
> >
> >
> > Raymond
> >
> >
> > ___
> >
> > Python-Dev mailing list
> >
> > Python-Dev@python.org
> >
> > http://mail.python.org/mailman/listinfo/python-dev
> >
> > Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/tleeuwenburg%40gmail.com
> >
> >
> >
> >
> >
> >
> > --
> > --
> > Tennessee Leeuwenburg
> > http://myownhat.blogspot.com/
> > "Don't believe everything you think"
> >
>



-- 
--
Tennessee Leeuwenburg
http://myownhat.blogspot.com/
"Don't believe everything you think"
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

[Dennis Benzinger]

Hi Nick!

Am 04.03.2009 22:34, Nick Coghlan schrieb:
> Dennis Benzinger wrote:
>> I'd prefer encoding the order in the class name, therefore I suggest
>> (Ins|Insertion)(Order|Ordered)Dict, e.g. InsOrderDict. Abbreviating the
>> first group to simply I probably is too confusing because of the use of
>> I as a prefix for interfaces.
> 
> Except I just don't see this proliferation of dict types with different
> sort orders ever happening.

Maybe there's a misunderstanding because I don't see it either. I was
trying to suggest four alternative names for the OrderedDict class. I
don't prefer encoding every possible sort order into the class name. I
just wanted to improve the name of OrderedDict.

> The distinction between OrderedDict and dict is that the order of
> keys()/values()/items() isn't arbitrary the way it is in a regular dict
> - there's a defined order that will always be used.

Yes, the insertion order.

> That's all the name
> tells you - if someone assumes they know what that ordering is without
> actually looking at the documentation (and gets it wrong as a result),
> then I don't see how that is any different from the fact that someone
> might mistakenly assume that list.sort() puts the items in descending
> order instead of ascending order.

And because that's all the name tells you I suggested to make the name
more clear by prepending Ins or Insertion.

> For other sort orders, it seems far more likely to me that a
> collections.SortedMap type would be added at some point in the future
> that accepts a key function like the one accepted by sorted() and
> list.sort(). Such a data type would make different trade-offs between
> insertion, deletion and lookup speeds than those made in the hash map
> based OrderedDict.
> [...]

Yes.


Dennis Benzinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Josiah Carlson]

On Wed, Mar 4, 2009 at 1:31 PM, Guido van Rossum  wrote:
> On Wed, Mar 4, 2009 at 1:27 PM, Chris McDonough  wrote:
>> Daniel Stutzbach wrote:
>>> On Wed, Mar 4, 2009 at 12:54 PM, Guido van Rossum  wrote:
>>>
 The same as always. We don't change APIs in bugfix releases.

>>>
>>> This question is actually for the Zope folks and others who have had
>>> problems with the 2.6 asyncore/asynchat:
>>>
>>> Are any of the problems due to a change in the documented API... or are they
>>> all due to changes in undocumented internals that your code relied on?
>>
>> As far as I can tell, asyncore/asynchat is all "undocumented internals".  Any
>> use of asyncore in anger will use internals; there never was any 
>> well-understood
>> API to these modules.  Medusa itself (from which asyncore and asynchat were
>> derived) appears to itself break with the changes to asyncore/asynchat in 2.6
>> (at least it appears to use attributes like "ac_out_buffer" which were 
>> removed
>> in 2.6; this is not "Zope's version"; there is no such animal; this is plain 
>> old
>> Medusa 0.5.4).
>>
>> Count me in as one who believes that it would be the lesser of two evils to
>> revert to the older (2.5 and prior) asyncore/asynchat implementations in 
>> 2.6.2
>> rather than soldiering on with the 2.6 and 2.6.1 implementation (which almost
>> certainly has fewer, if any, consumers); somebody messed up in 2.6 by making 
>> its
>> asyncore/asynchat more forward compatible with 3.0's than backwards 
>> compatible
>> with 2.5's and prior; this was just a mistake and keeping old code running
>> should trump any theoretical or puritanical benefit in a dot release.
>
> Then I'd like to hear from the folks who made and reviewed those
> changes to asyncore in 2.6. I can't imagine the changes were done
> without good intentions.

Interestingly enough, I just accidentally found this thread with an
unrelated web search, but it makes sense to reply.

Why the changes to asyncore:
1) the internals of asyncore were inefficient
2) the API and general behavior of the handle_*(), readable() and
writable() methods are unchanged, which are *exactly* what a user
should be overriding with subclassing
3) anyone modifying the *internals* of the implementation for the sake
of speed, shouldn't need to anymore

Maybe I have misread the posts in this thread, but does anyone have
any examples of their code breaking when only overriding handle_*(),
readable(), and writable() methods?

 - Josiah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com