Re: [Python-Dev] Python 3.0.1
Aahz pythoncraft.com> writes: > > There's absolutely no reason not to have a 3.0.2 before 3.1 comes out. > You're probably right that what Raymond wants to is best not done for > 3.0.1 -- but once we've agreed in principle that 3.0.x isn't a true > production release of Python for PEP6 purposes, we can do "release early, > release often". It's a possibility. To be honest, I didn't envision us releasing a 3.0.2 rather than focusing on 3.1 (which, as others said, can be released in a few months if we keep the amount of changes under control). But then it's only a matter of naming. We can continue the 3.0.x series and incorporate in them whatever was initially planned for 3.1 (including the IO-in-C branch, the dbm.sqlite module, etc.), and release 3.1 only when the whole thing is "good enough". Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
Eric Smith wrote: Terry Reedy wrote: Ron Adam wrote: Steven D'Aprano wrote: Michael Foord wrote: Don't we have a pretty-print API - and isn't it spelled __str__ ? Not really. If it were as simple as calling str(obj), there would be no need for the pprint module. I agree. And when I want to use pprint, there are usually additional output formatting requirements I need that isn't a "one size fits all" type of problem. I don't see how you can have a standard interface (like __pprint__), and have additional, per-object formatting parameters. I don't see how you can't. Other standard methods take variable arguments: __init__, __new__, __call__ come to mind. > But that's beside the point, I don't like __pprint__ in any event. Too special. I'm not sure what you mean by "too special". It's no more special than any other special method. Do you mean the use-case is not common enough? I would find this useful. Whether enough people would find it useful enough to add yet another special method is an open question. -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python breakpoint opcode
Hi Neal, The last post in the thread was: http://mail.python.org/pipermail/python-dev/1999-August/000793.html referencing a download at http://sirac.inrialpes.fr/~marangoz/python/lineno/ Cheers, Andrew This e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. No communication sent by e-mail to or from Eutechnyx is intended to give rise to contractual or other legal liability, apart from liability which cannot be excluded under English law. This email has been scanned for all known viruses by the Email Protection Agency. http://www.epagency.net www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
On 2009-01-30 11:40, Antoine Pitrou wrote: > Aahz pythoncraft.com> writes: >> There's absolutely no reason not to have a 3.0.2 before 3.1 comes out. >> You're probably right that what Raymond wants to is best not done for >> 3.0.1 -- but once we've agreed in principle that 3.0.x isn't a true >> production release of Python for PEP6 purposes, we can do "release early, >> release often". > > It's a possibility. To be honest, I didn't envision us releasing a 3.0.2 > rather > than focusing on 3.1 (which, as others said, can be released in a few months > if > we keep the amount of changes under control). > > But then it's only a matter of naming. We can continue the 3.0.x series and > incorporate in them whatever was initially planned for 3.1 (including the > IO-in-C branch, the dbm.sqlite module, etc.), and release 3.1 only when the > whole thing is "good enough". That would be my preference. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 30 2009) >>> 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 our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
Antoine Pitrou wrote: > Raymond Hettinger rcn.com> writes: >> * If you're thinking that shelves have very few users and that >> 3.0.0 has had few adopters, doesn't that mitigate the effects >> of making a better format available in 3.0.1? Wouldn't this >> be the time to do it? > > There was already another proposal for an sqlite-based dbm module, you may > want to synchronize with it: > http://bugs.python.org/issue3783 > > As I see it, the problem with introducing it in 3.0.1 is that we would be > rushing in a new piece of code without much review or polish. Again > Also, there are > only two release blockers left for 3.0.1, so we might just finish those and > release, then concentrate on 3.1. > Seems to me that every deviation from the policy introduced as a result for the True/False debacle leads to complications and problems. There's no point having a policy instigated for good reasons if we can ignore those reasons on a whim. So to my mind, ignoring the policy *is* effectively declaring 3.0 to be, well, if not a dead parrot then at least a rushed release. Most consistently missing from this picture has been effective communications (in both directions) with the user base. Consequently nobody knows whether specific features are in serious use, and nobody knows whether 3.0 is intended to be a stable base for production software or not. Ignoring users, and acting as though we know what they are doing and what they want, is not going to lead to better acceptance of future releases. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
2009/1/30 Steven D'Aprano : >> But that's beside the >> >> point, I don't like __pprint__ in any event. Too special. > > I'm not sure what you mean by "too special". It's no more special than any > other special method. Do you mean the use-case is not common enough? I would > find this useful. Whether enough people would find it useful enough to add > yet another special method is an open question. In my view, the issue is that as a special method, *either* it has to be included on all core types (too intrusive for something as non-critical as pprint) *or* pprint has to hard-code the behaviour for core types and still fall back to the special method for non-core types (ugly and a maintenance problem keeping the type tests up to date). Some sort of registry of type-specific implementation functions (whether you call it a generic function or just put together a custom implementation for pprint alone) is more flexible, and less intrusive. It also allows end users to customise the behaviour, even for core types. In all honesty, I think pkgutil.simplegeneric should be documented, exposed, and moved to a library of its own[1]. It's precisely what is needed for this type of situation, which does come up fairly often. I don't think ABCs do what's needed here (although maybe I'm missing something - if so, I'd be interested in knowing what). I'd be willing to look at creating a patch, if the consensus was that this was an appropriate approach and there was a reasonable chance of it being accepted (assuming my code wasn't rubbish :-)) Paul. [1] Note - I have no opinion on the quality of the code, I haven't reviewed it, I am assuming it's OK on the basis that it has been present and in use internally in the pkgutil module for some time now. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
Martin v. Löwis wrote: >> svn up >> svnmerge >> ... conflicts >> svn revert -R . >> svn up >> svnmerge >> ... same conflicts > > Ah. In the 3.0 branch, always do "svn revert ." after svnmerge. > It's ok (Nick says it isn't exactly ok, but I don't understand why) Doing "svn revert ." before making the commit will lose the metadata changes that svnmerge uses for its bookkeeping (i.e. if this practice is used regularly, the tool will completely lose track of which revisions have already been merged). That won't bother those of us that are only backporting cherry-picked revisions, but is rather inconvenient for anyone checking for revisions that haven't been backported yet, but haven't been explicitly blocked either. Doing "svn resolved ." assumes that you did everything else correctly, and even then I don't see how svnmerge could both backport the py3k changes to the metadata and make its own changes and still get the metadata to a sane state. The consequence of getting this approach wrong is that the merge state of the 3.0 maintenance branch can be clobbered completely (losing track both of which revisions have been backported and which have been blocked). Doing both "svn revert ." and "svnmerge merge -M -F " clears out the conflicted metadata and then correctly updates the metadata for the revisions that have been backported. It will always update the svnmerge metadata correctly, regardless of the relative order of the svnmerge and svn update operations. Given the choice of a method which will always do the right thing, over one which always does the wrong thing and another one which only does the right thing if I did two other things in the right order and will completely trash the bookkeeping if I get it wrong, I prefer the option which is guaranteed to be correct (even if it happens to be a little slower as svnmerge recreates the needed metadata updates). If there's something wrong with my understanding of either svn properties or the operation of svnmerge that means the quicker approaches aren't as broken as I think they are, then I'd be happy to adopt one of them (since they *are* faster than my current approach). But until someone pokes a hole in my logic, I'll stick with the slower-but-always-correct methodology (and continue advocating that approach to everyone else doing updates that affect all four branches). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
On Fri, 30 Jan 2009 07:03:03 -0500, Steve Holden wrote: > Antoine Pitrou wrote: >> Raymond Hettinger rcn.com> writes: >>> * If you're thinking that shelves have very few users and that >>> 3.0.0 has had few adopters, doesn't that mitigate the effects >>> of making a better format available in 3.0.1? Wouldn't this >>> be the time to do it? >> >> There was already another proposal for an sqlite-based dbm module, you >> may >> want to synchronize with it: >> http://bugs.python.org/issue3783 >> >> As I see it, the problem with introducing it in 3.0.1 is that we would be >> rushing in a new piece of code without much review or polish. > > Again > >> Also, there are >> only two release blockers left for 3.0.1, so we might just finish those >> and >> release, then concentrate on 3.1. >> > Seems to me that every deviation from the policy introduced as a result > for the True/False debacle leads to complications and problems. There's > no point having a policy instigated for good reasons if we can ignore > those reasons on a whim. > > So to my mind, ignoring the policy *is* effectively declaring 3.0 to be, > well, if not a dead parrot then at least a rushed release. > > Most consistently missing from this picture has been effective > communications (in both directions) with the user base. Consequently > nobody knows whether specific features are in serious use, and nobody > knows whether 3.0 is intended to be a stable base for production > software or not. Ignoring users, and acting as though we know what they > are doing and what they want, is not going to lead to better acceptance > of future releases. My 2 cents as a user... I wouldn't consider v3.0.n (where n is small) for use in production. v3.1 however implies (to me at least) a level of quality where I would be disappointed if it wasn't production ready. Therefore I would suggest the main purpose of any v3.0.1 release is to make sure that v3.1 is up to scratch. Phil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
Steven D'Aprano wrote: Eric Smith wrote: Terry Reedy wrote: Ron Adam wrote: Steven D'Aprano wrote: Michael Foord wrote: Don't we have a pretty-print API - and isn't it spelled __str__ ? Not really. If it were as simple as calling str(obj), there would be no need for the pprint module. I agree. And when I want to use pprint, there are usually additional output formatting requirements I need that isn't a "one size fits all" type of problem. I don't see how you can have a standard interface (like __pprint__), and have additional, per-object formatting parameters. I don't see how you can't. Other standard methods take variable arguments: __init__, __new__, __call__ come to mind. Those are different, since they're called on known specific objects. Having params to a generic __pprint__ method would be more like having params to __str__ or __repr__. If you know enough about the object to know which parameters to pass to its pretty-print function, then just call a normal method on the object to do the pprint'ing. But, for example, assuming pprint for a list is recursive (as it is for repr), how would you pass the arguments around? > But that's beside the point, I don't like __pprint__ in any event. Too special. I'm not sure what you mean by "too special". It's no more special than any other special method. Do you mean the use-case is not common enough? I would find this useful. Whether enough people would find it useful enough to add yet another special method is an open question. Bad choice of words on my part. I meant "too special case" for such machinery. That is, the use case isn't common enough. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
Martin v. Löwis wrote: >> There are potential problems with doing it that way [1]. The safer >> option is to do: >> >> svn revert . >> svnmerge merge -M -F > > I still don't see the potential problem. If you do svnmerge, svn commit, > all is fine, right? Sort of. svnmerge still gets confused by the fact that the revision being backported already has changes to the svnmerge metadata, so you have to either revert it (which is always wrong), or flag it as resolved (I believe that svnmerge actually does get that case right, but I haven't checked it extensively - since if it does get it right, I don't understand why it leaves the conflict in place instead of automatically marking it as resolved). Regardless, the consequences of forgetting that you did the svn up after the merge instead of before (e.g. if it took some time to get the backported version working, or if something interrupted you between the initial backport/update and the final test and commit step) are fairly hard to clean up, so I prefer the safe approach (despite the extra minute or two it takes for svnmerge to recalculate the metadata changes). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
Nick Coghlan gmail.com> writes: > > Doing "svn resolved ." assumes that you did everything else correctly, > and even then I don't see how svnmerge could both backport the py3k > changes to the metadata and make its own changes and still get the > metadata to a sane state. The metadata are discriminated by source merge URL. That is, the py3k metadata are of the form "/python/trunk:" while the release30-maint metadata are of the form "/python/branches/py3k:". (*) I guess that's what allows svn to not shoot itself in the foot when merging. I did "svn resolved ." again yesterday and it doesn't seem to have borked anything. (*) (try "svn propget svnmerge-integrated" or "svn propget svnmerge-blocked") Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
Antoine Pitrou wrote: > Nick Coghlan gmail.com> writes: >> Doing "svn resolved ." assumes that you did everything else correctly, >> and even then I don't see how svnmerge could both backport the py3k >> changes to the metadata and make its own changes and still get the >> metadata to a sane state. > > The metadata are discriminated by source merge URL. That is, the py3k metadata > are of the form "/python/trunk:" while the release30-maint > metadata are of the form "/python/branches/py3k:". (*) > I guess that's what allows svn to not shoot itself in the foot when merging. Ah, thanks - that's the piece I was missing regarding why the svn resolved trick works (I have used that approach before and checked it as you did - as Martin has pointed out, the only time it definitely goes wrong is if you do an update *after* doing the local merge and the update included other backports). So I'll chalk the fact that svnmerge emits that false alarm up to a deficiency in the tool and only use the "regenerate the metadata" approach when I suspect I may have done the merge+update in the wrong order (since it's a harmless thing to do - it just wastes a couple of minutes relative to the svn resolved approach). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Universal newlines, and the gzip module.
Christopher> 1) It would be nice if the gzip module (and the zip lib Christopher>module) supported Universal newlines -- you could read a Christopher>compressed text file with "wrong" newlines, and have Christopher>them handled properly. However, that may be hard to do, Christopher>so at least: Christopher> 2) Passing a 'U' flag in to gzip.open shouldn't break it. I agree with Brett that 'U' is meaningless on the compressed file itself. You want it applied to the contents of the compressed file though, is that right? That makes sense to me. It probably belongs in a separate argument though. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
2009/1/30 Steve Holden : > Most consistently missing from this picture has been effective > communications (in both directions) with the user base. Serious question: does anybody know how to get better communication from the user base? My impression is that it's pretty hard to find out who is actually using 3.0, and get any feedback from them. I suppose a general query on clp might get some feedback, but otherwise, what? I've not seen any significant amount of blog activity on 3.0. As a small contribution, my position is as follows: I use Python mostly for one-off scripts, both at home and at work. I also use Python for a suite of database monitoring tools, as well as using some applications written in Python (Mercurial and MoinMoin, in particular). Ignore the applications, they aren't moving to 3.0 in the short term (based on comments from the application teams). For my own use, the key modules I need are cx_Oracle and pywin32. cx_Oracle was available for 3.0 very quickly (and apparently the port wasn't too hard, which is good feedback!). pywin32 is just now available in preview form. My production box is still using 2.5, and I will probably migrate to 2.6 in due course - but I'll probably leave 3.0 for the foreseeable future (I may rethink if MoinMoin becomes available on 3.0 sooner rather than later). For my desktop PC, I'm using 2.6 but as I do a fair bit of experimenting with modules, I'm taking it slowly (I'd like to see 2.6 binaries for a few more packages, really). I have 3.0 installed, but not as default, so frankly it doesn't get used unless I'm deliberately trying it out. Based on the recent threads, I'm thinking I really should make 3.0 the default just to get a better feel for it. The io-in-C changes would probably help push me to doing so (performance isn't really an issue for me, but I find I'm irrationally swayed by the "3.0 io is slow, but it's getting fixed soon by the io-in-C rewrite" messages I've been seeing - I have no idea if that's a general impression, or just a result of my following python-dev, though). It would make no difference to me, personally, whether *any* of the changes being discussed were released in 3.0.1 or 3.1 (except insofar as I'd like to see them sooner rather than later). So, in summary, for practical purposes I use 2.6. I probably could use 3.0 for a significant proportion of my needs, but the impressions I've been getting make me cautious. I'm using Windows, and although I *can* build a lot of stuff myself, I really don't want to be bothered, so I rely on bdist_wininst installers being available, which is an additional constraint. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
2009/1/30 Walter Dörwald : > Paul Moore wrote: > >> [...] >> In all honesty, I think pkgutil.simplegeneric should be documented, >> exposed, and moved to a library of its own[1]. > > http://pypi.python.org/pypi/simplegeneric Thanks, I was aware of that. I assume that the barrier to getting this into the stdlib will be higher than to simply exposing an implementation already available in the stdlib. To be honest, all I would like is for these regular "let's have another special method" discussions to become unnecessary... Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
Paul Moore wrote: > [...] > In all honesty, I think pkgutil.simplegeneric should be documented, > exposed, and moved to a library of its own[1]. http://pypi.python.org/pypi/simplegeneric > [...] Servus, Walter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 29, 2009, at 1:13 PM, Guido van Rossum wrote: I'd like to find a middle ground. We can all agree that the users of 3.0 are a small minority compared to the 2.x users. Therefore I think we can bend the rules more than we have done for the recent 2.x releases. Those rules weren't always there (anyone remember the addition of bool, True and False to 2.2.1?). The rules were introduced for the benefit of our most conservative users -- people who introduce Python in an enterprise and don't want to find that they are forced to upgrade in six months. Removing stuff that should have been removed is fine, and I'm even okay with bending the "should have been" definition. Frankly, I don't really believe the users for whom those rules were created are using 3.0 yet. Instead, I expect there to be two types of users: people in the educational business who don't have a lot of bridges to burn and are eager to use the new features; and developers of serious Python software (e.g. Twisted) who are trying to figure out how to port their code to 3.0. The first group isn't affected by the changes we're considering here (e.g. removing cmp or some obscure functions from the operator module). The latter group *may* be affected, simply because they may have some pre-3.0 code using old features that (by accident) still works under 3.0. I mostly agree. I'm also concerned about downstream consumers that may be distributing 3.0 and will have a different schedule for doing their upgrades. What I really want to avoid is people having to do stuff like the ugliness to work around the 2.2.1 additions: try: True except NameError: True = 1 False = 0 Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSYMZ5nEjvBPtnXfVAQJZyAP/dAbxc37a3HPfZ6SYH29OxfsyWeist6yk 0jli2WVDiLnc9iYmLky3Bj/B7aijZpq2X2/UOS/F6akOYJhLKfjYckiXzcjBmBIK Ypy3uGrw1wRFxz4ZrJGGzBjxvzSkbYj8ijkGsPqm95FDalq2YOXtrRbOft861dyy 4i2APtZ40AA= =s7U3 -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
Hi all, > On Thu, Jan 29, 2009 at 6:12 AM, Ben North wrote: >> Hi, >> >> I find 'functools.partial' useful, but occasionally I'm unable to use it >> because it lacks a 'from the right' version. > -1 For me, the main objection to a partial that places its stored positional arguments from the right is that you don't know which positions those arguments will actually occupy until the partial is called. Who *really* thinks that would be a neat feature? There's probably a reason why Haskell doesn't do this... Peter Harris ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 29, 2009, at 5:09 PM, Aahz wrote: The problem is that the obvious candidate for doing the vetting is the Release Manager, and Barry doesn't like this approach. The vetting does need to be handled by a core committer IMO -- MAL, are you volunteering? Anyone else? Barry, are you actively opposed to marking 3.0.x as experimental, or do you just dislike it? (I.e. are you -1 or -0?) I'm opposed to marking 3.0 experimental, so I guess -1 there. It's the first model year of a redesigned nameplate, but it's still got four wheels, a good motor and it turns mostly in the direction you point it. :) No release is ever what everyone wants. There has never been a release where I haven't wanted to add or change something after the fact (see my recent 2.6 unicode grumblings). Perhaps frustratingly, but usually correctly, the community is very resistant to making such feature or API changes after a release is made. That's just life; we deal with it, workaround it and work harder towards the next major release. If that's too burdensome, then maybe it's really the 18 month development cycle that needs to be re-examined. All that aside, I will support whatever community consensus or BDFL pronouncement is made here. Don't be surprised if when you ask me though I'm more conservative than you want. You can always appeal to a higher authority (python-dev or Guido). So don't worry, I'll continue to RM the 3.0 series! Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSYMbn3EjvBPtnXfVAQLsUAP+J3WPGMNgGPSWrawJa8Yp+1RBTIt2vOif rgV+5xyOQqOKnuDntZPAv1R2SqrTCHv8abyLP4pBaoklqtymIDgikiOLJkI2tHij MT+gfPu4Xb7F35HAXE/6vhel124nr8JG15fXBQdEWqiozNZl9GaXEqKZY8tdhgkC 4VDdY6KEwL0= =kvOy -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 29, 2009, at 6:27 PM, Raymond Hettinger wrote: The problem is that the obvious candidate for doing the vetting is the Release Manager, and Barry doesn't like this approach. The vetting does need to be handled by a core committer IMO -- MAL, are you volunteering? Anyone else? It should be someone who is using 3.0 regularly (ideally someone who is working on fixing it). IMO, people who aren't exercising it don't really have a feel for the problems or the cost/benefits of the fixes. That's not the right way to look at it. I'm using 2.6 heavily these days, does that mean I get to decide what goes in it or not? No. Everyone here, whether they are using 2.6 or not should weigh in, with of course one BDFL to rule them all. Same goes for 3.0. This is a community effort and I feel strongly that we should work toward reaching consensus (that seems to be an American theme these days). Make your case, we'll listen to the pros and cons, decide as a community and then move on. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSYMcnHEjvBPtnXfVAQK+aQQApR5McrCOiYUf6RiNvmrDKmTShMde4iWt Rh9x3wY3EVQskcgdpd+05VSfceVCKJJlqbR1NdMDtnuzM8aD56qQyAxYHhqYyxkh 0adHg1ZmYt/95K0/WE3DM8NoBUPxUFIb4nyeprGBsYola9BUQNc//VSRSIyXf0U6 p3xwN8oQS/c= =KKeq -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 29, 2009, at 6:40 PM, Guido van Rossum wrote: On Thu, Jan 29, 2009 at 3:27 PM, Raymond Hettinger wrote: To get the ball rolling, I have a candidate for discussion. Very late in the 3.0 process (after feature freeze), the bsddb code was ripped out (good riddance). This had the unfortunate side-effect of crippling shelves which now fall back to using dumbdbm. I'm somewhat working on an alternate dbm based on sqlite3: http://code.activestate.com/recipes/576638/ It is a pure python module and probably will not be used directly, but shelves will see an immediate benefit (especially for large shelves) in terms of speed and space. On the one hand, it is an API change or new feature because people can (if they choose) access the dbm directly. OTOH, it is basically a performance fix for shelves whose API won't change at all. The part that is visible and incompatible is that 3.0.1 shelves won't be readable by 3.0.0. That is too much for 3.0.1. It could affect external file formats which strikes me as a bad idea. Sounds like a good candidate for 3.1, which we should be expecting in 4-6 months I hope. Also you could try find shelve users (are there any?) and recommend they install this as a 3rd party package, with the expectation it'll be built into 3.1. I concur. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSYMctnEjvBPtnXfVAQKC3QP/bVCQ6KTI5Kd1H/y2Qp85pkLiC8JAH7ap 8vJ2xPjZde4oe6tz5WRziUparpM5FMA4Cz0fuMg4C7vtt6ZLIG27OKVuXx9i4atG zrtnEfs129Xouq4se6UFiIaIj1KNiNWbZa4cOkSlQFUq37Ww/B25JlrtGnreZB4v 13r8lRzTNOU= =8Fo7 -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 29, 2009, at 7:43 PM, Raymond Hettinger wrote: We should have insisted that bsddb not be taken out until a replacement was put in. The process was broken with the RM insisting on feature freeze early in the game but letting tools like bsddb get ripped-out near the end. IMO, it was foolish to do one without the other. Very good arguments were made for ripping bsddb out. Guido agreed. A replacement would have delayed 3.0 even more than it originally was, and the replacement would not have been battle tested. It's possible, maybe even likely, that the replacement would have been found inadequate later on and then we'd be saddled with a different mistake. Given that it's easy to make 3rd party packages work, I firmly believe this was the right decision. With a proven, solid, popular replacement available for several months, it will be easy to pull that into the 3.1 release. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSYMdtXEjvBPtnXfVAQK+FAQAlNL26s4ekva/3jpnATfZfXtAkHa+Wqdo f9luB8gkLk3Dk0qXyjm6AisFCMh+Zgu8g+OgrWS3DO6yR+/SlfjVcPbq0kr8nP+L +EXXisuZofeHuxp0JZ3ePoL94ALbv35norx1yHqiKnEMEvUbCfdNWb4sGE2kM5ZE snfeFattlIg= =RQ7t -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 29, 2009, at 8:34 PM, Stephen J. Turnbull wrote: I think that the important question is "can the 3.0.x series be made 'viable' in less than the time frame for 3.1?" If not, I really have to think it's DOA from the point of view of folks who consider 3.0.0 non-viable. I think that's what Barry and Martin are saying. Of course, the definition of "viable" is the key thing here. I'm not picking on Raymond, but what is not viable for him will be perfectly viable for other people. We have to be very careful not to view our little group of insiders as the sole universe of Python users (3.0 or otherwise). Guido is saying something different. AIUI, he's saying that explicitly introducing controlled instability into 3.0.x of the form "this is what the extremely stable non-buggy inherited-from-3.0 core of 3.1 is going to look like" will be a great service to those who consider 3.0.0 non-viable. The key point is that new features in 3.1 are generally going to be considered less reliable than those inherited from 3.0, and thus a debugged 3.0, even if the implementations have been unstable, provides a way for the very demanding to determine what that set is, and to test how it behaves in their applications. I'm not sure I agree with that last paragraph. We have a pretty good track record of introducing stable new features in dot-x releases, so there's no reason to believe that the same won't work for 3.x. I think it's worth a try, after consultation with some of the major developers who are the ostensible beneficiaries. But if tried, I think it's important to mark 3.0.x as "not yet stable" even if the instability is carefully defined and controlled. It all depends on where that instability lies. If 3.0 crashed every time you raised an exception due to some core design flaw, then yeah, we'd have a problem. The fact that a bundled module doesn't do what you want it to does not scream instability to me. The should-have- been-removed features don't either. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSYMfenEjvBPtnXfVAQLIhwP+JVFJWXRoQ5Fz65vrmmGo+8w7ZspjVCWP 9a+yrAh1aGHf0w4vQAirRuBGZNWvl4e5F/Pd4DoWdFVPPKuEhyOiavPAP90ViThy yKHHoEBv6cloUIRXrKendJGzA7L5bDVN0CoQjcPh499mpDxvq7aGgru2lYdD7iT0 KuB21maqMTc= =dWTA -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.0.1/3.1.0 summary
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 29, 2009, at 10:59 PM, Brett Cannon wrote: 1. Barry, who is the release manager for 3.0.1, does not like the idea of the cruft that is being proposed removed from 3.0.1. Personally I say we continue to peer pressure him as I think a new major release is not like our typical minor release, but I am not about to force Barry to go against what he thinks is reasonable unless I am willing to step up as release manager (and I am not since I simply don't have the time to learn the process fast enough along with just a lack of time with other Python stuff). I followed up in a different thread, but just FTR here. I'll continue to RM 3.0. I'll follow the community consensus on specific issues, but if there isn't a clear one and I have to decide, I'll likely take the more conservative path. Appealing to python-dev and Guido is (as always :) allowed. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSYMkjHEjvBPtnXfVAQK/fgP/T4uWwU41k1OEgS6ngXlZvUao3dVh0Hni f+iyeo+cyvWggp6ks1NLoJ+BOH/lpwIybwtuLqUI/FcajctdlOUaTyw2CE2jPjgD SMJID5oj1e/7vpB3Dk26RCIB+trZ6GTg1lC4OjRVn0vrKK/QVRg6dYD2YKcW0Seh fF++3EHxhW0= =TMO+ -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.0.1/3.1.0 summary
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 30, 2009, at 12:53 AM, Martin v. Löwis wrote: 1. Barry, who is the release manager for 3.0.1, does not like the idea of the cruft that is being proposed removed from 3.0.1. I don't think he actually said that (in fact, I think he said the opposite). It would be good if he clarified, though. To clarify: cruft that should have been removed 3.0 is fine to remove for 3.0.1, for some definition of "should have been". Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSYMkxXEjvBPtnXfVAQIqtgP+Mra/z5nLY5SU56cw0JjgBwCVY1N3060K TSG90E4R+JpCsXRD7sjf2UfSAzKAGKz6gYja3hnt5awzhnCJMacgN0tvXNaAmuYi b7Qb6N4oV3izDGZPl3x0EO3DGimov2Nq8hCsEZbYnNd3U62MwRlzpW+FJbFJlZHO VR1jiVWX8Ig= =p0VE -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
> Paul Moore wrote: > > Serious question: does anybody know how to get better communication > from the user base? My impression is that it's pretty hard to find out > who is actually using 3.0, and get any feedback from them. I suppose a > general query on clp might get some feedback, but otherwise, what? > I've not seen any significant amount of blog activity on 3.0. I teach programming in a CS dept. at a UK university. We've been teaching Python in one context or another for 5 years now, and are currently in our second year of teaching it as the primary programming language. We have to make decisions on software versions for the coming academic year during the summer months. This means that we've had to be content this year with Python 2.5. We'd love to switch to 3.0 as soon as possible (i.e., Oct 2009), as it is a significantly cleaner language for our purposes. However, we make extensive use of third-party libraries and frameworks such as Pygame, wxPython, etc, to increase the motivation levels of students. The 3.0-readiness of these libraries and frameworks is inevitably going to be a factor in the decision we make this summer. Nick ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.0.1/3.1.0 summary
On Fri, Jan 30, 2009 at 4:03 PM, Barry Warsaw wrote: > To clarify: cruft that should have been removed 3.0 is fine to remove for > 3.0.1, for some definition of "should have been". Just to double check, can I take this as a green light to continue with the cmp removal (http://bugs.python.org/issue1717) for 3.0.1? Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (01/23/09 - 01/30/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2352 open (+54) / 14582 closed (+20) / 16934 total (+74) Open issues with patches: 788 Average duration of open issues: 697 days. Median duration of open issues: 6 days. Open Issues Breakdown open 2328 (+53) pending24 ( +1) Issues Created Or Reopened (74) ___ urrlib2/httplib doesn't reset file position between requests 01/23/09 http://bugs.python.org/issue5038created matejcik Adjust reference-counting note 01/24/09 http://bugs.python.org/issue5039created tjreedy Bug of CGIXMLRPCRequestHandler 01/24/09 http://bugs.python.org/issue5040created WayneHuang Memory leak in imp.find_module 01/24/09 CLOSED http://bugs.python.org/issue5041created ocean-city patch, easy Structure sub-subclass does not initialize with base class posit 01/24/09 http://bugs.python.org/issue5042created jaraco get_msvcr() returns None rather than [] 01/24/09 http://bugs.python.org/issue5043created lkcl name not found in generator in eval()01/24/09 http://bugs.python.org/issue5044created fjhpy imaplib should remove length of literal strings 01/24/09 http://bugs.python.org/issue5045created bmoore native win32 and wine mingw+msys build of python2.7 01/24/09 CLOSED http://bugs.python.org/issue5046created lkcl patch Remove Monterey support from configure.in01/24/09 http://bugs.python.org/issue5047created skip.montanaro patch Extending itertools.combinations 01/25/09 CLOSED http://bugs.python.org/issue5048created konryd ctypes unwilling to allow pickling wide character01/25/09 http://bugs.python.org/issue5049created jaraco unicode(C) invokes C.__unicode__ when __unicode__ is defined 01/25/09 CLOSED http://bugs.python.org/issue5050created livibetter test_update2 in test_os.py invalid due to os.environ.clear() fol 01/25/09 http://bugs.python.org/issue5051created lkcl Mark distutils to stay compatible with 2.3 01/25/09 http://bugs.python.org/issue5052reopened tarek http.client.HTTPMessage.getallmatchingheaders() always returns [ 01/25/09 http://bugs.python.org/issue5053created mwatkins patch CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly parsed01/25/09 http://bugs.python.org/issue5054created mwatkins Distutils-SIG page needs to be updated 01/25/09 CLOSED http://bugs.python.org/issue5055created akitada PyAPI assumes OS can access shared data in loadable modules (win 01/25/09 CLOSED http://bugs.python.org/issue5056created lkcl patch Unicode-width dependent optimization leads to n
Re: [Python-Dev] Summary of Python tracker Issues
On Fri, 30 Jan 2009 18:06:48 +0100 (CET), Python tracker wrote: [snip] Average duration of open issues: 697 days. Median duration of open issues: 6 days. It seems there's a bug in the summary tool. I thought it odd a few weeks ago when I noticed the median duration of open issues was one day. I just went back and checked and the week before it was one day it was 2759 days. Perhaps there is some sort of overflow problem when computing this value? Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
[email protected] wrote: Hi all, On Thu, Jan 29, 2009 at 6:12 AM, Ben North wrote: I find 'functools.partial' useful, but occasionally I'm unable to use it because it lacks a 'from the right' version. -1 For me, the main objection to a partial that places its stored positional arguments from the right is that you don't know which positions those arguments will actually occupy until the partial is called. Certainly this interacts in a magical way with keyword args. That definitional problem is the reason there was no curry_right in the original recipe that was the basis of the first partial. If you have: def button(root, position, action=None, text='*', color=None): ... ... blue_button = partial(button, my_root, color=(0,0,1)) Should partial_right(blue_button, 'red') change the color or the text? It is computationally hard to do that (may have to chase chains of **kwarg-passing functions), but even hard to document. So, I'd avoid it. --Scott David Daniels [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
On Thu, Jan 29, 2009 at 8:25 PM, Raymond Hettinger wrote: > > [Guido van Rossum] >> >> Sorry, not convinced. > > No worries. Py3.1 is not far off. > > Just so I'm clear. Are you thinking that 3.0.x will never have > fast shelves, or are you thinking 3.0.2 or 3.0.3 after some > external deployment and battle-testing for the module? I don't know about fast shelves, but I don't think your new module should be added to 3.0.x for any x. Who knows if there even will be a 3.0.2 -- it sounds like it's better to focus on 3.1 after 3.0.1. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Universal newlines, and the gzip module.
[email protected] wrote: Christopher> 1) It would be nice if the gzip module (and the zip lib Christopher>module) supported Universal newlines -- you could read a Christopher>compressed text file with "wrong" newlines, and have Christopher>them handled properly. However, that may be hard to do, Christopher>so at least: Christopher> 2) Passing a 'U' flag in to gzip.open shouldn't break it. I agree with Brett that 'U' is meaningless on the compressed file itself. right -- I think the code that deals with the flags is not smart enough -- it adds the 'b' flag if it isn't already there, but that's all it does. There are only a few flags that make sense for opening a gzip file -- it should only use those, and either ignore others or raise an exception if there are others that don't make sense. You want it applied to the contents of the compressed file though, is that right? That would be great. That makes sense to me. It probably belongs in a separate argument though. I could go either way on that -- if we simply extracted the 'U' from the passed in mode, we wouldn't have to change the API at all, and it wouldn't break any code that wasn't broken already. As for having 'U' applied to the uncompressed data -- I have no idea how much work that would be -- it depends on how it is currently handling text files (does that work -- i.e \r\n converted to \n on Windows?), and how the Universal newline code is written. In any case, the 'U' flag should NEVER get passed through to the file opening code, and that's easy to fix. I tried to post this to the bug tracker, but my attempt to create an account failed -- do I need to be pre-approved or something? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Partial function application 'from the right'
Hi, > [ Potential new "functools.partial_right", e.g., > >split_comma = partial_right(str.split, '.') > ] Thanks for the feedback. Apologies if (as was suggested) this should have gone to python-ideas; I thought as a fairly small extension to existing functionality it would be OK here. I'll try to summarise the responses. There was some very luke-warm support. Terry Reedy suggested it would be worth posting a patch to the tracker, for the record, even if it turns out to be rejected. Nick Coghlan made more clear than I did the main reason a 'partial_right' would be useful: > [...] some functions and methods written in C (such as string methods) > *don't* [support keyword args], so partial's keyword support doesn't > help. > > A functools.rpartial would go some way towards addressing that. On the other hand, Collin Winter asked for more evidence that real benefit (beyond mere 'completeness' of the functools module) would result. I don't really have to hand anything more than the three cases mentioned in my original email (str.split, math.log, itertools.islice), but since the change is so small, I thought the feature worth raising. Leif Walsh pointed out that you could achieve the same effect by defining your own function. This is true, but functools.partial exists because it's sometimes useful to create such functions either more concisely, or anonymously. A 'partial_right' would allow more such functions to be so created. Peter Harris was negative on the idea, pointing out that after g = partial_right(f, 7) you don't know which argument of 'f' the '7' is going to end up as, because it depends on how many are supplied in the eventual call to 'g'. This is true, and would require some care in partial_right's use. Peter also wondered > There's probably a reason why Haskell doesn't do this... I have only written about five lines of Haskell in my life, so take this with a hefty pinch of salt, but: Haskell does have a 'flip' function which reverses the order of a function's arguments, so it looks like you can very easily build a 'partial_right' in Haskell, especially since standard functions are in curried form. There was some discussion (started by Antoine Pitrou) of an idea to generalise 'partial' further, potentially using the Ellipsis object, to allow arbitrarily-placed 'holes' in the argument list. E.g., split_comma = partial(str.split, ..., ',') In some ways I quite like the even-more-completeness of this idea, but think that it might be the wrong side of the complexity/benefit trade-off. Scott David Daniels pointed out that using Ellipsis would have the downside of > [...] preventing any use of partial when an argument could be an the > Ellipsis instance. This could be fixed by making the general form be something with the meaning partial_explicit(f, hole_sentinel, *args, **kwargs) where appearances of the exact object 'hole_sentinel' in 'args' would indicate a hole, to be filled in at the time of the future call. A user wanting to have '...' passed in as a true argument could then do g = partial_explicit(f, None, 3, ..., 4, axis = 2) or hole = object() g = partial_explicit(f, hole, 3, ..., hole, 4, axis = 2) if they wanted a true '...' argument and a hole. (I might have the syntax for this wrong, having not played with Python 3.0, but I hope the idea is clear.) There was some concern expressed (by Daniel Stutzbach, Alexander Belopolsky) that the meaning of '...' would be confusing --- 'one hole' or 'arbitrary many holes'? I think the extra complexity vs extra functionality trade-off is worth considering for 'partial_right', but my personal opinion is that a 'partial_explicit' has that trade-off the wrong way. I'll try to find time to create the patch in the tracker in the next few days, by which time perhaps it'll have become clearer whether the idea is a good one or not. Thanks, Ben. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.0.1/3.1.0 summary
On Fri, Jan 30, 2009 at 08:03, Barry Warsaw wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Jan 30, 2009, at 12:53 AM, Martin v. Löwis wrote: > >>> 1. Barry, who is the release manager for 3.0.1, does not like the idea >>> of the cruft that is being proposed removed from 3.0.1. >> >> I don't think he actually said that (in fact, I think he said the >> opposite). It would be good if he clarified, though. > > To clarify: cruft that should have been removed 3.0 is fine to remove for > 3.0.1, for some definition of "should have been". Great! Then should we start planning for 3.0.1 in terms of release dates and what to have in the release so we can get this out the door quickly? -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.0.1/3.1.0 summary
On Fri, Jan 30, 2009 at 1:56 PM, Brett Cannon wrote: > Great! Then should we start planning for 3.0.1 in terms of release > dates and what to have in the release so we can get this out the door > quickly? I think considering there's only two release blockers we should plan for about a week or two from now. I'm not sure if we want to do a release candidate; we didn't for 2.6.1, but maybe it would be good to see if the community can find any other horrible problems. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.0.1/3.1.0 summary
On Fri, Jan 30, 2009 at 12:07, Benjamin Peterson wrote: > On Fri, Jan 30, 2009 at 1:56 PM, Brett Cannon wrote: >> Great! Then should we start planning for 3.0.1 in terms of release >> dates and what to have in the release so we can get this out the door >> quickly? > > I think considering there's only two release blockers we should plan > for about a week or two from now. > > I'm not sure if we want to do a release candidate; we didn't for > 2.6.1, but maybe it would be good to see if the community can find any > other horrible problems. I say it's Barry's call. If he has the time and wants to, then great; they don't hurt. But I know I won't object if we don't have one. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
On 29-Jan-09, at 3:38 PM, Daniel Stutzbach wrote: On Thu, Jan 29, 2009 at 5:24 PM, Mike Klaas wrote: And yet, python isn't confined to mathematical notation. *, ** are both overloaded for use in argument lists to no-one's peril, AFAICT. Certainly, but there is no danger of confusion them for multiplication in context, whereas: split_comma = partial(str.split, ..., ',') to me looks like "make ',' the last argument" rather than "make ',' the second argument". Yes, I agree. I mistakenly thought that that was the proposal under discussion (that partial(f, ..., 2) == right_curry(f, 2)) -Mike ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Universal newlines, and the gzip module.
Christopher Barker wrote: I tried to post this to the bug tracker, but my attempt to create an account failed -- do I need to be pre-approved or something? No. If you do not get a response from the above, and a retry does not work, you could email [email protected] with details on what you did and how it failed. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
Paul Moore wrote: Serious question: does anybody know how to get better communication from the user base? One of the nice things about Python is that the downloads are truly free -- no required 'registration'. On the other hand, there is no option to give feedback either. If PSF/devs wanted to add something to the site, and someone else volunteered to do the implementation, I would volunteer to help with both design and analysis. That said, I think a main determinant of general 3.0 use will be availability of 3rd-party libraries, including Windows binaries. So perhaps we should aim survey efforts at their authors. I have the impression that the C-API porting guide needs improvement for such effort. On the other hand, perhaps they wonder whether ports will be used. In that case, we need more reports like the post of Nick Efford: " > We'd love to switch to 3.0 as soon as possible (i.e., Oct 2009), > as it is a significantly cleaner language for our purposes. > [university CS courses] > However, we make extensive use of third-party libraries and > frameworks such as Pygame, wxPython, etc, to increase the > motivation levels of students. The 3.0-readiness of these > libraries and frameworks is inevitably going to be a factor in > the decision we make this summer. " Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
I am just replying to the end of this thread to throw in a reminder about my partial.skip patch, which allows the following usage: split_one = partial(str.split, partial.skip, 1) Not looking to say "mine is better", but if the idea is being given merit, I like the skipping arguments method better than just the "right partial", which I think is confusing combined with keyword and optional arguments. And, this patch already exists. Could it be re-evaluated? On Fri, Jan 30, 2009 at 4:20 PM, Mike Klaas wrote: > On 29-Jan-09, at 3:38 PM, Daniel Stutzbach wrote: > >> On Thu, Jan 29, 2009 at 5:24 PM, Mike Klaas wrote: >>> >>> And yet, python isn't confined to mathematical notation. *, ** are both >>> overloaded for use in argument lists to no-one's peril, AFAICT. >> >> Certainly, but there is no danger of confusion them for multiplication in >> context, whereas: >> >> split_comma = partial(str.split, ..., ',') >> >> to me looks like "make ',' the last argument" rather than "make ',' the >> second argument". > > Yes, I agree. I mistakenly thought that that was the proposal under > discussion (that partial(f, ..., 2) == right_curry(f, 2)) > > -Mike > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ironfroggy%40gmail.com > -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
>> Ah. In the 3.0 branch, always do "svn revert ." after svnmerge. >> It's ok (Nick says it isn't exactly ok, but I don't understand why) > > Doing "svn revert ." before making the commit will lose the metadata > changes that svnmerge uses for its bookkeeping (i.e. if this practice is > used regularly, the tool will completely lose track of which revisions > have already been merged). How so? The metadata are getting tracked just fine, no loss whatsoever. > That won't bother those of us that are only > backporting cherry-picked revisions, but is rather inconvenient for > anyone checking for revisions that haven't been backported yet, but > haven't been explicitly blocked either. Take a look at r68901, which I merged using the procedure I described. svn diff -r68900:68901 --depth empty . gives Modified: svnmerge-integrated - /python/branches/py3k:1-67498,67522-67529,67531-67533,67535-67544,67546-67549,67551-67584,67586-67602,67604-67606,67608-67609,67611-67619,67621-67635,67638,67650,67653-67701,67703-67712,67714,67716-67746,67748,67750-67762,67764-67797,67799-67809,67811-67822,67825-67838,67840-67850,67852-67857,67859-67885,67888-67902,67904-67909,67911-67931,67933,67937-67938,67940,67950-67955,67957-67958,67960-67963,67965-67973,67975-67980,67982,67984-68014,68016-68058,68060-68089,68091-68093,68101,68103,68132,68137,68139-68152,68169-68170,68175,68178,68184,68193,68200,68205-68206,68212,68216,68223-68224,68226-68229,68237,68242,68245,68247,68249,68309,68321,68342,68363,68375,68401,68427,68440,68443,68451,68454,68463,68474-68475,68477,68508,68511,68525,68529,68553,68581,68587,68615,68619,68630,68638,68650-68653,68662,68669,68675,68677,68700,68709,68730,68732,68746,68767-68770,68782,68814-68815,68836,68855,68857,68887,68895 + /python/branches/py3k:1-67498,67522-67529,67531-67533,67535-67544,67546-67549,67551-67584,67586-67602,67604-67606,67608-67609,67611-67619,67621-67635,67638,67650,67653-67701,67703-67712,67714,67716-67746,67748,67750-67762,67764-67797,67799-67809,67811-67822,67825-67838,67840-67850,67852-67857,67859-67885,67888-67902,67904-67909,67911-67931,67933,67937-67938,67940,67950-67955,67957-67958,67960-67963,67965-67973,67975-67980,67982,67984-68014,68016-68058,68060-68089,68091-68093,68101,68103,68132,68137,68139-68152,68169-68170,68175,68178,68184,68193,68200,68205-68206,68212,68216,68223-68224,68226-68229,68237,68242,68245,68247,68249,68309,68321,68342,68363,68375,68401,68427,68440,68443,68451,68454,68463,68474-68475,68477,68508,68511,68525,68529,68553,68581,68587,68615,68619,68630,68638,68650-68653,68662,68669,68675,68677,68700,68709,68730,68732,68746,68767-68770,68782,68814-68815,68836,68855,68857,68887,68895,68898 As you can see, 68898 has been added to svnmerge-integrated, and this is indeed the revision that I merged. > Doing "svn resolved ." assumes that you did everything else correctly, > and even then I don't see how svnmerge could both backport the py3k > changes to the metadata and make its own changes and still get the > metadata to a sane state. The *only* interesting metadata in the svnmerge-integrated property are the ones that svnmerge has written, and svnmerge writes them correctly. > The consequence of getting this approach wrong > is that the merge state of the 3.0 maintenance branch can be clobbered > completely (losing track both of which revisions have been backported > and which have been blocked). Not with the procedure I described. > > Doing both "svn revert ." and "svnmerge merge -M -F " clears > out the conflicted metadata and then correctly updates the metadata for > the revisions that have been backported. It will always update the > svnmerge metadata correctly, regardless of the relative order of the > svnmerge and svn update operations. I don't understand why you bring up this "regardless of the relative order"? Who ever proposed a different order? If you do things in the order I suggest, everything will be fine, right? > Given the choice of a method which will always do the right thing, over > one which always does the wrong thing and another one which only does > the right thing if I did two other things in the right order and will > completely trash the bookkeeping if I get it wrong That's open for debate. What *specific* wrong order are you talking about? If you do things in the right order, will it still get the bookkeeping wrong? > If there's something wrong with my understanding of either svn > properties or the operation of svnmerge that means the quicker > approaches aren't as broken as I think they are, then I'd be happy to > adopt one of them (since they *are* faster than my current approach). > But until someone pokes a hole in my logic, I'll stick with the > slower-but-always-correct methodology (and continue advocating that > approach to everyone else doing updates that affect all four branches). See above. You claim that doing things the way I recommend will lose metadata; I believe this claim is false. Regards, Martin
Re: [Python-Dev] Partial function application 'from the right'
Calvin Spealman gmail.com> writes: > > I am just replying to the end of this thread to throw in a reminder > about my partial.skip patch, which allows the following usage: > > split_one = partial(str.split, partial.skip, 1) > > Not looking to say "mine is better", but if the idea is being given > merit, I like the skipping arguments method better than just the > "right partial", which I think is confusing combined with keyword and > optional arguments. And, this patch already exists. Could it be > re-evaluated? Sorry, where is the patch? If one writes X = partial.skip, it looks quite nice: split_one = partial(str.split, X, 1) Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
> (I believe that svnmerge actually does get that case right, but I > haven't checked it extensively - since if it does get it right, I don't > understand why it leaves the conflict in place instead of automatically > marking it as resolved). I think this is a plain bug. It invokes "svn merge", which creates a conflict, then removes the conflicted property (regardless of whether there was a conflict), then writes the property fresh. It doesn't consider the case that there might have been a conflict, just because such conflict didn't occur in their testing. > Regardless, the consequences of forgetting that you did the svn up after > the merge instead of before (e.g. if it took some time to get the > backported version working, or if something interrupted you between the > initial backport/update and the final test and commit step) are fairly > hard to clean up, so I prefer the safe approach (despite the extra > minute or two it takes for svnmerge to recalculate the metadata changes). If I find that it conflicts on commit, I rather restart all over. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
> Serious question: does anybody know how to get better communication > from the user base? My impression is that it's pretty hard to find out > who is actually using 3.0, and get any feedback from them. I think the bug tracker is a way in which users communicate with developers. There have been 296 issues since Dec 3rd that got tagged with version 3.0. The absolute majority of these were documentation problems (documentation was incorrect). Then, I would say we have installation problems, and then problems with IDLE. There is also a significant number of 2to3 problems. > I'm using Windows, and although I *can* build a lot of stuff myself, I > really don't want to be bothered, so I rely on bdist_wininst > installers being available, which is an additional constraint. Notice that bdist_wininst doesn't really work in 3.0. So you likely won't see many packages until 3.0.1 is released. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
On Fri, Jan 30, 2009 at 7:42 PM, Antoine Pitrou wrote: .. > If one writes X = partial.skip, it looks quite nice: > > split_one = partial(str.split, X, 1) Or even _ = partial.skip split_one = partial(str.split, _, 1) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] FINAL REMINDER: OSCON 2009: Call For Participation
The O'Reilly Open Source Convention has opened up the Call For Participation -- deadline for proposals is Tuesday Feb 3. OSCON will be held July 20-24 in San Jose, California. For more information, see http://conferences.oreilly.com/oscon http://en.oreilly.com/oscon2009/public/cfp/57 -- Aahz ([email protected]) <*> http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
Martin v. Löwis wrote: > See above. You claim that doing things the way I recommend will lose > metadata; I believe this claim is false. I can see how "svn resolved ." gets it right (now that I understand how the conflict is being produced and then fixed automatically by svnmerge, but not actually marked as resolved). I still don't understand how "svn revert ." can avoid losing the metadata changes unless svnmerge is told to modify the properties again after they have been reverted. Or am I misunderstanding SVN, and the revert command doesn't actually revert property changes? Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
> I can see how "svn resolved ." gets it right (now that I understand how > the conflict is being produced and then fixed automatically by svnmerge, > but not actually marked as resolved). > > I still don't understand how "svn revert ." can avoid losing the > metadata changes unless svnmerge is told to modify the properties again > after they have been reverted. Or am I misunderstanding SVN, and the > revert command doesn't actually revert property changes? Oops, I meant "svn resolved ." all the time. When I wrote "svn revert .", it was by mistake. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
