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
> 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
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
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
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
+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 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 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 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
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
> 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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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 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
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
-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
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
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
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.
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
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
* 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
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
> ... 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 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
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 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
[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
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
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
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
> 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,
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
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>
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
47 matches
Mail list logo
