Raymond Hettinger python at rcn.com writes:
For an insertion order dictionary, there was also a question about
how to handle duplicate keys.
Given odict([(k1,v1), (k2,v2), (k1,v3)]), what should the odict.items()
return?
[(k1,v3), (k2,v2)]
[(k2,v2), (k1,v3)]
All the ordered dict
In data 15 giugno 2008 alle ore 02:24:43, Greg Ewing [EMAIL PROTECTED] ha
scritto:
...and which should *not* be used in most cases, for
the same reason.
All those tutorials that start out with 'from something
import *' are doing a lot of harm to the impressionable
minds of new programmers,
In data 15 giugno 2008 alle ore 07:43:32, Raymond Hettinger [EMAIL PROTECTED]
ha scritto:
For an insertion order dictionary, there was also a question about
how to handle duplicate keys.
Given odict([(k1,v1), (k2,v2), (k1,v3)]), what should the odict.items()
return?
[(k1,v3), (k2,v2)]
On Jun 14, 4:39 pm, Armin Ronacher [EMAIL PROTECTED]
wrote:
- in XML/HTML processing it's often desired to keep the attributes of
an tag ordered during processing. So that input ordering is the
same as the output ordering.
Munging XML is a niche.
- Form data transmitted via
Nick Coghlan schrieb:
Benjamin Peterson wrote:
On Fri, Jun 13, 2008 at 12:14 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 9:42 AM, Benjamin Peterson
[EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 11:40 AM, Raymond Hettinger [EMAIL PROTECTED] wrote:
Nick def
From: Cesare Di Mauro [EMAIL PROTECTED]
The same problem happens with dictionary updates:
d = {}
d[k1] = v1
d[k2] = v2
d[k1] = v3
The last instruction just replaces the existing entry, so I'm +0 for the first
result.
There's a difference. With dicts, the third insertion *replaces* the
I compared multiple ordered dicts now (including Babel, Django and the
C-implementation I mentioned earlier) and implemented a python version
of the ordered dict as reference implementation:
http://dev.pocoo.org/hg/sandbox/raw-file/tip/odict.py
I find the slicing API surprising. IMO, if
Georg Brandl wrote:
Nick Coghlan schrieb:
This has become a lot more complicated than what I thought we were
doing: adding PEP 8 compliant aliases for the existing methods without
otherwise changing the threading implementation. As far as I can
recall, that is all that was contained in the
Armin Ronacher wrote:
That's true, but by now there are countless of ordered dict
implementations with a mostly-compatible interface and applications and
libraries are using them already.
Even worse, most of them are slow, i.e. show a wrong algorithmic
complexity ...
I have an example
Raymond Hettinger wrote:
I don't favor one over the other. Am just pointing-out that the
proposal is a little more complex than simply wishing for an ordered
verion of a dictionary and expecting that that wish is self-defining in
a way the matches everyone's intuition, use cases, and
[EMAIL PROTECTED] wrote:
-1 for ordered dict
+1 for sorted dict
Build the ordered dict, then sort it in-place afterwards, just like a
list (alternatively, build a normal dict then feed sorted(orig.items())
to the ordered dict constructor).
The point of an ordered dict is that unlike a
On Sun, 15 Jun 2008 02:59:51 pm David Wolever wrote:
And, as far as questions about the definition of an ordered
dictionary, is there any good reason not to simply treat the dict as
a list? Something like (with the obvious bits left out):
Yes.
(1) If you implement the ordered dict as a
On Sun, 2008-06-15 at 00:12 -0700, Raymond Hettinger wrote:
From: Cesare Di Mauro [EMAIL PROTECTED]
The same problem happens with dictionary updates:
d = {}
d[k1] = v1
d[k2] = v2
d[k1] = v3
The last instruction just replaces the existing entry, so I'm +0 for the
first result.
... like your implementation. It is not too hard to get the delitem
O(log n) compared to your O(n), see here:
http://codespeak.net/svn/user/arigo/hack/pyfuse/OrderedDict.py
So many people are implementing this kind of data type but do not really
care about making as fast as it could be
On Sun, 15 Jun 2008 06:42:32 pm laurent wrote:
An other way to think of such a structure would be as a list, for
which each item would also have an associated key.
I think someone mentioned the link with a list during this thread,
but here I am not referring to implementation, but the feature
* Guido van Rossum wrote:
On Sat, Jun 14, 2008 at 4:57 PM, André Malo [EMAIL PROTECTED] wrote:
* Armin Ronacher wrote:
Some reasons why ordered dicts are a useful feature:
- in XML/HTML processing it's often desired to keep the attributes
of an tag ordered during processing. So that
Steven D'Aprano steve at pearwood.info writes:
Conceptually, I would expect the following behaviour:
od = odict()
od[1] = 'spam' # insert a new key
od[2] = 'parrot' # insert a new key
od[1] = 'ham' # modify existing key
od.items()
[(1, 'ham'), (2, 'parrot')]
That behavior is
Hi,
Alexander Schremmer 2008a at usenet.alexanderweb.de writes:
Even worse, most of them are slow, i.e. show a wrong algorithmic
complexity ...
I already said that in the initial post.
I have an example implementation here that incorporates the ideas
from ordereddict, Django's OrderedDict
There are far more responses for that topic than I imagined so I would love
to write a PEP about that topic, incorporating the ideas/questions and
suggestions discussed here.
Regards,
Armin
___
Python-Dev mailing list
Python-Dev@python.org
Martin v. Löwis martin at v.loewis.de writes:
I compared multiple ordered dicts now (including Babel, Django and the
C-implementation I mentioned earlier) and implemented a python version
of the ordered dict as reference implementation:
From: Armin Ronacher [EMAIL PROTECTED]
There are far more responses for that topic than I imagined so I would love
to write a PEP about that topic, incorporating the ideas/questions and
suggestions discussed here.
Instead of going straight to a PEP, I recommend opening a new wiki page
on the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 15, 2008, at 1:43 AM, Raymond Hettinger wrote:
For an insertion order dictionary, there was also a question about
how to handle duplicate keys.
Given odict([(k1,v1), (k2,v2), (k1,v3)]), what should the
odict.items() return?
[(k1,v3),
Armin Ronacher wrote:
- in XML/HTML processing it's often desired to keep the attributes of
an tag ordered during processing. So that input ordering is the
same as the output ordering.
- [...]
XML libraries such as etree could add support for it when creating
elements
On Sun, Jun 15, 2008 at 3:49 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
Georg Brandl wrote:
Nick Coghlan schrieb:
This has become a lot more complicated than what I thought we were doing:
adding PEP 8 compliant aliases for the existing methods without otherwise
changing the threading
My work on the AST optimizer has led me down the path of attempting to
replace things like Name(True) with Const(Py_True) nodes. This works
fine most of the time, with the exception of the xmlrpclib module, where
True and False are actually redefined:
True, False = True, False
As I stated
On Sun, Jun 15, 2008 at 8:11 AM, Thomas Lee [EMAIL PROTECTED] wrote:
The simplest options I can think of to remedy this:
1. A setattr hack: setattr(__import__(__name__), True, True)
2. Remove all optimization of Name(True) and Name(False)
3. Skip AST optimization entirely for the LHS of
Option 4 just struck me: only optimize Name nodes if they have a Load
ctx. This makes even more sense: in a Store context, we almost
invariably want the name rather than the constant.
Cheers,
T
Thomas Lee wrote:
My work on the AST optimizer has led me down the path of attempting to
replace
Benjamin Peterson wrote:
On Sun, Jun 15, 2008 at 8:11 AM, Thomas Lee [EMAIL PROTECTED] wrote:
The simplest options I can think of to remedy this:
1. A setattr hack: setattr(__import__(__name__), True, True)
2. Remove all optimization of Name(True) and Name(False)
3. Skip AST optimization
dbpokorny at gmail.com dbpokorny at gmail.com writes:
If you don't like the fact that your web application framework loses
the order of its key:value pairs relative to the page, then you should
bring it up with the developers.
Who will then point up that to retain that order while providing
At 02:19 PM 6/15/2008 +, Antoine Pitrou wrote:
Ordered dicts, dicts that remember the chronological order of their
insertion, don't sound generally useful.
They are generally useful in any case where you want to handle key-value
pairs while not confusing a human operator by messing up the
Phillip J. Eby pje at telecommunity.com writes:
As for the other uses for ordered dictionaries, I find it simplest to
just use a list of key,value pairs, and only transform it to a
dictionary or dictionary-like structure as needed, using tools like
the cgi module, the email package, or
Georg Brandl wrote:
Remember that it must still be possible to write (in 2.6)
True = 0
assert not True
Ah of course. Looks like I should just avoid optimizations of
Name(True) and Name(False) all together. That's a shame!
Cheers,
T
Georg
Thomas Lee schrieb:
Option 4 just struck me: only
Thomas Lee schrieb:
Georg Brandl wrote:
Remember that it must still be possible to write (in 2.6)
True = 0
assert not True
Ah of course. Looks like I should just avoid optimizations of
Name(True) and Name(False) all together. That's a shame!
We can of course decide to make assignment to
At 02:34 PM 6/15/2008 +, Antoine Pitrou wrote:
Phillip J. Eby pje at telecommunity.com writes:
As for the other uses for ordered dictionaries, I find it simplest to
just use a list of key,value pairs, and only transform it to a
dictionary or dictionary-like structure as needed, using
Georg Brandl wrote:
We can of course decide to make assignment to True and False
illegal in 2.7 :)
Georg
Great to know that's an option. There's little-to-no chance of this
making 2.6.
I might just avoid trying to treat True/False as real constants until
there's been a proper discussion
On Sun, Jun 15, 2008 at 6:01 AM, Barry Warsaw [EMAIL PROTECTED] wrote:
On Jun 15, 2008, at 1:43 AM, Raymond Hettinger wrote:
The second one is a bit weird because a key loses its place whenever
the value is updated.
Heh, neither of these would work for the email package's own flavor of
2008/6/15 Raymond Hettinger [EMAIL PROTECTED]:
From: Armin Ronacher [EMAIL PROTECTED]
There are far more responses for that topic than I imagined so I would
love
to write a PEP about that topic, incorporating the ideas/questions and
suggestions discussed here.
Instead of going straight to
Sorry, that's correct. This is against 2.6 trunk.
That's the idea -- in 3.x this will be a non-issue.
It's perhaps even less of an issue than you think: In 3.0,
True and False are *already* compiled into constants. So
any additional special casing would make no difference.
Regards,
Martin
On Sun, Jun 15, 2008 at 1:03 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
Raymond Hettinger wrote:
I don't favor one over the other. Am just pointing-out that the proposal
is a little more complex than simply wishing for an ordered verion of a
dictionary and expecting that that wish is
On Jun 14, 2008, at 8:26 PM, Guido van Rossum wrote:
No, but an ordered dict happens to be a *very* common thing to need,
for a variety of reasons. So I'm +0.5 on adding this to the
collections module. However someone needs to contribute working code.
Here's an LRU cache that I've used a few
-1 to this 'on' statement.
On Sat, Jun 14, 2008 at 10:14 PM, Nick Coghlan [EMAIL PROTECTED] wrote:
It isn't that a Pascal-with-style statement can't be achieved, it's that it
is pointless syntactic sugar in Python. Just use o =
long_complicated_object_name instead.
+1 to this reason.
--
On Jun 15, 2008, at 12:20 PM, zooko wrote:
So, it would be easy to change those two behaviors in order to use
this implementation. There are actually three implementations in
that file: one that is asymptotically O(1) for all operations
(using a double-linked list woven into the values of
+1 on updating the FAQ. Maybe we could even have it notice that a
read-only version of the desired semantic for 'with' is easily hacked
with the *current* semantic of 'with'...:
@contextlib.contextmanager
def readonly(anobj):
caller_globals = sys._getframe(2).f_globals
saved_globals =
On Sun, 15 Jun 2008 07:39:05 pm Armin Ronacher wrote:
Steven D'Aprano steve at pearwood.info writes:
Conceptually, I would expect the following behaviour:
od = odict()
od[1] = 'spam' # insert a new key
od[2] = 'parrot' # insert a new key
od[1] = 'ham' # modify existing key
Talin wrote:
In some cases, the term is used to mean a
dictionary that remembers the order of insertions, and in other cases it
is used to mean a sorted dict,
I would be more in favor of the idea if we could come up with a less
ambiguous naming scheme.
Perhaps indexed list or maybe keyed
Cesare Di Mauro wrote:
OK, but nobody have questioned about removing 'from something import *' just to
help noobs...
I'm not advocating removing it from the language, far
from it. I agree there are legitimate uses for it in
rare cases.
I just wish that people wouldn't use it in tutorials,
But my point is that we we need to focus on finding real use cases and
exploring how best to solve them. Otherwise we might as well throw in
my OrderedSet[1] as-is, despite that it's got no comments and no
ratings. Even I don't seem to use it.
I'm mostly lurking on these threads, so as to
47 matches
Mail list logo
