[Python-Dev] SWT PyCon Sprint?
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 working... -- Nick ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
> > 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 this means we need a PEP! Or the implementation can have a switch to choose between keep-first logic or replace logic. The latter seems a bit odd to me. The key position would be determined by the first encountered while the value would be determined by the last encountered. Starting with [(10, v1), (20, v2), (10.0, v3)], the ordered dictionary's items would look like [(10, v3), (20, v2)]. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
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 use cases. And as > > long as you don't have too many duplicates, filterdups as above should > > keep memory consumption down better. > > Thinking about this further - memory usage would be almost identical. By > the time you completed the iterable, you would have built up exactly the > same set internally - although probably not as memory efficient since it > would be being built piecemeal. OTOH, an ordered set has a bit of extra > memory for maintaining the order, so it's going to be pretty close. Definitely true that if you iterate through your entire iterable, it doesn't gain you anything over an OrderedSet. OTOH, if you only end up looking at the first N elements of the iterable, then this would be more efficient than putting the entire iterable into an OrderedSet and taking the first N from there. Of course you can put only the first elements into the OrderedSet, but note that you can't just put in the first N; you have to add elements of the iterable into the OrderedSet until it has len(obj) == N. Not that this should be more than a few lines of code, but it's code that you wouldn't have to write with fitlerdups. That said, you're right of course that filterdups is certainly not a big win over OrderedSet. I was really just trying to point out that if we were just trying to provide a solution to the filtering-duplicates-while-maintaining-order problem that OrderedSet wasn't the only path to that goal. I think since then there have been a number of other reasonable cases suggested for wanting an OrderedSet, e.g.: * A DB result set that is indexed by a key but also maintains row order [Eli Stevens, Jeff Bauer] * A config-file data structure that indexes by option names but maintains the order of elements read from a config file [John Williams] * Drop-down field selectors indexed by both name and sequence position [Jeff Bauer] So I'm now probably +0.5 on adding an OrderedSet to collections. Not that my opinion is particularly influential, of course. ;-) Steve -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] @deprecated (was: Useful thread project for 2.5?)
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 deprecated. It will result in a warning being emmitted
> when the function is used."""
> def newFunc(*args, **kwargs):
> warnings.warn("Call to deprecated function.")
> return func(*args, **kwargs)
> return newFunc
>
> = example
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.
In Zope 3's deprecation package, we have decided to put a special deprecation
proxy around the module (instead of the function) and register a list of
attribute names (note that it does not matter whether its a class, function
or other type of object) that are deprecated. The advantage is that you get a
deprecation warning just by looking up the object.
See: http://svn.zope.org/Zope3/trunk/src/zope/deprecation/
Disclaimer: This code is a bit experimental and might not be the best
solution. It is currently used in the trunk and does a pretty good job,
though.
Regards,
Stephan
--
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
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, filterdups as above should > keep memory consumption down better. Thinking about this further - memory usage would be almost identical. By the time you completed the iterable, you would have built up exactly the same set internally - although probably not as memory efficient since it would be being built piecemeal. OTOH, an ordered set has a bit of extra memory for maintaining the order, so it's going to be pretty close. The only thing this gains you (and it's significant) is the ability to work on any iterable lazily. Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
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 familiar to me - it's the type of thing you don't think about until you actually need it. > In both cases, I could get by with other techniques, but I > would use stdlib ordered dicts if they were available. > I also prefer the term "ordered dict" to LinkedHashXXX. You may notice the subject is LinkedHashXXX *equivalents* ;) There is no way I would ever propose adding them with those names. OTOH, "ordered set" and "ordered dict" implies different things to different people - usually "sorted" rather than "the order things were put in". Perhaps "temporally-ordered" ;) BTW, just to clarify the semantics: Set: Items are iterated over in the order that they are added. Adding an item that compares equal to one that is already in the set does not replace the item already in the set, and does not change the iteration order. Removing an item, then re-adding it moves the item to the end of the iteration order. Dict: Keys are iterated over in the order that they are added. Setting a value using a key that compares equal to one already in the dict replaces the value, but not the key, and does not change the iteration order. Removing a key (and value) then re-adding it moves the key to the end of the iteration order. Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
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, 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'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 In both cases, I could get by with other techniques, but I would use stdlib ordered dicts if they were available. I also prefer the term "ordered dict" to LinkedHashXXX. Jeff Bauer Rubicon, Inc. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
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 stdlib, but it's another use case. Each dict key >> contains a dict value; the subkeys from later-added keys are supposed to >> override earlier subkeys. The original implementation relied on subkeys >> being unique, but that doesn't work for our new business requirements.) > > 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 this means we need a PEP! -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
[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 key > contains a dict value; the subkeys from later-added keys are supposed to > override earlier subkeys. The original implementation relied on subkeys > being unique, but that doesn't work for our new business requirements.) 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). Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
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 another use case for you. bust as you say, easy to do > yourself... 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 key contains a dict value; the subkeys from later-added keys are supposed to override earlier subkeys. The original implementation relied on subkeys being unique, but that doesn't work for our new business requirements.) -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] @deprecated (was: Useful thread project for 2.5?)
> 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 should block the @deprecated decorator from being used. I hope that monkey patching is rare enough that you shouldn't mind checking once a year of so if the thing you're monkey-patching might have been deprecated (in which case you shouldn't be monkey-patching it but instead rewrite your code to avoid it altogether). > In Zope 3's deprecation package, we have decided to put a special deprecation > proxy around the module (instead of the function) and register a list of > attribute names (note that it does not matter whether its a class, function > or other type of object) that are deprecated. The advantage is that you get a > deprecation warning just by looking up the object. Yeah, but not everybody has Zope's proxying machinery. I think you're overreacting. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
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 to do yourself... =?ISO-8859-1?Q?"Martin_v._L=F6wis"?= writes: | 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 some order - but that is rarely the order in which | they were added to the dictionary. Most frequently, you want the keys | sorted, according to some criteria. If not that, I would assume that you | typically have the order of keys determined before even filling the | dictionary, in which case you can do | | for k in keys_in_preferred_order: | v = hashtable[k] | process(k,v) | | I remember having needed that once in the past 15 years (in Smalltalk | at the time), so I wrote an OrderedDictionary for Smalltalk/V (which | didn't have it). It took me an hour or so. | | I don't recall what precisely it was that I needed it for, and I cannot | think of any use case for the data type right now. | | So I'm -0 on adding the data type: I have a vague feeling it is needed, | but rarely, and I don't know precisely what for. | | Regards, | Martin | ___ | Python-Dev mailing list | Python-Dev@python.org | http://mail.python.org/mailman/listinfo/python-dev | Unsubscribe: http://mail.python.org/mailman/options/python-dev/tommy%40ilm.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
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 duplicates from a list while retaining order? The primary use case I have deals with DB result sets*. The ordering of the rows returned from a query is important, so keeping the iteration order is nice. Most of the tables I deal with have keys of some kind, and being able to pull out a result row by key is also nice. Granted, I rarely use /both/ at the same time, but it is nice to not have to specify how the result set will be used when I retrieve it. To me, this seems to be the same concept as the config file parsing previously mentioned. I don't feel qualified to have an opinion** about inclusion in the stdlib, much less vote. relurkin'ly yrs, Eli [*] - In my case, it's actually coded in Java, for work. There might be a reason that this problem isn't language-generic, but the 1.5 minutes I spent thinking about it were not illuminating. [**] - Yet I have one anyway. This kind of datatype seems one of those easy-to-get-half-right things that could benefit from a solid implementation. It also doesn't strike me as controversial in terms of API or internal structure. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
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 data
is likely to have come from a file that was arranged in some meaningful
order, and it would be nice to preserve that order, especially if it can
be done with no extra effort.
That is a good example, IMO. But then, in the specific case, the
dictionary for each section is created deeply inside ConfigParser,
with the lines
cursect = {'__name__': sectname}
self._sections[sectname] = cursect
So this uses a builtin dict, and there is no easy way to override it
for the application.
Of course, given your reasoning, ConfigParser *should* use an
OrderedDictionary (probably both for cursect and for self._sections),
in which case this would all be transparent to the application.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: No new features
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 the API such that code for 2.3.x may not work on > 2.2.x, but code that runs on 2.2.x must work on 2.3.x. > > micro releases, ie 2.2.1 ->2.2.2, are for bug fixes only. There can be no > changes to the API, so that all code that runs on 2.2.2 should work with > 2.2.1, barring the bugs fixed. > > The example you cited of adding bool was an extension to the API, and hence > should have been a minor release, not a micro release. > > I just read the PEP-6, and it doesn't seem to use this terminology, or make > this distinction... does something else do this anywhere? I thought this > approach was common knowledge... Functionally speaking, Python has only major releases and micro releases. We don't have the resources to support minor releases. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
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 > duplicates from a list while retaining order? > > Steve Using a LinkedHashMap generally cuts down in the amount of apparent randomness in a program. This is especially helpful when it comes time to debug a really complicated program by diffing log files, since it prevents slightly different maps from having wildly different iteration orders. Often using a plain HashMap can introduce enough randomness to make two otherwise similar log files nearly impossible to compare. 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 data is likely to have come from a file that was arranged in some meaningful order, and it would be nice to preserve that order, especially if it can be done with no extra effort. --jw ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: No new features
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 way change the old API. Any existing code should be un-effected in any > > way by the change. > > > > 2) The new features must be clearly documented as "New in version X.Y.Z". > > This way people using these features will know the minium Python version > > required for their application. > > 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 because of some apple snafus but > it was made even more useless by the fact that people out in the wild > were writing code for 2.2.1 and using True/False/bool. 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. You missed the "minor releases" bit in my post. 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 the API such that code for 2.3.x may not work on 2.2.x, but code that runs on 2.2.x must work on 2.3.x. micro releases, ie 2.2.1 ->2.2.2, are for bug fixes only. There can be no changes to the API, so that all code that runs on 2.2.2 should work with 2.2.1, barring the bugs fixed. The example you cited of adding bool was an extension to the API, and hence should have been a minor release, not a micro release. I just read the PEP-6, and it doesn't seem to use this terminology, or make this distinction... does something else do this anywhere? I thought this approach was common knowledge... Donovan Baardahttp://minkirri.apana.org.au/~abo/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
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 as the code I'm trying to test. I see. I would argue that you were better off if the test cases were sorted (according to some total, stable-across-releases, order), rather than being ordered. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
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 some order - but that is rarely the order in which they were added to the dictionary. Most frequently, you want the keys sorted, according to some criteria. If not that, I would assume that you typically have the order of keys determined before even filling the dictionary, in which case you can do for k in keys_in_preferred_order: v = hashtable[k] process(k,v) I remember having needed that once in the past 15 years (in Smalltalk at the time), so I wrote an OrderedDictionary for Smalltalk/V (which didn't have it). It took me an hour or so. I don't recall what precisely it was that I needed it for, and I cannot think of any use case for the data type right now. So I'm -0 on adding the data type: I have a vague feeling it is needed, but rarely, and I don't know precisely what for. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
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 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 as the code I'm trying to test. James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
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, 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. Sorry, I didn't mean to come across as suggesting that there weren't other use cases for it. I'm only asking for people who know these other use cases to present them here. At the moment, we have only one use case, and for that use case, OrderedDict/OrderedSet isn't really the best solution. (That's all my code was intended to point out -- I don't really care if it makes it into itertools or not.) If people could present a few reasonable problems where OrderedDict/OrderedSet really do provide the best solutions, and then make the case that these use cases are reasonably frequent, I think there would be much better support for adding such types to the standard library. Steve -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
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 useful data type, isn't it? > > 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. Hm, removing duplicates from a list is an algorithm, not a data structure. And the code you posted (no offense intended) is, also imo, faster written by an experienced programmer than located in some module. OTOH, I see no problem adding it to itertools. > 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, 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] @deprecated (was: Useful thread project for 2.5?)
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 lost. That's the idiom for decorators. They will almost always be wrappers for other functions by returning a new function that uses closures to access the original. Besides, you no longer have the original function directly available in the global namespace of the module since the name of the decorated function gets rebound before you have a chance to see the original function. So there really is no issue with the function not being the exact same since you can't really see it undecorated without a lot of effort; no real change of the object that the user can ever tell. And as for monkey-patching breaking something, that's there fault for monkey-patching. Python doesn't prevent you from doing something stupid which why it is the language four out of five adults choose to code in (the fifth one, the hold-out, just can't let go of Java because he/she is a recent college grad and it is all they have ever known; they also think that EAFP is "evil" =). -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
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 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 duplicates from a list while retaining order? Steve -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
[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" <[EMAIL PROTECTED]> writes: > -0 for the addition to the collections module, -1 on the specific > name. 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? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rationale for the no-new-features approach
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 OverflowError... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
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. From the outside, it is primarily a Dictionary; only when you look closer you see that this specific dictionary requires hashable keys (as opposed to, say, the C++ std::map, which requires sortable keys). So consequently, the data type should be called OrderedDictionary, and its cookbook recipe is http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/107747 Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode inconsistency?
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 version). Maybe we should also expose the C API as suggested in the patch, e.g. as text(obj). Perhaps the right thing to do is introduce a new format code that means insert text(obj) instead of str(obj), e.g %t. If we do that though then we should make "'%s' % u'xyz'" return a string instead of a unicode object. I suspect that would break a lot of code. It would result in lots of UnicodeErrors due to failing conversion of the Unicode string to a string. Plus it would break with the general rule of always coercing to Unicode (see below) and lose us the ability to write polymorphic code. OTOH, having %s mean text(obj) instead of str(obj) may work just fine. People who want it to mean str() generally don't have any unicode strings floating around so text() has the same effect. People who are using unicode probably would find text() to be more useful behavior. I think that's why someone hacked PyString_Format to sometimes return unicode strings. That wasn't a hack: it's part of the Unicode integration logic which always coerces to Unicode if strings and Unicode meet. In the above case a string format string meets a Unicode object as argument which then results in a Unicode object to be returned. Regarding the use of __str__, to return a unicode object: we could introduce a new slot (e.g. __text__) instead. However, I can't see any advantage to that. If someone really wants a str object then they call str() or PyObject_Str(). Right. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 09 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rationale for the no-new-features approach
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 (re)reading this at some point and it > helped me clarify some ideas floating around in my head. > > http://www.internalmemos.com/memos/memodetails.php?memo_id=1321 Thanks for posting that, it was interesting. Cheers, mwh -- NUTRIMAT: That drink was individually tailored to meet your personal requirements for nutrition and pleasure. ARTHUR: Ah. So I'm a masochist on a diet am I? -- The Hitch-Hikers Guide to the Galaxy, Episode 9 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] scrambling python in a microsoft .exe container
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 for, but it's pretty clear that python-dev is the wrong place to ask. Please switch to comp.lang.python. Thanks. (python-dev should only be used for people working on Python releases.) -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib/idlelib NEWS.txt, 1.49.2.3, 1.49.2.4 idlever.py, 1.22.2.1, 1.22.2.2
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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.access and Unicode
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, either. If there are ACLs on the file, access will consider them (or atleast it should), but no other method will. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode inconsistency?
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 we should also expose the C API as suggested in the patch, > e.g. as text(obj). Perhaps the right thing to do is introduce a new format code that means insert text(obj) instead of str(obj), e.g %t. If we do that though then we should make "'%s' % u'xyz'" return a string instead of a unicode object. I suspect that would break a lot of code. OTOH, having %s mean text(obj) instead of str(obj) may work just fine. People who want it to mean str() generally don't have any unicode strings floating around so text() has the same effect. People who are using unicode probably would find text() to be more useful behavior. I think that's why someone hacked PyString_Format to sometimes return unicode strings. Regarding the use of __str__, to return a unicode object: we could introduce a new slot (e.g. __text__) instead. However, I can't see any advantage to that. If someone really wants a str object then they call str() or PyObject_Str(). Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: No new features
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 release should be compatible with every other, except for bugs and fixes to those bugs. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib/idlelib NEWS.txt, 1.49.2.3, 1.49.2.4 idlever.py, 1.22.2.1, 1.22.2.2
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. I must've updated it to 1.1.1 sometime after the 2.4 release (I vaguely recall doing this). -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: [Python-checkins] python/dist/src/Lib/idlelib NEWS.txt, 1.49.2.3, 1.49.2.4 idlever.py, 1.22.2.1, 1.22.2.2
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 > -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. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rationale for the no-new-features approach
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 clarify some ideas floating around in my head. http://www.internalmemos.com/memos/memodetails.php?memo_id=1321 On Thursday 10 March 2005 03:01, Guido van Rossum wrote: > For those who only remember bool(), Python 1.5.2 was probably the > worst offender here (it had nothing to do with 1.5.1). Mea culpa > etcetera. That was a heck of a long time ago, and Python was a heck of a lot younger then. Hell, I can still remember the interpreter-prints-all-return-values-to-stdout being turned off sometime during the 0.9.x series (best minor-release-change ever!). And while the True/False issue was a complete pain, it at least serves as a good example (in the http://www.despair.com/demotivators/mis24x30prin.html sense of the word ) Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rationale for the no-new-features approach
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 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 remember the >days when major features in 3rd-dot releases caused major headaches for us. For those who only remember bool(), Python 1.5.2 was probably the worst offender here (it had nothing to do with 1.5.1). Mea culpa etcetera. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] scrambling python in a microsoft .exe container
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rationale for the no-new-features approach
+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 remember the days when major features in 3rd-dot releases caused major headaches for us. I think that made Python look bad. Jim 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. Goal 1: When we cut a bugfix release, people will upgrade to it. - This helps the users (they have bugs fixed) - This helps us (python-dev) because people won't be logging bugs against already-fixed-bugs. - This makes us (Python) look good, because people using Python have the most bug-free experience possible. Goal 2: Packagers of Python will package up releases of Python that are as close to the "official" release as possible. - This, to me, is a huge win. If we don't have to worry about whether someone is running 2.4.1, or DistroFoo's version of 2.4.1 with a couple of backported fixes from 2.4.2, or some other horrible frankenstein's monster of a release, it makes our lives much easier. (This is also why I've been on a bit of a stomping exercise to attempt to get distros that broke Python into pieces to stop doing this (notably, Debian/Ubuntu's distutils- in-python-devel pain)) - And yes, we're always going to have the problem of some distros stuck on old Python releases (Redhat -> Python 1.5.2, Debian stable -> Python 2.1, &c) but we can hopefully encourage them to at least roll out the latest bugfix version of whatever version they're stuck on. Goal 3: Good PR. - I've read a disturbing amount of words about other languages (*cough*Java*cough*) that have no sanity about minor and major releases. This seems to piss people off a great deal. One of Python's selling points is that we're very cautious and a suitable choice for grownups to use in business. - This is good for us (Python community) because it makes it less likely we'll be stuck in a job where we're forced to code Perl, or C++, or Java, or some other horrible fate. It also boosts the size of the community, meaning that there will be more volunteers to work on Python (hurrah!) Goal 4: Try and prevent something like try: True, False except NameError: True, False = 1, 0 from ever ever happening again. - This, I hope, needs no further explanation Anthony -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rationale for the no-new-features approach
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 Anthony (I was going to use a different phrase using some words from your original message, but then I thought better of that. :). I think we learned our lesson from the 2.2 True/False fiasco. It's a natural instinct to want to get those new features in earlier than the minor release lifecycle, but resisting that temptation demonstrates our maturity as a community, IMO. Having to wait for those new features in the mainline Python releases is the cost of our "batteries included" approach. If the users of a package want a shorter lifecycle, then the package maintainer will just have to make independent releases, sync'ing up with Python development in the latter's trunk. I've had to do this occasionally with the email package, for example. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: No new features
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 with Python > 2.2.0: this was pretty broken anyway because of some apple snafus but > it was made even more useless by the fact that people out in the wild > were writing code for 2.2.1 and using True/False/bool. 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. This is exactly right, and, assuming people are in agreement, I plan to add text to this effect to PEP 6. One of the slightly negative side effects of Python's growth is that a lot of people depend on it now, and I feel it's in everyone's interests to try and make the best releases I can. We now do more regular bugfix releases - once every 6 months is the goal. Ideally, people shouldn't be _forced_ to upgrade (although obviously I'd prefer if they did ). Assuming that none of the bugs fixed are actually biting you, you should be able to stick with that version of 2.4.0 that's rolled out across hundreds of machines, and not have to worry that someone's writing code against some 2.4.2-specific features. Or, to put it more concisely -- if we allow new features (however minor) in bugfix releases, we're effectively shipping a "new" Python release every 6 months. This is insane. I want to have my cake and eat it too - I want the bugs fixed, but I don't want to have to mess about with worrying about new features each time I need to roll out a new release (in my job). [Disclaimer: It should be obvious here that I'm speaking for myself, and in doing so, I'm wearing a number of different hats - while I'm currently the guy who does the cvs-tag-and-release, I'm also an author of a whole pile of Python software, some open source, some closed (for work). In addition, I need to think about deployment and rollout strategies for new code and new systems in my job. I'm trying to optimise the release process to suit all these hats, and at the same time thinking about what I've been told by other people (distro vendors, people running _very_ large sets of machines with Python software)] In an attempt to stir up some discussion - if you have a reason _for_ allowing new features in a minor release, suggest it! I'm genuinely interested in having this discussion and working out the best solution... Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: No new features
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 because of some apple snafus but > it was made even more useless by the fact that people out in the wild > were writing code for 2.2.1 and using True/False/bool. 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. Yes, exactly. That's why I wrote PEP 6 in the first place, and experience has only led to tightening things up further. The specific example of 2.2.1 and bool is even worse than you're noting, because 2.3's bool works a bit differently, so you have to actually code for three different problems in two major versions. Sehr schlecht. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] @deprecated (was: Useful thread project for 2.5?)
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 deprecated. It will result in a warning being emmitted
> when the function is used."""
> def newFunc(*args, **kwargs):
> warnings.warn("Call to deprecated function.")
> return func(*args, **kwargs)
> return newFunc
>
> = example =
> ...
> UserWarning: Call to deprecated function.
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.
In Zope 3's deprecation package, we have decided to put a special deprecation
proxy around the module (instead of the function) and register a list of
attribute names (note that it does not matter whether its a class, function
or other type of object) that are deprecated. The advantage is that you get a
deprecation warning just by looking up the object.
See: http://svn.zope.org/Zope3/trunk/src/zope/deprecation/
Disclaimer: This code is a bit experimental and might not be the best
solution. It is currently used in the trunk and does a pretty good job,
though.
Regards,
Stephan
--
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Re: @deprecated
[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 a decorator-maker-decorator (see "Creating Well-Behaved Decorators" in http://www.python.org/moin/PythonDecoratorLibrary), and I still think it's probably a wise approach since it's easy for people to be careless and forget to preserve these sorts of features. Jim Jewett writes: > I agree that it should go in the cookbook, but I think you should > set the category to a DeprecationWarning and give the offending > function's name. I had wondered about that, but wasn't familiar with how people actually use categories. DeprecationWarning certainly sounds right, or is there some reason why I should use a custom subclass of DeprecationWarning? Michael Hudson and Irmen point out: > 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... True enough. And java doesn't complain at all if the deprecated function is invoked via reflection. It's a fundamental difference in style between the two languages: Python barely even HAS a "compile phase", and Python programs tend to be far more dynamic than Java. -- Michael Chermside ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: @deprecated
"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 > during the *compilation phase* (when used with the -deprecation option). > During runtime, no warnings are produced. Yeah, that's what I meant to say, even if it wasn't what I said :) Cheers, mwh -- LINTILLA: You could take some evening classes. ARTHUR: What, here? LINTILLA: Yes, I've got a bottle of them. Little pink ones. -- The Hitch-Hikers Guide to the Galaxy, Episode 12 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: No new features
"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 in any > way by the change. > > 2) The new features must be clearly documented as "New in version X.Y.Z". > This way people using these features will know the minium Python version > required for their application. 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 because of some apple snafus but it was made even more useless by the fact that people out in the wild were writing code for 2.2.1 and using True/False/bool. 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. My 2p. Cheers, mwh -- Well, you pretty much need Microsoft stuff to get misbehaviours bad enough to actually tear the time-space continuum. Luckily for you, MS Internet Explorer is available for Solaris. -- Calle Dybedahl, alt.sysadmin.recovery ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: @deprecated
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 with the -deprecation option). During runtime, no warnings are produced. Grtz, Irmen. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: No new features (was Re: [Python-Dev] Re: [Python-checkins]python/dist/src/Modules ossaudiodev.c, 1.35, 1.36)
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. [...] > Initially, I was inclined to be much less anal about the no-new-features > thing. But since doing it, I've had a quite large number of people tell me how > much they appreciate this approach - vendors, large companies with huge > installed bases of Python, and also from people releasing software written > in Python. Very few people offer the counter argument as a general case - > with the obvious exception that everyone has their "just this one little > backported feature, plase!" (I'm the same - there's been times where > I've had new features I'd have loved to see in a bugfix release, just so I > could use them sooner). 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 in any way by the change. 2) The new features must be clearly documented as "New in version X.Y.Z". This way people using these features will know the minium Python version required for their application. Any change that breaks rule 1) must be delayed until a major release. Any change that breaks rule 2) is a documentation bug that needs fixing. Donovan Baardahttp://minkirri.apana.org.au/~abo/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] rationale for the no-new-features approach
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 users (they have bugs fixed) - This helps us (python-dev) because people won't be logging bugs against already-fixed-bugs. - This makes us (Python) look good, because people using Python have the most bug-free experience possible. Goal 2: Packagers of Python will package up releases of Python that are as close to the "official" release as possible. - This, to me, is a huge win. If we don't have to worry about whether someone is running 2.4.1, or DistroFoo's version of 2.4.1 with a couple of backported fixes from 2.4.2, or some other horrible frankenstein's monster of a release, it makes our lives much easier. (This is also why I've been on a bit of a stomping exercise to attempt to get distros that broke Python into pieces to stop doing this (notably, Debian/Ubuntu's distutils- in-python-devel pain)) - And yes, we're always going to have the problem of some distros stuck on old Python releases (Redhat -> Python 1.5.2, Debian stable -> Python 2.1, &c) but we can hopefully encourage them to at least roll out the latest bugfix version of whatever version they're stuck on. Goal 3: Good PR. - I've read a disturbing amount of words about other languages (*cough*Java*cough*) that have no sanity about minor and major releases. This seems to piss people off a great deal. One of Python's selling points is that we're very cautious and a suitable choice for grownups to use in business. - This is good for us (Python community) because it makes it less likely we'll be stuck in a job where we're forced to code Perl, or C++, or Java, or some other horrible fate. It also boosts the size of the community, meaning that there will be more volunteers to work on Python (hurrah!) Goal 4: Try and prevent something like try: True, False except NameError: True, False = 1, 0 from ever ever happening again. - This, I hope, needs no further explanation Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] BRANCH FREEZE for 2.4.1rc1, 0000 UTC, 2005-03-10
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 _extraordinarily_ conservative with checkins to the release24-maint branch until 2.4.1 final is out. If in doubt, feel free to email me, or contact on any one of AIM: anthonyatekit, jabber: [EMAIL PROTECTED], or IRC: #python-dev on Freenode. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: No new features (was Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Modules ossaudiodev.c, 1.35, 1.36)
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 to sync with Optik > 1.5.1? I'm a bit embarassed that Python 2.4's optparse has __version__ > == "1.5a2" because I didn't release Optik 1.5 in time. The version string update I don't see being a problem. > And yes, there were some tiny new features in 1.5 and a few more coming > in 1.5.1: > > * SF patch #870807: allow users to specify integer option arguments > in hexadecimal, octal, or binary with leading "0x", "0", or "0b" > (1.5 final). Again, this is a new feature, and having it behave differently in 2.4.1 to 2.4 could be confusing - but I'm not absolutely against this. > * SF feature #1050184: add 'append_const' action (patch by > Andrea 'fwyzard' Bocci) (1.5 final). New feature? > * Keep going if importing gettext fails (so optparse can be used > in the Python build process) (1.5 final). Bug fix. > * Fix so the 'merge' script works again (bugs spotted, and mostly > fixed, by Andrea 'fwyzard' Bocci). (1.5.1) Bug fix. > * SF bug #1145594: add 'finish()' method to OptionParser so > applications can explicitly break reference cycles, making life > easier for Python's garbage collector. (1.5.1) Is this purely an internal method, or something that people would use as part of the API? If it's an API change, it shouldn't be included. > * SF feature #988126: add 'epilog' attribute to OptionParser > (and constructor arg): paragraph of text to print after the > main option help. (1.5.1) API change. > * Corrected French translation (po/optik/fr.po) (Laurent Laporte). > (1.5.1) Bug fix. > Every one of these is useful to someone, and none of them are even > remotely destabilizing. But they all add functionality that would be > present in 2.4.1 and not in 2.4. That doesn't bother me in the > slightest, but I guess it bothers some people. Initially, I was inclined to be much less anal about the no-new-features thing. But since doing it, I've had a quite large number of people tell me how much they appreciate this approach - vendors, large companies with huge installed bases of Python, and also from people releasing software written in Python. Very few people offer the counter argument as a general case - with the obvious exception that everyone has their "just this one little backported feature, plase!" (I'm the same - there's been times where I've had new features I'd have loved to see in a bugfix release, just so I could use them sooner). > I'd like to check this in for 2.4.1. But I won't if anyone says "don't > do it". Nor will I if no one else says "do it". Well, 2.4.1rc1 is out in about 12 hours time. If you want to check in the bugfixes before then, please feel free. If you don't want to apply bits and pieces, then don't worry about it. I don't want anything but critical fixes landing between 2.4.1rc1 and 2.4.1 final. Remember that 2.4.2 will turn up inevitably, it's not like this is the last release between now and 2.5... I should also add that the above is really just policy as it's evolved - if people want to discuss this (am I being too strict?) I'm happy to talk about it. I'd even suggest a BOF at PyCon, except I won't be there :-( -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode inconsistency?
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 short of saying "OK, we don't give
a rip anymore about what type of objects PyObject_{Str,Repr} return",
It's about 10 lines of code. See http://python.org/sf/1159501 .
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 we should also expose the C API as suggested in the patch,
e.g. as text(obj).
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Mar 09 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: @deprecated
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" DO in >> Java? Why it causes the compiler to emit a warning if you use the function in >> question. Not a bad idea. > > Isn't it, though? > >> Amusingly enough, the syntax is even the same in >> Python: > [...code omitted...] > > Cl. So simple, and yet so powerful. One might even call it Pythonic! 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... Cheers, mwh -- ROOSTA: Ever since you arrived on this planet last night you've been going round telling people that you're Zaphod Beeblebrox, but that they're not to tell anyone else. -- The Hitch-Hikers Guide to the Galaxy, Episode 7 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
