Re: odict.py
Eyal Lotem
>
> eyal.lote...@gmail.com wrote:
> > A. You have this down there:
> > if INTP_VER < (2, 3):
> > raise RuntimeError("Tests require Python v.2.3 or later")
> >
> > Its considered better to check for a feature than to check the
> > version. Always keep backports in mind, and be explicit about what you
> > really need. If "doctest" does not exist before Python2.3, just catch
> > the import error and explain that doctest must exist (And that it does
> > in such Pythons).
>
> That's not the case, doctest is indeed present in Python 2.2, it just
> became too much work to make tests pass under it. odict still works under
> 2.2, only the tests require 2.3 .
Oh. In that case, I think it would be better to find the exact causes
of the failures in earlier versions (for example, the lack of nested
scopes or so), and check for that. Some people may want to use
backports -- and I think its more informative to be explicit about the
feature you want rather than the version you want.
If its too much work, its reasonable to drop the version checks
altogether and just specify it in some readme or so (Yes, I just don't
like "version checks" in Python code :-).
> Of course, without tests it's hard to have much confidence in correct
> behavior. We'll have to drop 2.2 compatibility sooner or later, the world
> moves on. :-)
>
>
> > B. Is it really a good idea to inherit from dict, if you modify its
> > signatures and behaviour? I would go for just having the dict as a
> > member, as none of the original dict methods are not overridden, and
> > if some new dict methods appear, they may work incorrectly.
>
> Well, it's still a dict with some behavior added. It should not make much
> of a difference. And I don't foresee frequent appearance of new methods on
> the builtin dict. :-)
Well, I believe that in Python inheritance is an implementation tool
and not a political statement about an object :-) So I tend to only
inherit if I actually lend the methods. Typically, my
"what-if-they-added-methods-test" is more of a thought experiment to
determine if inheritance is "the right thing" than an actual
consideration. I guess in this case the results are not
straightforward (you want your dict to have all the methods a normal
dict has, but not the original implementations thereof).
> > C. It could be nice if the "Experiemental" tag was removed once the
> > experiment is over :-)
>
> Are you talking about the SequenceOrderedDict docstring? That's Michael's
> addition, he'll let us know when it's time. ;-)
>
>
> > D. I think its a bad idea to override keys/values/items in
> > SequenceOrderedDict with other methods (while keeping the old ones in
> > _keys/etc). Its nicer if SequenceOrderedDict was really an
> > OrderedDict, and be usable as such (and thus still have the same keys/
> > values/items methods). Its OK to have both keys() and keysview() or
> > keysseq() or whatever. Practicality beats purity, and here you get a
> > practical disadvantage (interface incompatibility) for a "purity"
> > benefit (method name elegance).
>
> Once again, Michael's call. Also, make sure to familiarize yourself with
> these comp.lang.python threads, if you didn't already: ;-)
Michael: Do you agree? :-)
>
> Why are there no ordered dictionaries?
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/5ac716f9ad14cc04/d5b97a5e2eb39d05
>
> New Ordered Dictionery to Criticise
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/5b1a6c90f3139af3/697d3a32d4dd8427
>
Will check out the threads.
> > E. I am only using odict out of the entire package, but it seems like
> > great work!
>
> Thanks, I got fed up of seeing a number of incomplete implementations in
> various libraries and frameworks.
>
>
> --
> Nicola Larosa - nicola...@gmail.com
>
> [Lucky people] are skilled at creating and noticing chance opportunities,
> make lucky decisions by listening to their intuition, create self-
> fulfilling prophecies via positive expectations, and adopt a resilient
> attitude that transforms bad luck into good. -- Tim Ong, December 2006
>
>
> >
>
eyal....@gmail.com
if INTP_VER < (2, 3):
raise RuntimeError("Tests require Python v.2.3 or later")
Its considered better to check for a feature than to check the
version. Always keep backports in mind, and be explicit about what you
really need. If "doctest" does not exist before Python2.3, just catch
the import error and explain that doctest must exist (And that it does
in such Pythons).
B. Is it really a good idea to inherit from dict, if you modify its
signatures and behaviour? I would go for just having the dict as a
member, as none of the original dict methods are not overridden, and
if some new dict methods appear, they may work incorrectly.
C. It could be nice if the "Experiemental" tag was removed once the
experiment is over :-)
D. I think its a bad idea to override keys/values/items in
SequenceOrderedDict with other methods (while keeping the old ones in
_keys/etc). Its nicer if SequenceOrderedDict was really an
OrderedDict, and be usable as such (and thus still have the same keys/
values/items methods). Its OK to have both keys() and keysview() or
keysseq() or whatever. Practicality beats purity, and here you get a
practical disadvantage (interface incompatibility) for a "purity"
benefit (method name elegance).
E. I am only using odict out of the entire package, but it seems like
great work!
Thanks.
Eyal
Nicola Larosa
> A. You have this down there:
> if INTP_VER < (2, 3):
> raise RuntimeError("Tests require Python v.2.3 or later")
>
> Its considered better to check for a feature than to check the
> version. Always keep backports in mind, and be explicit about what you
> really need. If "doctest" does not exist before Python2.3, just catch
> the import error and explain that doctest must exist (And that it does
> in such Pythons).
That's not the case, doctest is indeed present in Python 2.2, it just
became too much work to make tests pass under it. odict still works under
2.2, only the tests require 2.3 .
Of course, without tests it's hard to have much confidence in correct
behavior. We'll have to drop 2.2 compatibility sooner or later, the world
moves on. :-)
> B. Is it really a good idea to inherit from dict, if you modify its
> signatures and behaviour? I would go for just having the dict as a
> member, as none of the original dict methods are not overridden, and
> if some new dict methods appear, they may work incorrectly.
Well, it's still a dict with some behavior added. It should not make much
of a difference. And I don't foresee frequent appearance of new methods on
the builtin dict. :-)
> C. It could be nice if the "Experiemental" tag was removed once the
> experiment is over :-)
Are you talking about the SequenceOrderedDict docstring? That's Michael's
addition, he'll let us know when it's time. ;-)
> D. I think its a bad idea to override keys/values/items in
> SequenceOrderedDict with other methods (while keeping the old ones in
> _keys/etc). Its nicer if SequenceOrderedDict was really an
> OrderedDict, and be usable as such (and thus still have the same keys/
> values/items methods). Its OK to have both keys() and keysview() or
> keysseq() or whatever. Practicality beats purity, and here you get a
> practical disadvantage (interface incompatibility) for a "purity"
> benefit (method name elegance).
Once again, Michael's call. Also, make sure to familiarize yourself with
these comp.lang.python threads, if you didn't already: ;-)
Why are there no ordered dictionaries?
http://groups.google.com/group/comp.lang.python/browse_thread/thread/5ac716f9ad14cc04/d5b97a5e2eb39d05
New Ordered Dictionery to Criticise
http://groups.google.com/group/comp.lang.python/browse_thread/thread/5b1a6c90f3139af3/697d3a32d4dd8427
> E. I am only using odict out of the entire package, but it seems like
> great work!
Thanks, I got fed up of seeing a number of incomplete implementations in