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 v
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>
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 v
> 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,
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 2.x
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 im
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 expectati
[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 norma
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 l
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 th
On Sun, 15 Jun 2008 05:12:38 pm Raymond Hettinger wrote:
> With an odict that preserves insertion order, you're talking about
> *deleting* the old entry and *appending* the new one, complete with
> both the new key and new value.
I certainly don't consider updating an ordered dictionary entry as
> ... 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
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 feat
* 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 proc
Steven D'Aprano 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 b
Hi,
Alexander Schremmer <2008a 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 Ordere
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
http://mail.
Martin v. Löwis 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:
> >
> >http://dev.pocoo.org/hg/sandbox/raw-file/t
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 th
-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), (k
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
> ele
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
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 state
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 th
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 th
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 optimiza
dbpokorny gmail.com 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 you
with a
Remember that it must still be possible to write (in 2.6)
True = 0
assert not True
Georg
Thomas Lee schrieb:
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.
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 th
Phillip J. Eby 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 wsg
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: o
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 t
At 02:34 PM 6/15/2008 +, Antoine Pitrou wrote:
Phillip J. Eby 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
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 discussio
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
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
> 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 i
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 t
-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 = cal
On Sun, 15 Jun 2008 07:39:05 pm Armin Ronacher wrote:
> Steven D'Aprano 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 exis
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,
wh
> 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
It is possible to get both ordered dict and sorted dict semantics in
the same type if you replace (key, value) pairs for dictionary entries
with (key,value,order) triples. The third component is a value that
indicates the place of the entry relative to the other entries. To get
an ordered dict, __s
47 matches
Mail list logo
