[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
[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)
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] 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
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
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] @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: 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] 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 wink). 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] 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] 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 wink) 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: [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
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?
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] 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] 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
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 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] 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
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
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
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] 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] @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
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] 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
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
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
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] 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
[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
