Re: PEP proposal: sequence expansion support for yield statement: yield *

On Fri, Apr 22, 2016 at 1:19 AM, justin walters wrote: > I agree with the others that the new syntax is not needed. > > I would also like to point out that I believe any new added syntax or > functionality should avoid the use of '*' and '**' as both of these > characters are already used for many

Re: PEP proposal: sequence expansion support for yield statement: yield *

I agree with the others that the new syntax is not needed. I would also like to point out that I believe any new added syntax or functionality should avoid the use of '*' and '**' as both of these characters are already used for many things such as optional arguments and mathematical operators. Ad

Re: PEP proposal: sequence expansion support for yield statement: yield *

On Thu, 21 Apr 2016 05:34 am, Ken Seehart wrote: > Currently the common pattern for yielding the elements in a sequence is as > follows: > > for x in sequence: yield x > > I propose the following replacement (the result would be identical): > > yield *sequence Others have already pointed o

Re: PEP proposal: sequence expansion support for yield statement: yield *

On Thu, Apr 21, 2016 at 8:26 AM, wrote: > Anyway, thanks for the link. And I suppose checking Python 3 for > implementation would be a good prior step as well! Sadly, "yield from" is not > in python 2.7, but it's presence in python 3.3 renders my proposal dead as a > parrot without a liver. >

Re: PEP proposal: sequence expansion support for yield statement: yield *

On Wednesday, April 20, 2016 at 1:00:45 PM UTC-7, Ethan Furman wrote: > On 04/20/2016 12:34 PM, Ken Seehart wrote: > > New ideas for Python are typically vetted on Python Ideas. [1] > > > Currently the common pattern for yielding the elements in a sequence > > is as follows: > > > >for x in

Re: PEP proposal: sequence expansion support for yield statement: yield *

Currently the common pattern for yielding the elements in a sequence is as follows: for x in sequence: yield x I propose the following replacement (the result would be identical): yield *sequence imho the current syntax is much more intuitive, it is obvious to infer what it does by

Re: PEP proposal: sequence expansion support for yield statement: yield *

On 04/20/2016 12:34 PM, Ken Seehart wrote: New ideas for Python are typically vetted on Python Ideas. [1] Currently the common pattern for yielding the elements in a sequence > is as follows: for x in sequence: yield x I propose the following replacement (the result would be identical):

Re: PEP proposal: sequence expansion support for yield statement: yield *

On Wed, Apr 20, 2016, at 15:34, Ken Seehart wrote: > Currently the common pattern for yielding the elements in a sequence is > as follows: > > for x in sequence: yield x > > I propose the following replacement (the result would be identical): > > yield *sequence yield from sequence -- http

PEP proposal: sequence expansion support for yield statement: yield *

