I realize that this is exceedingly late in the game, but is anybody
interested in doing a Write-Python-Bindings-for-SWT sprint? It's been
brought up before in various places, and PyCon seems the likely place
to get enough concentrated knowledge to actually get it kicked off and
somewhat workin
> > If I read the proposal correctly, order would be determined by when
the
> > key was first encountered. Presumably, that would mean that the
related
> > value would also be the first encountered (not overridden by
later-added
> > keys as dictated by your business requirements).
>
> Hm
Delaney, Timothy C (Timothy) <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
>
> > def filterdups(iterable):
> > seen = set()
> > for item in iterable:
> > if item not in seen:
> > seen.add(item)
> > yield item
> >
> > Adding this to, say, itertools
On Tuesday 08 March 2005 18:05, Jim Jewett wrote:
> ... compiler recognition of "@deprecated" in doc comments.
>
> Michael Chermside suggested:
>
> = code =
> import warnings
>
> def deprecated(func):
> """This is a decorator which can be used to mark functions
>
Steven Bethard wrote:
> def filterdups(iterable):
> seen = set()
> for item in iterable:
> if item not in seen:
> seen.add(item)
> yield item
>
> Adding this to, say, itertools would cover all my use cases. And as
> long as you don't have too many dup
Jeff Bauer wrote:
> I'm not specifically lobbying for its inclusion in
> stdlib, but I often find an ordered dict useful when I
> want both ordered and random access, e.g. situations:
>
>- database table fields/attributes
>- drop down field selectors
Yep - these are also cases that are f
Thomas Heller <[EMAIL PROTECTED]> wrote:
> Steven Bethard <[EMAIL PROTECTED]> writes:
>
>> What use do you have for it other than filtering
>> duplicates from a list while retaining order?
>
> If this were the only use case, you are right. I cannot
> remember the use case I once had right now, a
On Wed, Mar 09, 2005, Raymond Hettinger wrote:
> [Aahz]
>>
>> Gee, I just found out I could have used an OrderedDict today. (We're
>> using a dict that we're now having to add an auxilliary list to to track
>> when keys are added.) (This isn't particularly an argument in favor of
>> adding Ordere
[Aahz]
> Gee, I just found out I could have used an OrderedDict today. (We're
> using a dict that we're now having to add an auxilliary list to to
track
> when keys are added.) (This isn't particularly an argument in favor
of
> adding OrderedDict to stdlib, but it's another use case. Each dict
k
On Wed, Mar 09, 2005, Tommy Burnette wrote:
>
> I'd say I'm +0. fwiw- I've been using a locally-rolled OrderedDict
> implementation for the last 5-6 years in which insertion order is the
> only order respected. I use it all over the place (in a code base of
> ~60k lines of python code).
>
> so t
> This is a recipe for disaster. Creating a new function from the old can have
> unwanted side effects, since you effectively change the object. For example,
> if someone is monkey patching this function, then the deprecation warning
> gets lost.
That's a rather extreme use case, and not one that
I'd say I'm +0. fwiw- I've been using a locally-rolled OrderedDict
implementation for the last 5-6 years in which insertion order is the
only order respected. I use it all over the place (in a code base of
~60k lines of python code).
so there's another use case for you. bust as you say, easy t
Steven Bethard wrote:
Thomas Heller <[EMAIL PROTECTED]> wrote:
[About an ordered dictionary]
Well, that was basically the question I posed. So far I've seen only
one use for it, and that one is better served by adding a function to
itertools. What use do you have for it other than filtering
dupli
John Williams wrote:
The other use case I have is for dealing with data where the iteration
order doesn't matter to the program but it does matter to users. For
instance, consider the ConfigParser's write method. Any ordering of
values in the output is functionally equivalent, but the original
On Thu, Mar 10, 2005, Donovan Baarda wrote:
>
> major releases, ie 2.x -> 3.0, are for things that can break existing code.
> They change the API so that things that run on 2.x may not work with 3.x.
>
> minor releases, ie 2.2.x ->2.3.0, are for things that cannot break existing
> code. They can e
Steven Bethard wrote:
> Thomas Heller <[EMAIL PROTECTED]> wrote:
>
>> [About an ordered dictionary]
>
>
> Well, that was basically the question I posed. So far I've seen only
> one use for it, and that one is better served by adding a function to
> itertools. What use do you have for it other tha
G'day again,
From: "Michael Hudson" <[EMAIL PROTECTED]>
> "Donovan Baarda" <[EMAIL PROTECTED]> writes:
>
> >
> > Just my 2c;
> >
> > I don't mind new features in minor releases, provided they meet the
> > following two criteria;
> >
> > 1) Don't break the old API! The new features must be pure ext
James Y Knight wrote:
I use ordered dictionaries for testing. With an ordered dict I can
string compare the output of my program to what is expected. Without an
ordered dict, I'd have to re-parse the output and order it, which would
require some complicated code that's just as likely to be wrong
Thomas Heller wrote:
I cannot understand why people are against adding it to stdlib (after
the name, the implementation, and the exact place have been decided).
It's certainly a useful data type, isn't it?
It depends on the precise semantics. You often want a dictionary where
the keys come out in s
On Mar 9, 2005, at 4:19 PM, Thomas Heller wrote:
If this were the only use case, you are right. I cannot remember the
use case I once had right now, and probably the code has been rewritten
anyway. But I assume use cases exist, otherwise there weren't so many
recipes for the ordered dictionary.
I
Thomas Heller <[EMAIL PROTECTED]> wrote:
> Steven Bethard <[EMAIL PROTECTED]> writes:
>
> > What use do you have for it other than filtering
> > duplicates from a list while retaining order?
>
> If this were the only use case, you are right. I cannot remember the
> use case I once had right now
Steven Bethard <[EMAIL PROTECTED]> writes:
> Thomas Heller <[EMAIL PROTECTED]> wrote:
>> [About an ordered dictionary]
> [snip]
>> I cannot understand why people are against adding it to stdlib (after
>> the name, the implementation, and the exact place have been decided).
>> It's certainly a use
Stephan Richter wrote:
[SNIP - Michael's deprecated decorator]
This is a recipe for disaster. Creating a new function from the old can have
unwanted side effects, since you effectively change the object. For example,
if someone is monkey patching this function, then the deprecation warning
gets
Thomas Heller <[EMAIL PROTECTED]> wrote:
> [About an ordered dictionary]
[snip]
> I cannot understand why people are against adding it to stdlib (after
> the name, the implementation, and the exact place have been decided).
> It's certainly a useful data type, isn't it?
Well, that was basically t
[About an ordered dictionary]
> Delaney, Timothy C (Timothy) wrote:
>> Does anyone else think it would be worthwhile adding these to
>> collections, or should I just make a cookbook entry?
Greg Ward <[EMAIL PROTECTED]> writes:
> +1 on a cookbook entry. +0 on adding to stdlib.
"Martin v. Löwis"
Guido van Rossum wrote:
On Wed, 09 Mar 2005 10:38:12 -0500, Jim Fulton <[EMAIL PROTECTED]> wrote:
+1 (wish * could say +sys.maxint).
Anthony gets my +1 too, which then adds up to sys.maxint. :-)
+1!
I hope this mailing list runs on python2.2+, or the discussion has to
stop now due to OverflowErro
Delaney, Timothy C (Timothy) wrote:
Does anyone else think it would be worthwhile adding these to
collections, or should I just make a cookbook entry?
-0 for the addition to the collections module, -1 on the specific
name.
Java made a *big* mistake by putting "Hash" into the names of these
things.
Neil Schemenauer wrote:
On Wed, Mar 09, 2005 at 11:10:59AM +0100, M.-A. Lemburg wrote:
The patch implements the PyObjbect_Text() idea (an API that
returns a basestring instance, ie. string or unicode) and
then uses this in '%s' (the string version) to properly propogate
to u'%s' (the unicode versio
Anthony Baxter <[EMAIL PROTECTED]> writes:
> My google-fu returned, and I found the piece I was looking for earlier.
> This discusses (from an internal Sun perspective) some of the problems
> with Java. They make quite a big deal about the problem of changing
> code across minor releases. I recall
On Wed, Mar 09, 2005, Niklas Fischer wrote:
>
> i lost the fight against google to find a wrapper/scrambler for python -
> boxed in an exe file.
> even the mandatory '-monty' string didn t help to find any tools.
>
> anyone got experience with such a tool?
It's not clear what you're looking f
On Wednesday 09 March 2005 12:06, Anthony Baxter wrote:
> No - Py2.4 shipped with idle 1.1. I must've updated it to 1.1.1 sometime
> after the 2.4 release (I vaguely recall doing this).
Ah, ok. I guess I should have looked.
-Fred
--
Fred L. Drake, Jr.
___
Brett C. wrote:
If there was no other way to get os.access-like functionality, I would
say it should be backported. But since there are other ways to figure
out everything that os.access can tell you
I believe this is not really true, atleast not on Windows, and perhaps
not in certain NFS cases,
On Wed, Mar 09, 2005 at 11:10:59AM +0100, M.-A. Lemburg wrote:
> The patch implements the PyObjbect_Text() idea (an API that
> returns a basestring instance, ie. string or unicode) and
> then uses this in '%s' (the string version) to properly propogate
> to u'%s' (the unicode version).
>
> Maybe w
Hear, hear!
> Going from
> 2.x.y to 2.x.y+1 shouldn't break anything, going from 2.x.y+1 to 2.x.y
> shouldn't break anything that doesn't whack into a bug in 2.x.y -- and
> "not having bool" isn't a bug in this sense.
Micro releases are all about bug fixes. Every micro release of the
same minor
On Thursday 10 March 2005 03:48, Fred L. Drake, Jr. wrote:
> > RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/idlever.py,v
> > -IDLE_VERSION = "1.1.1"
> > +IDLE_VERSION = "1.1.1c1"
>
> Shouldn't this progress from 1.1.1 to 1.1.2c1? Otherwise it's moving
> backward.
No - Py2.4 shipped wi
On Wednesday 09 March 2005 06:54, [EMAIL PROTECTED] wrote:
> RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/NEWS.txt,v
...
> -What's New in IDLE 1.1.1?
> -===
> +What's New in IDLE 1.1.1c1?
...
> RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/idlever.py,v
> -
My google-fu returned, and I found the piece I was looking for earlier.
This discusses (from an internal Sun perspective) some of the problems
with Java. They make quite a big deal about the problem of changing
code across minor releases. I recall (re)reading this at some point and it
helped me cla
On Wed, 09 Mar 2005 10:38:12 -0500, Jim Fulton <[EMAIL PROTECTED]> wrote:
> +1 (wish * could say +sys.maxint).
Anthony gets my +1 too, which then adds up to sys.maxint. :-)
> To emphasize:
>
> - We want people to update to bug fix releases quickly. For people
>to do that, they need to know t
hi all!
i lost the fight against google to find a wrapper/scrambler for python -
boxed in an exe file.
even the mandatory '-monty' string didn t help to find any tools.
anyone got experience with such a tool?
thanks for any hint.
greets, Nik
___
+1 (wish * could say +sys.maxint).
To emphasize:
- We want people to update to bug fix releases quickly. For people
to do that, they need to know the risk of breakage is low. Reducing the
scope of the release is important for that.
- Python has gotten much better at this than it used to be. I
On Wed, 2005-03-09 at 07:17, Anthony Baxter wrote:
> So it's only fair that I write down my rationale for why I'm being anal
> about the no-new-features approach. Comments are more than welcome -
> ideally, after discussion, I'll put some more words in the bugfix PEP.
I applaud your strictness Ant
On Wednesday 09 March 2005 23:53, Michael Hudson wrote:
> No no no! The point of what Anthony is saying, as I read it,
Your reading of my message is correct.
> is that
> experience suggests it is exactly this sort of change that should be
> avoided. Consider the case of Mac OS X 10.2 which c
On Wed, Mar 09, 2005, Michael Hudson wrote:
>
> No no no! The point of what Anthony is saying, as I read it, is that
> experience suggests it is exactly this sort of change that should be
> avoided. Consider the case of Mac OS X 10.2 which came with Python
> 2.2.0: this was pretty broken anyway b
On Tuesday 08 March 2005 18:05, Jim Jewett wrote:
> ... compiler recognition of "@deprecated" in doc comments.
>
> Michael Chermside suggested:
>
> = code =
> import warnings
>
> def deprecated(func):
> """This is a decorator which can be used to mark functions
>
[I followed Greg's suggestion and proposed a "deprecated" decorator.]
Raymond writes:
> Decorators like this should preserve information about the underlying
> function
Of course! The version I posted was intended to illustrate the idea, not
to be a clean implementation. A long time ago, I propos
"Irmen de Jong" <[EMAIL PROTECTED]> writes:
> mwh wrote:
>
>
>> One difference: I imagine (hope!) the java compiler would complain if
>> the deprecated function is referenced, whereas the python version only
>> complains if it is called...
>
> The java compiler actually already produces deprecatio
"Donovan Baarda" <[EMAIL PROTECTED]> writes:
>
> Just my 2c;
>
> I don't mind new features in minor releases, provided they meet the
> following two criteria;
>
> 1) Don't break the old API! The new features must be pure extensions that in
> no way change the old API. Any existing code should be u
mwh wrote:
> One difference: I imagine (hope!) the java compiler would complain if
> the deprecated function is referenced, whereas the python version only
> complains if it is called...
The java compiler actually already produces deprecation warnings
during the *compilation phase* (when used wi
G'day,
From: "Anthony Baxter" <[EMAIL PROTECTED]>
> On Wednesday 09 March 2005 12:21, Greg Ward wrote:
> > On 09 March 2005, Anthony Baxter said (privately):
> > > Thanks! I really want to keep the no-new-features thing going for
> > > as long as possible, pending any AoG (Acts of Guido), of cours
So it's only fair that I write down my rationale for why I'm being anal
about the no-new-features approach. Comments are more than welcome -
ideally, after discussion, I'll put some more words in the bugfix PEP.
Goal 1: When we cut a bugfix release, people will upgrade to it.
- This helps the us
So we're cutting 2.4.1c1 in about 12 hours time. Please leave the branch alone
from UTC (that's 8pm US Eastern, unless my timezones are all screwed
up). Once the release candidate is done, we'll have a week to shake out any
embarrassing bugs, and then a 2.4.1 final. Please be _extraordinari
On Wednesday 09 March 2005 12:21, Greg Ward wrote:
> On 09 March 2005, Anthony Baxter said (privately):
> > Thanks! I really want to keep the no-new-features thing going for
> > as long as possible, pending any AoG (Acts of Guido), of course.
>
> Grumble. How do you feel about upgrading optparse t
Neil Schemenauer wrote:
On Sat, Apr 04, 1998 at 07:04:02AM +, Tim Peters wrote:
[Martin v. L?wis]
I can't see any harm by supporting this operation also if __str__ returns
a Unicode object.
It doesn't sound like a good idea to me, at least in part because it
would be darned messy to implement s
Greg Ward <[EMAIL PROTECTED]> writes:
> On 08 March 2005, Michael Chermside said:
>> Greg writes:
>> > This is one of my top two Java features [1].
>> ...
>> > [1] The other is compiler recognition of "@deprecated" in doc comments.
>>
>> Hmm... what a good idea! Let's see... what exactl
54 matches
Mail list logo
