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),
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 progr
Raymond Hettinger 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 i
On 14-Jun-08, at 8:39 PM, Armin Ronacher wrote:
...
I noticed lately that quite a few projects are implementing their own
subclasses of `dict` that retain the order of the key/value pairs.
...
I'm +1 on this one too, as there are at least a couple of times in
recent memory when I would have fou
Hasan Diwan gmail.com> writes:
>
> 2008/6/14 Talin acm.org>:
> > There's been a lot of controversy/confusion about ordered dicts. One of the
> > sources of confusion is that people mean different things when they use the
> > term "ordered dict": In some cases, the term is used to mean a diction
From: "Talin" <[EMAIL PROTECTED]>
There's been a lot of controversy/confusion about ordered dicts.
I think that is why all earlier proposals all died.
One of
the sources of confusion is that people mean different things when they
use the term "ordered dict": In some cases, the term is used
BJörn Lindqvist gmail.com> writes:
> I think that the name ordereddict would be more readable though, and
> match the existing defaultdict class in the collections module.
While I agree that "ordered" makes more sense, it's pretty stupid to type
with two 'd's right after another.
Regards,
Armin
Guido van Rossum python.org> writes:
>
> On Sat, Jun 14, 2008 at 4:57 PM, André Malo perlig.de> wrote:
> > I find this collection of cases pretty weak as an argument for implementing
> > that in the stdlib. A lot of special purpose types would fit into such
> > reasoning, but do you want to hav
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 getName(self):
Talin wrote:
Michael Foord wrote:
Armin Ronacher wrote:
Hi,
I noticed lately that quite a few projects are implementing their own
subclasses of `dict` that retain the order of the key/value pairs.
However half of the implementations I came across are not implementing
the whole dict interface w
Greg Ewing wrote:
Cesare Di Mauro wrote:
The same happens with:
from Tkinter import *
which is a fair common instruction...
...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
Cesare Di Mauro wrote:
I agree: Python's with statement does have a completely different
meaning of the same Pascal & Co 's statement.
However, I don't agree with the FAQ on this point. I think that a
Pascal-like with statement can be achieved, even with a dynamic
language such as Python, and in
> Have the comparison function passed in as a parameter then, if it's
> None, then have it maintain the order of insertion?
No. This would contribute to the confusion, not resolve it. If it's
called "ordered dictionary", it shouldn't do sorting at all. If it does
sorting, it should be called "sort
2008/6/14 Talin <[EMAIL PROTECTED]>:
> There's been a lot of controversy/confusion about ordered dicts. One of the
> sources of confusion is that people mean different things when they use the
> term "ordered dict": In some cases, the term is used to mean a dictionary
> that remembers the order of
On Sat, Jun 14, 2008 at 11:39 PM, Armin Ronacher
<[EMAIL PROTECTED]> wrote:
> Some reasons why ordered dicts are a useful feature:
And for metaclasses or for LRU caches or for removing duplicates in a
list while maintaining order. I think that the name ordereddict would
be more readable though, a
Michael Foord wrote:
Armin Ronacher wrote:
Hi,
I noticed lately that quite a few projects are implementing their own
subclasses of `dict` that retain the order of the key/value pairs.
However half of the implementations I came across are not implementing
the whole dict interface which leads to
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 input ordering i
The odict (as proposed here, ordered on time of key insertion) looks
like a close match to the dlict needed by some of the optimization
proposals.
http://python.org/dev/peps/pep-0267/
-jJ
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
Raymond Hettinger wrote:
> PEP-3141 outlines an approach to writing binary
> operators to allow the right operand to override
> the operation if the left operand inherits the
> operation from the ABC.
> Here is my first approximation at how to write
> them for the Integral mixins:
> class Integr
Cesare Di Mauro wrote:
The same happens with:
from Tkinter import *
which is a fair common instruction...
...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
min
Hi,
Armin Ronacher active-4.com> writes:
> To fight that problem I want to proposed a new class in "collections"
> called odict which is a dict that keeps the items sorted, similar to
> a PHP array.
I'm also +1 on this. I've used the implementation you mentioned in a compiler
project of mine an
* 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 input ordering is the
> same as the output ordering.
>
> - Form data transmitted via HTT
Cesare Di Mauro wrote:
However, I don't agree with the FAQ on this point. I think that a
> Pascal-like with statement can be achieved, even with a dynamic
> language such as Python, and in a simple way.
It's not so much a matter of whether it *can* be done, but
whether there's any substantial
Armin Ronacher wrote:
Hi,
I noticed lately that quite a few projects are implementing their own
subclasses of `dict` that retain the order of the key/value pairs.
However half of the implementations I came across are not implementing
the whole dict interface which leads to weird bugs, also the p
Hi,
I noticed lately that quite a few projects are implementing their own
subclasses of `dict` that retain the order of the key/value pairs.
However half of the implementations I came across are not implementing
the whole dict interface which leads to weird bugs, also the performance
of a Python i
On Sat, Jun 14, 2008 at 1:24 PM, Simon Cross <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 14, 2008 at 10:19 PM, Cesare Di Mauro <[EMAIL PROTECTED]> wrote:
>> from Tkinter import *
>
> I discourage this too. :)
And so do I, every single time I teach Python (which is pretty often,
even though many of th
On Sat, Jun 14, 2008 at 4:18 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Jun 13, 2008, at 9:54 AM, Facundo Batista wrote:
>> Next weekend, 21 and 22, it will be the Python Bug days.
>>
>> Maybe it's worth to delay the betas one week to include this work?
>
> I think I'd rather stick to a one w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 13, 2008, at 9:54 AM, Facundo Batista wrote:
2008/6/13 Barry Warsaw <[EMAIL PROTECTED]>:
My proposal is this: I will spin another release this coming
Wednesday, June
18. If we can get both the 2.6 and 3.0 buildbots green by then,
and cl
On Sat, Jun 14, 2008 at 10:19 PM, Cesare Di Mauro <[EMAIL PROTECTED]> wrote:
> from Tkinter import *
I discourage this too. :)
Schiavo
Simob
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
On Sat, Jun 14, 2008 at 9:53 PM, Cesare Di Mauro <[EMAIL PROTECTED]> wrote:
> Just take a look at the example I reported: don't you find it easier to read?
Sure, it's perhaps a bit easier on the eyes, but readability includes
understanding what's the code does.
Let's take an example:
>on Tkinter
In data 14 giugno 2008 alle ore 22:09:56, Martin v. Löwis <[EMAIL PROTECTED]>
ha scritto:
> No, not at all. I actually *like* having to specify the object on a
> method call. I find C++/Java code very hard to read which invokes a
> method without specifying this. infront of the call - in particul
In data 14 giugno 2008 alle ore 22:09:28, Guilherme Polo <[EMAIL PROTECTED]> ha
scritto:
>> on Tkinter:
>>on ScrolledText.ScrolledText(master, width=60, height=37):
>> insert(END, self.log.getText())
>> configure(state=DISABLED)
>> see(END)
>> pack(fill=BOTH)
>>
>
> Then
> Just take a look at the example I reported: don't you find it easier to read?
No, not at all. I actually *like* having to specify the object on a
method call. I find C++/Java code very hard to read which invokes a
method without specifying this. infront of the call - in particular
when you are u
Yep. Javascript's totally botched and unusable 'with' statement is an
excellent warning of what horrors that kind of thing can wreck in a
dynamic language unless carefully designed. I also agree that .foo is
a good disambiguation syntax -- unfortunately it doesn't disambiguate
among *nested* with
On Sat, Jun 14, 2008 at 5:05 PM, Cesare Di Mauro <[EMAIL PROTECTED]> wrote:
> In data 14 giugno 2008 alle ore 21:33:40, Georg Brandl <[EMAIL PROTECTED]> ha
> scritto:
>
>> So what is the advantage to
>>
>> b = Button(self)
>> b.text = "QUIT"
>> b.fg = "red"
>> b.command = self.quit
>>
>> ?
>>
>> G
In data 14 giugno 2008 alle ore 21:33:40, Georg Brandl <[EMAIL PROTECTED]> ha
scritto:
> So what is the advantage to
>
> b = Button(self)
> b.text = "QUIT"
> b.fg = "red"
> b.command = self.quit
>
> ?
>
> Georg
In this example there are many assignaments, so there aren't many advantages.
But th
In data 14 giugno 2008 alle ore 11:03:09, Simon Cross <[EMAIL PROTECTED]> ha
scritto:
> After having read all the examples in the thread so far, let's never
> add anything like this to Python ever. It breaks so many of the
> "import this" guidelines it's scary. The biggest loss is readability.
>
On Sat, Jun 14, 2008 at 12:31 AM, <[EMAIL PROTECTED]> wrote:
>> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
>
>Guido> On Fri, Jun 13, 2008 at 9:21 AM, <[EMAIL PROTECTED]> wrote:
>>> In trying to solve a build problem with the multiprocessing code on
>>> Solaris10 I vis
Cesare Di Mauro schrieb:
Also, taking the Tk example that I used, it can be changed in the following way:
on Button(self) as b:
b.text = "QUIT"
b.fg = "red"
b.command = self.quit
pack({"side": "left"})
on Button(self) as b:
In data 14 giugno 2008 alle ore 08:55:58, Martin v. Löwis <[EMAIL PROTECTED]>
ha scritto:
> This probably belongs to python-ideas or some such, but I don't
> think this approach can work. People will want to assign to local
> variables in an "ob" block, and then be surprised that the
> assignment
At 08:19 AM 6/14/2008 +0200, Cesare Di Mauro wrote:
Assignament must work on the object's namespace, of course:
def foo(a):
on a:
x += 1
print x
will be equivalent to:
def foo(a):
a.x += 1
print a.x
Er, you need a syntactic disambiguation here to distinguish
attributes fr
On Fri, Jun 13, 2008 at 11:31 PM, <[EMAIL PROTECTED]> wrote:
>> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
>
>Guido> Ow. definitely.
>
> Yes. If I have some time Saturday and nobody beats me to it I'll fix this.
Sorry, it seems I've beaten you. :)
--
Cheers,
Benjamin Pet
On Sat, Jun 14, 2008 at 10:16 AM, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> I am a great fan of Pascal-style with blocks, and I'd love Python to get
> something like them. But I have concluded that they simply aren't
> practical in Python. Your suggestion sounds reasonable at first glance,
> but
On Sat, 14 Jun 2008 04:19:30 pm Cesare Di Mauro wrote:
> A "with" statement (such as Pascal's one) can be implemented adding a
> new scope resolution on top of LEGB. So, taking the FAQ's example,
> and using a new keyword (because with is already assigned to a
> different kind of work):
>
> def fo
44 matches
Mail list logo
