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 exactly does @deprecated
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
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 course.
[...]
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 un-effected
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 deprecation warnings
[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 proposed
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
as
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
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 came
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
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
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 with idle 1.1.
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
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
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.
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 the
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.
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
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 extensions
that in
no
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
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 extend
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
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
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 IMO
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 there's
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 OrderedDict to
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
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 duplicates,
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 would cover all my
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 Guess
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
31 matches
Mail list logo
