Re: [Python-Dev] Python 3.0.1
Aahz aahz at 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 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] 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 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] 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 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] Python 3.0.1
On 2009-01-30 11:40, Antoine Pitrou wrote: Aahz aahz at 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 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] pprint(iterator)
2009/1/30 Steven D'Aprano st...@pearwood.info: 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 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] [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 revision 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 | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] [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 py3k-rev 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 | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] [Python-checkins] Merging to the 3.0 maintenance branch
Nick Coghlan ncoghlan at 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:list of revisions while the release30-maint metadata are of the form /python/branches/py3k:list of revisions. (*) 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 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] Universal newlines, and the gzip module.
Christopher 1) It would be nice if the gzip module (and the zip lib Christophermodule) supported Universal newlines -- you could read a Christophercompressed text file with wrong newlines, and have Christopherthem handled properly. However, that may be hard to do, Christopherso 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 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] Python 3.0.1
2009/1/30 Steve Holden st...@holdenweb.com: 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 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] 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 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] Partial function application 'from the right'
Hi all, On Thu, Jan 29, 2009 at 6:12 AM, Ben North b...@redfrontdoor.org 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 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] 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 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] 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 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] 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 pyt...@rcn.com 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 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] 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 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] 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 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] 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 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] Python 3.0.1
Paul Moore p.f.mo...@gmail.com 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 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] 3.0.1/3.1.0 summary
On Fri, Jan 30, 2009 at 4:03 PM, Barry Warsaw ba...@python.org 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 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] 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
Re: [Python-Dev] Summary of Python tracker Issues
On Fri, 30 Jan 2009 18:06:48 +0100 (CET), Python tracker sta...@bugs.python.org 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 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] Partial function application 'from the right'
s...@blueyonder.co.uk wrote: Hi all, On Thu, Jan 29, 2009 at 6:12 AM, Ben North b...@redfrontdoor.org 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 scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0.1
On Thu, Jan 29, 2009 at 8:25 PM, Raymond Hettinger pyt...@rcn.com 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 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] Universal newlines, and the gzip module.
s...@pobox.com wrote: Christopher 1) It would be nice if the gzip module (and the zip lib Christophermodule) supported Universal newlines -- you could read a Christophercompressed text file with wrong newlines, and have Christopherthem handled properly. However, that may be hard to do, Christopherso 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/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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] 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 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] 3.0.1/3.1.0 summary
On Fri, Jan 30, 2009 at 08:03, Barry Warsaw ba...@python.org 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 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] 3.0.1/3.1.0 summary
On Fri, Jan 30, 2009 at 1:56 PM, Brett Cannon br...@python.org 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 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] 3.0.1/3.1.0 summary
On Fri, Jan 30, 2009 at 12:07, Benjamin Peterson benja...@python.org wrote: On Fri, Jan 30, 2009 at 1:56 PM, Brett Cannon br...@python.org 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 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] 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 webmas...@python.org with details on what you did and how it failed. ___ 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] 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 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] 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 mike.kl...@gmail.com wrote: On 29-Jan-09, at 3:38 PM, Daniel Stutzbach wrote: On Thu, Jan 29, 2009 at 5:24 PM, Mike Klaas mike.kl...@gmail.com 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 Python-Dev@python.org 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 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] [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 revision 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 ironfroggy at 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 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] [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 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] 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 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] Partial function application 'from the right'
On Fri, Jan 30, 2009 at 7:42 PM, Antoine Pitrou solip...@pitrou.net 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 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] 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 (a...@pythoncraft.com) * 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 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] [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 | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] [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 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