Currently the common pattern for yielding the elements in a sequence is as follows: for x in sequence: yield x I propose the following replacement (the result would be identical): yield *sequence The semantics are somewhat different from argument expansion (from which the syntax is borrow

Re: PEP Proposal

On Sep 25, 2:24 pm, [EMAIL PROTECTED] wrote: > Hi, > > sorry, I have these ideas for longer than 10 years, please have a look on it > and comment on it. Thx. > > > > This is another proposal for introducing types into Python. > > There are many reasons for incorporating types into Python, but

Re: PEP Proposal

On Fri, Sep 26, 2008 at 6:14 AM, <[EMAIL PROTECTED]> wrote: > Typed parameters. Method-Declaration-filtered-typed parameters. That's what > I'm thinking of. Why do we need this (rubbish) ? Seriously. The use-case is far too small. And don't invent use-cases either. Instead of coming up with idea

Re: PEP Proposal

On Sep 25, 4:04 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote: > En Thu, 25 Sep 2008 16:24:58 -0300, <[EMAIL PROTECTED]> escribió: > > > sorry, I have these ideas for longer than 10 years, please have a look   > > on it > > and comment on it. Thx. > > > This is another proposal for introducing

Re: PEP Proposal

[EMAIL PROTECTED] schrieb: Gabriel Genellina wrote: En Thu, 25 Sep 2008 16:24:58 -0300, <[EMAIL PROTECTED]> escribió: sorry, I have these ideas for longer than 10 years, please have a look on it and comment on it. Thx. This is another proposal for introducing types into Python. You got the

Re: PEP Proposal

[EMAIL PROTECTED] a écrit : Gabriel Genellina wrote: En Thu, 25 Sep 2008 16:24:58 -0300, <[EMAIL PROTECTED]> escribió: sorry, I have these ideas for longer than 10 years, please have a look on it and comment on it. Thx. This is another proposal for introducing types into Python. You got the

Re: PEP Proposal

On Sep 25, 12:24 pm, [EMAIL PROTECTED] wrote: > def whoisthethief("List" x): > return iknowit(x) > > def whoisthethief("String" x, "String" y): > return iknowit([x,y]) > I dunno if this is very Pythonic in nature, but I've done things like rebinding methods dynamically. ex: >>> def test(a):

Re: PEP Proposal

Gabriel Genellina wrote: > En Thu, 25 Sep 2008 16:24:58 -0300, <[EMAIL PROTECTED]> escribió: > >> sorry, I have these ideas for longer than 10 years, please have a look >> on it >> and comment on it. Thx. >> >> This is another proposal for introducing types into Python. > > You got the terminolo

Re: PEP Proposal

En Thu, 25 Sep 2008 16:24:58 -0300, <[EMAIL PROTECTED]> escribió: sorry, I have these ideas for longer than 10 years, please have a look on it and comment on it. Thx. This is another proposal for introducing types into Python. You got the terminology wrong. Python had "types" from the very

PEP Proposal

Hi, sorry, I have these ideas for longer than 10 years, please have a look on it and comment on it. Thx. This is another proposal for introducing types into Python. There are many reasons for incorporating types into Python, but there is also a lot of concern about doing so because of des

Re: PEP proposal optparse

James <[EMAIL PROTECTED]> writes: > I would like to know your thoughts on a proposed change to optparse > that I have planned. It is possible to add default values to > multiple options using the set_defaults. However, when adding > descriptions to options the developer has to specify it in ea

Re: PEP proposal optparse

On Thu, Sep 18, 2008 at 9:02 PM, James Nicolson <[EMAIL PROTECTED]> wrote: > Perhaps it is better to keep descriptions short and store longer > descriptions elsewhere, but there are many programs that have long > descriptions, for example try: ls --help (at least on my machine a lot > of these desc

Re: PEP proposal optparse

On 2008-09-18, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote: > On Thu, 18 Sep 2008 11:07:45 -0500, Grant Edwards wrote: > >> While we're making suggestions, I've always wished that the --help >> output displayed the default values for options in addition to the help >> text specified by the u

Re: PEP proposal optparse

On Thu, 18 Sep 2008 11:07:45 -0500, Grant Edwards wrote: > While we're making suggestions, I've always wished that the --help > output displayed the default values for options in addition to the help > text specified by the user. I end up having to enter the default values > twice -- once as a ke

Re: PEP proposal optparse

Grant Edwards wrote: While we're making suggestions, I've always wished that the --help output displayed the default values for options in addition to the help text specified by the user. I end up having to enter the default values twice -- once as a keyword argument and again in the help text.

Re: PEP proposal optparse

While we're making suggestions, I've always wished that the --help output displayed the default values for options in addition to the help text specified by the user. I end up having to enter the default values twice -- once as a keyword argument and again in the help text. Then later when I deci

Re: PEP proposal optparse

On Thu, 18 Sep 2008 03:37:54 -0700, James wrote: > Hi, > > I would like to know your thoughts on a proposed change to optparse that > I have planned. It is possible to add default values to multiple options > using the set_defaults. However, when adding descriptions to options the > developer has

Re: PEP proposal optparse

James Mills wrote: As you can see (as long as you're reading this in fixed-width fonts) it _is_ very readable. given that it only relies on indentation from the left margin, it's no less readable in a proportional font (unless you're using an font with variable-width spaces, that is ;-).

Re: PEP proposal optparse

Perhaps it is better to keep descriptions short and store longer descriptions elsewhere, but there are many programs that have long descriptions, for example try: ls --help (at least on my machine a lot of these descriptions are quite long). 2008/9/18 James Mills <[EMAIL PROTECTED]>: > Hi James, >

Re: PEP proposal optparse

Hi James, I can't say I really agree with your proposal. I tend to keep the help descriptions of my options short and concise and to the point. Also, one must use the language's features (indentation) to your advantage, as doing so ensure readability. For example (from my bhimport tool): def p

PEP proposal optparse

Hi, I would like to know your thoughts on a proposed change to optparse that I have planned. It is possible to add default values to multiple options using the set_defaults. However, when adding descriptions to options the developer has to specify it in each add_option() call. This results in unre

Re: Micro-threading PEP proposal announcement

Pau Freixes wrote: When can I read this PEP ? I'm interesting I wanted to make everybody aware that I've posted a (rather long and involved) PEP proposal for adding micro-threading to Python on python-ideas for feedback and review. Python-ideas is another maili

Re: Micro-threading PEP proposal announcement

Sorry Bruce, When can I read this PEP ? I'm interesting Bye On Mon, Aug 25, 2008 at 7:15 PM, Bruce Frederiksen <[EMAIL PROTECTED]>wrote: > I wanted to make everybody aware that I've posted a (rather long and > involved) PEP proposal for adding micro-threading to Python

Micro-threading PEP proposal announcement

I wanted to make everybody aware that I've posted a (rather long and involved) PEP proposal for adding micro-threading to Python on python-ideas for feedback and review. In a nutshell, this proposal implements the Twisted Deferred/Reactor at the C level so that the Python programmer get

Re: sorteddict PEP proposal [started off as orderedict]

On 12 Oct, 09:17, Paul Rubin <http://[EMAIL PROTECTED]> wrote: > Mark Summerfield <[EMAIL PROTECTED]> writes: > > Below is a PEP proposal for a sorteddict. ... > > Is this proposal dead? I'd been meaning to post some thoughts which I > still haven't gotte

Re: sorteddict PEP proposal [started off as orderedict]

Mark Summerfield <[EMAIL PROTECTED]> writes: > Below is a PEP proposal for a sorteddict. ... Is this proposal dead? I'd been meaning to post some thoughts which I still haven't gotten around to writing up, and am wondering whether to keep it on my todo list. -- http://mail

Re: sorteddict [was a PEP proposal, but isn't anymore!]

"Duncan Booth" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | Subclassing doesn't have to imply a common implementation, just a common | interface. True, but in Python, subclassing is usually done to reuse implementation. Interface subclassing is usually from a common abstract ba

RE: sorteddict [was a PEP proposal, but isn't anymore!]

"Hamilton, William " <[EMAIL PROTECTED]> wrote: >> From: thebjorn >> What's stabledict? I'm assuming that ordereddict is a mapping that >> maintains insertion order(?) > > Yes, ordereddict is a dict that maintains insertion order. Stabledict > is probably a dict that maintains _an_ order, so tha

RE: sorteddict [was a PEP proposal, but isn't anymore!]

> From: thebjorn > What's stabledict? I'm assuming that ordereddict is a mapping that > maintains insertion order(?) Yes, ordereddict is a dict that maintains insertion order. Stabledict is probably a dict that maintains _an_ order, so that repr() and the like return the same value when used on d

Re: sorteddict [was a PEP proposal, but isn't anymore!]

On Sep 29, 7:13 pm, Duncan Booth <[EMAIL PROTECTED]> wrote: [...] > Right now I think there are probably three dict variants needed: sorteddict > (still waiting for a convincing use case), ordereddict (lots of use cases), > and this one: stabledict. What's stabledict? I'm assuming that ordereddict

Re: sorteddict [was a PEP proposal, but isn't anymore!]

thebjorn <[EMAIL PROTECTED]> wrote: > On Sep 29, 4:23 pm, Duncan Booth <[EMAIL PROTECTED]> wrote: > [...] >> Another example would be if you had a library which serialised a >> dictionary to xml. There is nothing wrong with the library if it >> doesn't care about order, but if you have some other

Re: sorteddict [was a PEP proposal, but isn't anymore!]

On Sep 29, 4:23 pm, Duncan Booth <[EMAIL PROTECTED]> wrote: [...] > Another example would be if you had a library which serialised a dictionary > to xml. There is nothing wrong with the library if it doesn't care about > order, but if you have some other reason why you want the xml to be stable > (

Re: sorteddict [was a PEP proposal, but isn't anymore!]

Antoon Pardon <[EMAIL PROTECTED]> wrote: > On 2007-09-27, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> Is this a practical use case? When are sequential visits of all >> elements in order frequently suspended to make insertions and >> deletions, with a need for efficient lookup by key? > >

Re: sorteddict [was a PEP proposal, but isn't anymore!]

On 2007-09-27, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Is this a practical use case? When are sequential visits of all > elements in order frequently suspended to make insertions and > deletions, with a need for efficient lookup by key? Does it need to be a sequential visit of *all* elemen

Re: sorteddict [was a PEP proposal, but isn't anymore!]

I don't see a focused discussion of computational complexity of a sorted dict; its API cannot be simpler than sorting a dictionary and it has issues and complications that have already been discussed without completely satisfactory solutions, so the only possible reason to adopt a sorted dict is th

Re: sorteddict PEP proposal [started off as orderedict]

Duncan Booth <[EMAIL PROTECTED]> writes: > Ok, your choice, just be aware that by using such a restrictive license you > will dissuade a lot of people from using your code. You've prevented your > module being used in any existing projects with Python license, GPL v2, or > probably any license o

Re: sorteddict PEP proposal [started off as orderedict]

Mark Summerfield <[EMAIL PROTECTED]> wrote: > As for the license, while it is on PyPI, I'll leave it as GPL v 3. If > it was wanted for the standard library (and I can't see that ever > happening), I will happily change it to the one that is preferred for > Python modules. Ok, your choice, just b

Re: sorteddict [was a PEP proposal, but isn't anymore!]

On 26 Sep, 18:59, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Mark Summerfield] > > > Below is a PEP proposal for a sorteddict. It arises out of a > > discussion on this list that began a few weeks ago with the subject of > > "An ordered dictionary for t

Re: sorteddict PEP proposal [started off as orderedict]

On 27 Sep, 08:32, Duncan Booth <[EMAIL PROTECTED]> wrote: > Paul Hankin <[EMAIL PROTECTED]> wrote: > >> A key which is in dict must be either in __keycache or in __addkeys, but > >> never in both. > > > Yes, I'm sorry: you're right. > > > But there's a different bug: if you delete a key that's not

Re: sorteddict PEP proposal [started off as orderedict]

Mark Summerfield wrote: > The sorteddict API that has emerged so far is (1) apart from the > constructor, everything is identical to dict, (2) the constructor > takes the same args as sorted(), so if you want to seed with a dict or > with keywords you write sorteddict(dict(a=1,b=2), ...), (or you c

Re: sorteddict PEP proposal [started off as orderedict]

Paul Hankin <[EMAIL PROTECTED]> wrote: >> A key which is in dict must be either in __keycache or in __addkeys, but >> never in both. > > Yes, I'm sorry: you're right. > > But there's a different bug: if you delete a key that's not in the > dict, you'll add it to the deleted list before the excep

Re: sorteddict PEP proposal [started off as orderedict]

On 2007-09-26, Mark Summerfield <[EMAIL PROTECTED]> wrote: > On 26 Sep, 13:22, Antoon Pardon <[EMAIL PROTECTED]> wrote: >> >> Well you should decide what you want. In a previous exchange one of the >> things that was wanted was that you could already seed a tree by using >> key word arguments so th

Re: sorteddict PEP proposal [started off as orderedict]

On Sep 26, 9:52 pm, Duncan Booth <[EMAIL PROTECTED]> wrote: > Paul Hankin <[EMAIL PROTECTED]> wrote: > >> So should Duncan's > > >> def __removekey(self, key): > >> if key in self.__addkeys: > >> del self.__addkeys[key] > >> else: > >> self.__delkeys.add(

Re: sorteddict PEP proposal [started off as orderedict]

Paul Hankin <[EMAIL PROTECTED]> wrote: >> So should Duncan's >> >> def __removekey(self, key): >> if key in self.__addkeys: >> del self.__addkeys[key] >> else: >> self.__delkeys.add(key) >> >> be changed to: >> >> def __removekey(self, key): >>

Re: sorteddict PEP proposal [started off as orderedict]

[James Stroud ] > Maybe its the PEP killers who act prematurely because I friggin' love > genexps and the little generators they generate. No, it's the PEP author who controls when they ask for pronouncement. The natural instinct is to ask for pronouncement as soon as you have an implementation an

Re: sorteddict PEP proposal [started off as orderedict]

Raymond Hettinger wrote: > As one who was submitted many PEPs, I can advise that the quickest way > to irrevocably kill an idea is to submit a PEP to early (we almost > didn't get genexps because the PEP was submitted pre-maturely). Maybe its the PEP killers who act prematurely because I friggin'

Re: sorteddict PEP proposal [started off as orderedict]

Mark Summerfield <[EMAIL PROTECTED]> writes: > The sorteddict API that has emerged so far is (1) apart from the > constructor, everything is identical to dict, I don't see this as necessary, it's ok if it resembles dict as much as dbm does. > (2) the constructor takes the same args as sorted(),

Re: sorteddict PEP proposal [started off as orderedict]

[Mark Summerfield] > Below is a PEP proposal for a sorteddict. It arises out of a > discussion on this list that began a few weeks ago with the subject of > "An ordered dictionary for the Python library?" It is worth remembering that the long sought after datatype was a dict t

Re: sorteddict PEP proposal [started off as orderedict]

On 26 Sep, 16:20, Paul Hankin <[EMAIL PROTECTED]> wrote: > On Sep 26, 3:24 pm, Mark Summerfield <[EMAIL PROTECTED]> > wrote: > > > On 26 Sep, 14:59, Paul Hankin <[EMAIL PROTECTED]> wrote: > > > > On Sep 26, 2:46 pm, Duncan Booth <[EMAIL PROTECTED]> wrote: > > > > > Paul Hankin <[EMAIL PROTECTED]> w

Re: sorteddict PEP proposal [started off as orderedict]

Mark Summerfield wrote: > The sorteddict API that has emerged so far is (1) apart from the > constructor, everything is identical to dict, (2) the constructor > takes the same args as sorted(), so if you want to seed with a dict or > with keywords you write sorteddict(dict(a=1,b=2), ...), (or you

Re: sorteddict PEP proposal [started off as orderedict]

On Sep 26, 3:24 pm, Mark Summerfield <[EMAIL PROTECTED]> wrote: > On 26 Sep, 14:59, Paul Hankin <[EMAIL PROTECTED]> wrote: > > > > > On Sep 26, 2:46 pm, Duncan Booth <[EMAIL PROTECTED]> wrote: > > > > Paul Hankin <[EMAIL PROTECTED]> wrote: > > > > More flexibly, keep a set of inserted keys that hav

Re: sorteddict PEP proposal [started off as orderedict]

Mark Summerfield wrote: > On 26 Sep, 13:22, Antoon Pardon <[EMAIL PROTECTED]> wrote: [...] >> So it seems the API needs some more sorting out. > > I think you missed some of the previous postings. > > The sorteddict API that has emerged so far is (1) apart from the > constructor, everything is id

Re: sorteddict PEP proposal [started off as orderedict]

On 26 Sep, 14:59, Paul Hankin <[EMAIL PROTECTED]> wrote: > On Sep 26, 2:46 pm, Duncan Booth <[EMAIL PROTECTED]> wrote: > > > Paul Hankin <[EMAIL PROTECTED]> wrote: > > > More flexibly, keep a set of inserted keys that haven't yet been > > > included in the sorted list, and a set of deleted keys tha

Re: sorteddict PEP proposal [started off as orderedict]

On Sep 26, 2:46 pm, Duncan Booth <[EMAIL PROTECTED]> wrote: > Paul Hankin <[EMAIL PROTECTED]> wrote: > > More flexibly, keep a set of inserted keys that haven't yet been > > included in the sorted list, and a set of deleted keys that haven't > > yet been removed from the sorted list. The cache is i

Re: sorteddict PEP proposal [started off as orderedict]

Paul Hankin <[EMAIL PROTECTED]> wrote: >> I suspect that for many use patterns you could improve performance >> significantly by having two levels of invalidation for the the key >> list: in __setitem__, if the key already exists you don't need to >> discard the list in __keycache (although if a k

Re: sorteddict PEP proposal [started off as orderedict]

On 26 Sep, 13:22, Antoon Pardon <[EMAIL PROTECTED]> wrote: > On 2007-09-26, Mark Summerfield <[EMAIL PROTECTED]> wrote: > > > > > On 26 Sep, 11:27, Hrvoje Niksic <[EMAIL PROTECTED]> wrote: > >> Mark Summerfield <[EMAIL PROTECTED]> writes: > >> > On 26 Sep, 09:51, Hrvoje Niksic <[EMAIL PROTECTED]> w

Re: sorteddict PEP proposal [started off as orderedict]

Paul Hankin <[EMAIL PROTECTED]> writes: >> An implementation of sorted dict using a balanced tree as the >> underlying data structure would give decent performance in all the >> mentioned use cases. For example, red-black trees search, insert, >> and delete in O(log n) time. > > But dicts do sear

Re: sorteddict PEP proposal [started off as orderedict]

On 2007-09-26, Mark Summerfield <[EMAIL PROTECTED]> wrote: > On 26 Sep, 11:27, Hrvoje Niksic <[EMAIL PROTECTED]> wrote: >> Mark Summerfield <[EMAIL PROTECTED]> writes: >> > On 26 Sep, 09:51, Hrvoje Niksic <[EMAIL PROTECTED]> wrote: >> >> Duncan Booth <[EMAIL PROTECTED]> writes: >> >> > I that's the

Re: sorteddict PEP proposal [started off as orderedict]

On Sep 26, 9:51 am, Hrvoje Niksic <[EMAIL PROTECTED]> wrote: > Duncan Booth <[EMAIL PROTECTED]> writes: > > I that's the point though: you can't write one implementation that has good > > performance for all patterns of use > > An implementation of sorted dict using a balanced tree as the > underly

Re: sorteddict PEP proposal [started off as orderedict]

On Sep 26, 9:31 am, Duncan Booth <[EMAIL PROTECTED]> wrote: > Mark Summerfield <[EMAIL PROTECTED]> wrote: > > As you've no doubt realised, this particular implementation gives best > > performance when the pattern of use is: lots of edits, lots of > > lookups, ..., and gives worst performance when

Re: sorteddict PEP proposal [started off as orderedict]

On 26 Sep, 11:27, Hrvoje Niksic <[EMAIL PROTECTED]> wrote: > Mark Summerfield <[EMAIL PROTECTED]> writes: > > On 26 Sep, 09:51, Hrvoje Niksic <[EMAIL PROTECTED]> wrote: > >> Duncan Booth <[EMAIL PROTECTED]> writes: > >> > I that's the point though: you can't write one implementation > >> > that has

Re: sorteddict PEP proposal [started off as orderedict]

Mark Summerfield <[EMAIL PROTECTED]> writes: > On 26 Sep, 09:51, Hrvoje Niksic <[EMAIL PROTECTED]> wrote: >> Duncan Booth <[EMAIL PROTECTED]> writes: >> > I that's the point though: you can't write one implementation >> > that has good performance for all patterns of use >> >> An implementation of

Re: sorteddict PEP proposal [started off as orderedict]

On 26 Sep, 09:51, Hrvoje Niksic <[EMAIL PROTECTED]> wrote: > Duncan Booth <[EMAIL PROTECTED]> writes: > > I that's the point though: you can't write one implementation that has good > > performance for all patterns of use > > An implementation of sorted dict using a balanced tree as the > underlyin

Re: sorteddict PEP proposal [started off as orderedict]

Duncan Booth <[EMAIL PROTECTED]> writes: > I that's the point though: you can't write one implementation that has good > performance for all patterns of use An implementation of sorted dict using a balanced tree as the underlying data structure would give decent performance in all the mentioned

Re: sorteddict PEP proposal [started off as orderedict]

Mark Summerfield <[EMAIL PROTECTED]> wrote: > As you've no doubt realised, this particular implementation gives best > performance when the pattern of use is: lots of edits, lots of > lookups, ..., and gives worst performance when the pattern of use is: > edit, lookup, edit, lookup (in which case

Re: sorteddict PEP proposal [started off as orderedict]

On 25 Sep, 22:33, Paul Hankin <[EMAIL PROTECTED]> wrote: > On Sep 25, 9:55 pm, Mark Summerfield <[EMAIL PROTECTED]> > wrote: > > > ... > > class sorteddict(dict): > > > ... > > if self.__keys is None: > > self.__keys = sorted(dict.keys(self), cmp=self.__cmp, > >

Re: sorteddict PEP proposal [started off as orderedict]

On Sep 25, 9:55 pm, Mark Summerfield <[EMAIL PROTECTED]> wrote: > ... > class sorteddict(dict): > > ... > if self.__keys is None: > self.__keys = sorted(dict.keys(self), cmp=self.__cmp, > key=self.__key, > reverse=self.__reverse) You'd be better

Re: sorteddict PEP proposal [started off as orderedict]

On 25 Sep, 20:28, Paul Hankin <[EMAIL PROTECTED]> wrote: > On Sep 25, 7:58 pm, Steven Bethard <[EMAIL PROTECTED]> wrote: > > > > > > Paul Hankin wrote: > > > ... > > > class sorteddict(dict): > > > "A sorted dictionary" > > > def __init__(self, arg=None, cmp=None, key=None, reverse=False):

Re: sorteddict PEP proposal [started off as orderedict]

Mark Summerfield wrote: > Hmmm, managed to confuse myself with 'b' and 'd'! > > d = sorteddict({1:"one", 3:"three", 5:"five", 99:"ninetynine"}) > > d.items() > > [(1, 'one'), (3, 'three'), (5, 'five'), (99, 'ninetynine')] > > d[3], d.value(3) > > ('three', 'ninetynine') > > So using [] return

Re: sorteddict PEP proposal [started off as orderedict]

Mark Summerfield wrote: > On 2007-09-25, Andrew Durdin wrote: >> e.g. sorteddict({1:'a', 3:'b': 5:'c', 99:'d'})[3] should return 'b', not >> 'd'. > > The sorteddict really does work in key order, so: > > d = sorteddict({1:'a', 3:'b', 5:'c', 99:'d'}) > d.items() > [(1, 'a'), (3, 'b'),

Re: sorteddict PEP proposal [started off as orderedict]

On Sep 25, 1:35 pm, thebjorn <[EMAIL PROTECTED]> wrote: > On Sep 25, 10:53 am, Mark Summerfield <[EMAIL PROTECTED]> > wrote: > > > Hi, > > > Below is a PEP proposal for a sorteddict. It arises out of a > > discussion on this list that began a few wee

Re: sorteddict PEP proposal [started off as orderedict]

On Sep 25, 7:58 pm, Steven Bethard <[EMAIL PROTECTED]> wrote: > > Paul Hankin wrote: > > ... > > class sorteddict(dict): > > "A sorted dictionary" > > def __init__(self, arg=None, cmp=None, key=None, reverse=False): > > if arg: > > ... > > With this is the implementation, I'm de

Re: sorteddict PEP proposal [started off as orderedict]

Steven Bethard <[EMAIL PROTECTED]> writes: > With this is the implementation, I'm definitely -1. Not because it's a > bad implementation, but because if the iteration is always doing a > sort, then there's no reason for a separate data structure. Agreed. A true sorted dict would keep its keys so

Re: sorteddict PEP proposal [started off as orderedict]

Paul Hankin wrote: > On Sep 25, 12:51 pm, Mark Summerfield <[EMAIL PROTECTED]> > wrote: >> On 25 Sep, 12:19, Paul Hankin <[EMAIL PROTECTED]> wrote: >> >> >> >>> Recall sorted... >>> sorted(iterable, cmp=None, key=None, reverse=False) --> new sorted >>> list >>> So why not construct sorteddicts

RE: sorteddict PEP proposal [started off as orderedict]

> From: Paul Hankin > > > Here's a first go. Sorting occurs when the keys are iterated over, > making it fast (almost as a dict) for construction, insertion, and > deletion, but slow if you're iterating a lot. You should look at some > use cases to decide if this approach is best, or if a sorted

Re: sorteddict PEP proposal [started off as orderedict]

On Sep 25, 12:51 pm, Mark Summerfield <[EMAIL PROTECTED]> wrote: > On 25 Sep, 12:19, Paul Hankin <[EMAIL PROTECTED]> wrote: > > > > > Recall sorted... > > sorted(iterable, cmp=None, key=None, reverse=False) --> new sorted > > list > > > So why not construct sorteddicts using the same idea of so

Re: sorteddict PEP proposal [started off as orderedict]

On Sep 25, 10:53 am, Mark Summerfield <[EMAIL PROTECTED]> wrote: > Hi, > > Below is a PEP proposal for a sorteddict. It arises out of a > discussion on this list that began a few weeks ago with the subject of > "An ordered dictionary for the Python library?", and a s

Re: sorteddict PEP proposal [started off as orderedict]

Mark Summerfield wrote: > PEP: XXX > Title: Sorted Dictionary [snip] > In addition, the keys() method has two optional arguments: > > keys(firstindex : int = None, secondindex : int = None) -> list of keys > > The parameter names aren't nice, but using say "start" and "end" would >

Re: sorteddict PEP proposal [started off as orderedict]

On 25 Sep, 12:19, Paul Hankin <[EMAIL PROTECTED]> wrote: > Recall sorted... > sorted(iterable, cmp=None, key=None, reverse=False) --> new sorted > list > > So why not construct sorteddicts using the same idea of sortedness? > > sorteddict((mapping | sequence | nothing), cmp=None, key=None, > re

Re: sorteddict PEP proposal [started off as orderedict]

On 25 Sep, 12:11, Jeremy Sanders wrote: > Mark Summerfield wrote: > > If there is positive feedback I will submit the PEP to the reviewers, > > so if you think it is a good idea please say so. (I'm sure that if you > > _don't_ like it you'll tell me anyway:-) > > It would be nice to have the abili

Re: sorteddict PEP proposal [started off as orderedict]

Recall sorted... sorted(iterable, cmp=None, key=None, reverse=False) --> new sorted list So why not construct sorteddicts using the same idea of sortedness? sorteddict((mapping | sequence | nothing), cmp=None, key=None, reverse=None) Then we can specify the exact behaviour of sorteddicts: it

Re: sorteddict PEP proposal [started off as orderedict]

Mark Summerfield wrote: > If there is positive feedback I will submit the PEP to the reviewers, > so if you think it is a good idea please say so. (I'm sure that if you > _don't_ like it you'll tell me anyway:-) It would be nice to have the ability to use numerical indexes and the key, but I don'

Re: sorteddict PEP proposal [started off as orderedict]

Mark Summerfield <[EMAIL PROTECTED]> wrote: > When handling collections of key-value data, it is often > convenient to access the data in key order. One way to do this is > to use an unsorted data structure (e.g., a Python dict), and then > sort the keys as needed. Another way is

Re: sorteddict PEP proposal [started off as orderedict]

On 2007-09-25, Andrew Durdin wrote: > On 9/25/07, Mark Summerfield <[EMAIL PROTECTED]> wrote: > > Since the sorteddict's data is always kept in key order, indexes > > (integer offsets) into the sorteddict make sense. Five additional > > methods are proposed to take advantage of this: >

Re: sorteddict PEP proposal [started off as orderedict]

On 2007-09-25, Andrew Durdin wrote: > On 9/25/07, Mark Summerfield <[EMAIL PROTECTED]> wrote: > > Since the sorteddict's data is always kept in key order, indexes > > (integer offsets) into the sorteddict make sense. Five additional > > methods are proposed to take advantage of this: >

Re: sorteddict PEP proposal [started off as orderedict]

On 25 Sep, 10:53, "A.T.Hofkamp" <[EMAIL PROTECTED]> wrote: > On 2007-09-25, Mark Summerfield <[EMAIL PROTECTED]> wrote: > > > If there is positive feedback I will submit the PEP to the reviewers, > > so if you think it is a good idea please say so. (I'm sure that if you > > _don't_ like it you'll t

Re: sorteddict PEP proposal [started off as orderedict]

On 9/25/07, Mark Summerfield <[EMAIL PROTECTED]> wrote: > > Since the sorteddict's data is always kept in key order, indexes > (integer offsets) into the sorteddict make sense. Five additional > methods are proposed to take advantage of this: > > key(index : int) -> value > > i

Re: sorteddict PEP proposal [started off as orderedict]

On 2007-09-25, Mark Summerfield <[EMAIL PROTECTED]> wrote: > If there is positive feedback I will submit the PEP to the reviewers, > so if you think it is a good idea please say so. (I'm sure that if you > _don't_ like it you'll tell me anyway:-) I like the idea, ie +1. > This PEP proposes th

sorteddict PEP proposal [started off as orderedict]

Hi, Below is a PEP proposal for a sorteddict. It arises out of a discussion on this list that began a few weeks ago with the subject of "An ordered dictionary for the Python library?", and a similar one on the P3K mailing list with the subject "ordered dict for p3k collections?

PEP proposal : Getting rid of the extension version/compiler dependency

It's been observed a couple times recently ... distributing and compiling extensions is a pain, especially on windows, when the main supported compilers are not freely availble .. nor even commercially availble anymore. What we need is a way to break out of this dependency. A way for python ext

Re: Pre-PEP Proposal: Codetags

Also, please update the Post-History header, adding the date(s) you posted the PEP to the mailing lists and/or newsgroups. And this time I'll remember to attach the file :-) -- David Goodger PEP: XXX Title: Codetags Version: $Revision$ Last-Modified: $Date$ Author: Mi

Re: Pre-PEP Proposal: Codetags

Bengt Richter wrote: >>Both elements seem to be missing your document: it does not propose >>changes to the Python language; instead, it proposes a specific >>way of writing comments (ie. something that is not relevant to the >>Python interpreter or libraries, only to the Python developer). > > >

  1   2   >