Re: [Python-Dev] git repositories for trunk and py3k
[back on the list] On Thu, Jul 17, 2008 at 11:24:16PM -0700, Brett Cannon wrote: Turned out to be a rebuild:: r65077 = 82d954e8c20c91562c4c660859d17756cba10992 r65082 = 1c75cce93c2ef2ec87e801888638cfdf5d2ff29a r65085 = 3143c2fbe7315afd29496dc0cdac3122bed30536 Done rebuilding .git/svn/git-svn/.rev_map.6015fed2-1504-0410-9fe1-9d1591cc4771 How do I know what is going to be sent? ``git log`` seems to suggest something by not listing a git-svn-id for my last commit, but is that really the best I got? The command git log git-svn.. will show you changes in your HEAD (by default master) tree that are not in the remote tree (git-svn). Is there some other way to see what will be pushed? I like running gitk before I push something. And how do I diff easily between commits? It depends on what you want, exactly. Maybe you can describe some use cases. A DVCS can't use identify revisions like SVN does. Generally I find myself using heads or tags to identify versions in combination with the ^ operator. For example, git diff HEAD^ would show the difference between the current working tree and the commit before the head of the stored tree. If you want the patch for a single commit, use git show object. For example, git show will display the last commit. To see amk's typo fix: git show 6cadb9c1b7e30a8b66cdba01cd79aa6397a07080 You can also abbreviate the commit id, eg. git show 6cadb9 As I say in my guide, git format-patch and git am are very handy when slinging patches around (e.g. to and from a bug tracker or mailing list). HTH, Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Windows buildbot trick
The most annoying thing on the windows buildbots is when Python crashes hard (with a general protection fault or stack overflow, for example). Usually the system pops up a dialog in this case which allows to attach a debugger to the process. This dialog will stay open until the maintainer manually closes it, and will prevent the next builds. On my boxes I have inserted these two lines into the PythonXY/Scripts/buildbot script, right at the top: import win32api; win32api.SetErrorMode(7) print SetErrorMode(7) called. These lines prevent the dialog box to be displayed for critical errors. For example, on Windows AMD64 the test_cpickle test in the trunk currently fails with a stack overflow; instead of hanging with the mentioned dialog box open the test now terminates: http://www.python.org/dev/buildbot/trunk/amd64%20XP%20trunk/builds/40/step-test/0 -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SVN IS OPEN
Guido van Rossum guido at python.org writes: Thanks Barry! Indeed, I want everyone to focus on stabilization and release blockers (and the occasional speed-up). Be extra careful with what you submit between now and October, ask for a code review unless you're really sure. Also, remember, NO NEW FEATURES! What should be done about http://bugs.python.org/issue2834? Should it make it into 3.0 or be delayed until 3.1? (code-wise there isn't left to be done, take a decision about a potential (? a) modifier and then implement it) ___ 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] SVN IS OPEN
Antoine Pitrou wrote: Guido van Rossum guido at python.org writes: Thanks Barry! Indeed, I want everyone to focus on stabilization and release blockers (and the occasional speed-up). Be extra careful with what you submit between now and October, ask for a code review unless you're really sure. Also, remember, NO NEW FEATURES! What should be done about http://bugs.python.org/issue2834? Should it make it into 3.0 or be delayed until 3.1? (code-wise there isn't left to be done, take a decision about a potential (? a) modifier and then implement it) Before beta 3, I think if we need minor features (such as re.ASCII) to fix fairly major bugs (re.IGNORECASE not working properly by default in Py3k) then they should probably go in (case by case permission still needed from Barry or Guido though, as with any post-beta1 feature addition). Once we're past beta 3 and heading for rc1 then the bar for approving feature additions to fix bugs will move even higher though. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] SVN IS OPEN
Nick Coghlan ncoghlan at gmail.com writes: Before beta 3, I think if we need minor features (such as re.ASCII) to fix fairly major bugs (re.IGNORECASE not working properly by default in Py3k) then they should probably go in (case by case permission still needed from Barry or Guido though, as with any post-beta1 feature addition). Ok I'll tackle the remaining of it before beta 3 then. Thanks 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] SVN IS OPEN
On Fri, Jul 18, 2008 at 3:24 AM, Nick Coghlan [EMAIL PROTECTED] wrote: Antoine Pitrou wrote: Guido van Rossum guido at python.org writes: Thanks Barry! Indeed, I want everyone to focus on stabilization and release blockers (and the occasional speed-up). Be extra careful with what you submit between now and October, ask for a code review unless you're really sure. Also, remember, NO NEW FEATURES! What should be done about http://bugs.python.org/issue2834? Should it make it into 3.0 or be delayed until 3.1? (code-wise there isn't left to be done, take a decision about a potential (? a) modifier and then implement it) Before beta 3, I think if we need minor features (such as re.ASCII) to fix fairly major bugs (re.IGNORECASE not working properly by default in Py3k) then they should probably go in (case by case permission still needed from Barry or Guido though, as with any post-beta1 feature addition). Once we're past beta 3 and heading for rc1 then the bar for approving feature additions to fix bugs will move even higher though. Right. Once b3 is out the bar will be *really* high. Once rc1 is out the bar will be raised even for bug fixes! So do this now. -- --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] [Python-3000] No beta2 tonight
On Thu, Jul 17, 2008 at 10:43 PM, Brett Cannon [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 7:37 PM, Guido van Rossum [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake [EMAIL PROTECTED] wrote: On Jul 17, 2008, at 7:27 PM, Martin v. Löwis wrote: bsddb is in a very bad shape, as the 2.6 code hasn't been merged into 3k. I somewhat doubt that this gets resolved before the release, so bsddb users might need to skip 3.0. In fact, bsddb as packages in core Python has rarely been in good shape. Has anyone actually considered that bsddb might do better if maintained strictly as an external package? That would make it easier for the any maintainers to release updates, and removes a source of frustration for users who either don't need it or would rather wait for a happier version. I think this is worth considering. I vaguely recall that the bsddb module was maintained before it was incorporated into the core Python release. +1. In my recollection maintaining bsddb has been nothing but trouble right from the start when we were all sitting together at Zope Corp North in a rented office in McLean... We can remove it from 3.0. We can't really remove it from 2.6, but we can certainly start end-of-lifing it in 2.6. Unless I hear otherwise, I will add it to PEP 3108. Please do! -- --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] [Python-3000] No beta2 tonight
On Fri, Jul 18, 2008 at 7:21 AM, Guido van Rossum [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 10:43 PM, Brett Cannon [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 7:37 PM, Guido van Rossum [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake [EMAIL PROTECTED] wrote: On Jul 17, 2008, at 7:27 PM, Martin v. Löwis wrote: bsddb is in a very bad shape, as the 2.6 code hasn't been merged into 3k. I somewhat doubt that this gets resolved before the release, so bsddb users might need to skip 3.0. In fact, bsddb as packages in core Python has rarely been in good shape. Has anyone actually considered that bsddb might do better if maintained strictly as an external package? That would make it easier for the any maintainers to release updates, and removes a source of frustration for users who either don't need it or would rather wait for a happier version. I think this is worth considering. I vaguely recall that the bsddb module was maintained before it was incorporated into the core Python release. +1. In my recollection maintaining bsddb has been nothing but trouble right from the start when we were all sitting together at Zope Corp North in a rented office in McLean... We can remove it from 3.0. We can't really remove it from 2.6, but we can certainly start end-of-lifing it in 2.6. Unless I hear otherwise, I will add it to PEP 3108. Please do! Invariably, when someone goes and removes a module, someone else is going to complain, but I used feature X, not having feature X will break my code. We, as maintainers can then say, if you cared, maintain it. But I'm not sure that is the greatest thing to tell people. I suspect that we may have to include some sort of work-alike for 2.7 and if not 3.0, 3.1 . If I were to vote for a work-alike, it would be based on sqlite. For one of the most common use-cases (bsddb.btree), simple sqlite code can be written to do the right thing. Recno is a little more tricky, but can also be done. The bsddb hash may not be possible, because sqlite doesn't support hashed indices :/. Just an idea. - Josiah ___ 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-3000] No beta2 tonight
On Fri, Jul 18, 2008 at 7:57 AM, Josiah Carlson [EMAIL PROTECTED] wrote: Invariably, when someone goes and removes a module, someone else is going to complain, but I used feature X, not having feature X will break my code. We, as maintainers can then say, if you cared, maintain it. But I'm not sure that is the greatest thing to tell people. I suspect that we may have to include some sort of work-alike for 2.7 and if not 3.0, 3.1 . If I were to vote for a work-alike, it would be based on sqlite. For one of the most common use-cases (bsddb.btree), simple sqlite code can be written to do the right thing. Recno is a little more tricky, but can also be done. The bsddb hash may not be possible, because sqlite doesn't support hashed indices :/. In my mind, BSDDB is pretty much the most heavy-weight extension we're maintaining. I think it's an illusion that a sqlite-based look-alike is going to fool anyone. The correct solution is to take support for bsddb to a separate project where those who care about it can maintain it together. That also makes it a lot easier to track the versions of Berkeley DB as they come out. Of course, you're free to try writing the work-alike you're proposing. :-) -- --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] Windows buildbot trick
On Fri, Jul 18, 2008 at 4:14 AM, Thomas Heller [EMAIL PROTECTED] wrote: The most annoying thing on the windows buildbots is when Python crashes hard (with a general protection fault or stack overflow, for example). Usually the system pops up a dialog in this case which allows to attach a debugger to the process. This dialog will stay open until the maintainer manually closes it, and will prevent the next builds. On my boxes I have inserted these two lines into the PythonXY/Scripts/buildbot script, right at the top: import win32api; win32api.SetErrorMode(7) print SetErrorMode(7) called. These lines prevent the dialog box to be displayed for critical errors. For example, on Windows AMD64 the test_cpickle test in the trunk currently fails with a stack overflow; instead of hanging with the mentioned dialog box open the test now terminates: http://www.python.org/dev/buildbot/trunk/amd64%20XP%20trunk/builds/40/step-test/0 That's a great trick! I seem to remember that there is a way to turn that off globally though, but not sure where. Maybe running drwtsn32.exe and un-checking 'Visual Notification' does the trick? -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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] Windows buildbot trick
On Fri, Jul 18, 2008 at 12:42 PM, Sidnei da Silva [EMAIL PROTECTED] wrote: That's a great trick! I seem to remember that there is a way to turn that off globally though, but not sure where. Maybe running drwtsn32.exe and un-checking 'Visual Notification' does the trick? FWIW, here's a kb article that describes this. Although it refers to 32-bit apps on 64-bit XP, I'm pretty sure you can do the same for 32-bit XP? http://support.microsoft.com/kb/283150/EN-US/ -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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 (07/11/08 - 07/18/08) 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. 1967 open (+38) / 13262 closed (+25) / 15229 total (+63) Open issues with patches: 619 Average duration of open issues: 705 days. Median duration of open issues: 1617 days. Open Issues Breakdown open 1939 (+38) pending28 ( +0) Issues Created Or Reopened (63) ___ IDLE - use enumerate instead of zip(count(), ...)07/11/08 http://bugs.python.org/issue3344created taleinat patch Patch for CGIHTTPServer.is_cgi function documentation07/11/08 CLOSED http://bugs.python.org/issue3345created tebeka patch test_ossaudiodev fails 07/12/08 http://bugs.python.org/issue3346created cartman urllib.robotparser doesn't work in Py3k 07/12/08 http://bugs.python.org/issue3347created mgiuca patch Cannot start wsgiref simple server in Py3k 07/12/08 http://bugs.python.org/issue3348created mgiuca patch search for 'patch' produces roundup error07/12/08 CLOSED http://bugs.python.org/issue3349created techtonik multiprocessing adds built-in types to the global copyreg.dispat 07/13/08 http://bugs.python.org/issue3350created alexandre.vassalotti Python crashed 07/14/08 CLOSED http://bugs.python.org/issue3351created yiyuan Deficiencies in multiprocessing/threading API07/14/08 http://bugs.python.org/issue3352created ncoghlan make built-in tokenizer available via Python C API 07/14/08 http://bugs.python.org/issue3353created effbot Improve error reporting for the argument parsing API 07/14/08 http://bugs.python.org/issue3354reopened benjamin.peterson Display bug in :show-inheritance: for class with standard docstr 07/14/08 http://bugs.python.org/issue3355created kumar303 some tests fail in debug mode (test_distutils, test_set) 07/14/08 http://bugs.python.org/issue3356created pitrou A bug in the __doc__ string of the sys module07/14/08 CLOSED http://bugs.python.org/issue3357created cheDu 2to3 Iterative Wildcard Matching 07/15/08 http://bugs.python.org/issue3358created nedds patch add 'rbU' mode to open() 07/15/08 CLOSED http://bugs.python.org/issue3359created techtonik Inconsistent type-deduction of decimal floating-point07/15/08 CLOSED http://bugs.python.org/issue3360created richyk pypi issue tracker link (python.org) 07/15/08 CLOSED http://bugs.python.org/issue3361created tds333 locale.getpreferredencoding() gives bus error on Mac OS X 10.4.1 07/15/08 http://bugs.python.org/issue3362created cfr python version incorrectly reported in crash
Re: [Python-Dev] Windows buildbot trick
Thomas Heller [EMAIL PROTECTED] writes: The most annoying thing on the windows buildbots is when Python crashes hard (with a general protection fault or stack overflow, for example). Usually the system pops up a dialog in this case which allows to attach a debugger to the process. This dialog will stay open until the maintainer manually closes it, and will prevent the next builds. On my boxes I have inserted these two lines into the PythonXY/Scripts/buildbot script, right at the top: import win32api; win32api.SetErrorMode(7) print SetErrorMode(7) called. These lines prevent the dialog box to be displayed for critical errors. For my buildbot, I've been running similarly modified buildbot code since late 2007 (in commands.py, surrounding the spawning of a process to execute a step) so it covers any use of the buildbot (mine was also building MSIs). I had to modify buildbot to fix a file upload bug anyway, so didn't mind running a patched version. Technically using 0x8007 rather than just 7 would also cover a possible missing file dialog, but not crucial. It hasn't been 100% foolproof, as I seem to recall once or twice still having to clear a dialog, but I think that was from the CRT within Python itself, which there was an old discussion about changing the Python code to initialize differently. It definitely catches the Windows hard failures though. -- David ___ 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] r65099 - python/trunk/Doc/library/string.rst
georg.brandl wrote:
Author: georg.brandl
Date: Fri Jul 18 13:15:06 2008
New Revision: 65099
Log:
Document the different meaning of precision for {:f} and {:g}.
Also document how inf and nan are formatted. #3404.
Thanks for doing this. But see this output:
http://www.python.org/dev/buildbot/all/sparc%20solaris10%20gcc%20trunk/builds/255/step-test/0
which shows that on Solaris with gcc it's 'NaN', not 'nan'. This is one
of the reasons I didn't get into documenting it. And on Windows, it's
even worse (no Windows box handy, sorry).
Do we want to document the actual behavior, or do we want to normalize
all platforms so that they all return 'nan' and 'inf'?
I'm still hoping to fix F formatting (issue 3382) on Windows, assuming
that it's acceptable to do that before the last beta. It mostly comes
down to deleting the tests, since I can't match on 'nan' and 'inf'.
There is some additional work mapping 'F' to 'f', and then uppercasing
the result, but that part is easy.
Eric.
___
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-3000] No beta2 tonight
On Fri, Jul 18, 2008 at 8:11 AM, Guido van Rossum [EMAIL PROTECTED] wrote: On Fri, Jul 18, 2008 at 7:57 AM, Josiah Carlson [EMAIL PROTECTED] wrote: Invariably, when someone goes and removes a module, someone else is going to complain, but I used feature X, not having feature X will break my code. We, as maintainers can then say, if you cared, maintain it. But I'm not sure that is the greatest thing to tell people. I suspect that we may have to include some sort of work-alike for 2.7 and if not 3.0, 3.1 . If I were to vote for a work-alike, it would be based on sqlite. For one of the most common use-cases (bsddb.btree), simple sqlite code can be written to do the right thing. Recno is a little more tricky, but can also be done. The bsddb hash may not be possible, because sqlite doesn't support hashed indices :/. In my mind, BSDDB is pretty much the most heavy-weight extension we're maintaining. I think it's an illusion that a sqlite-based look-alike is going to fool anyone. The correct solution is to take support for bsddb to a separate project where those who care about it can maintain it together. That also makes it a lot easier to track the versions of Berkeley DB as they come out. Of course, you're free to try writing the work-alike you're proposing. :-) It's entirely possible that I know very little about what was being made available via the bsddb module, but to match the API of what is included in the documentation (plus the dictionary interface that it supports) shouldn't be terribly difficult. Now, if there were *other* things that were undocumented, well, there's not much I can do about those. ;) - Josiah ___ 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-3000] No beta2 tonight
On Jul 18, 2008, at 1:45 PM, Josiah Carlson wrote: It's entirely possible that I know very little about what was being made available via the bsddb module, but to match the API of what is included in the documentation (plus the dictionary interface that it supports) shouldn't be terribly difficult. It's also entirely possible that the API isn't interesting if you don't support existing databases, for many applications. -Fred -- Fred Drake fdrake at 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-3000] No beta2 tonight
On Fri, Jul 18, 2008 at 7:21 AM, Guido van Rossum [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 10:43 PM, Brett Cannon [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 7:37 PM, Guido van Rossum [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake [EMAIL PROTECTED] wrote: On Jul 17, 2008, at 7:27 PM, Martin v. Löwis wrote: bsddb is in a very bad shape, as the 2.6 code hasn't been merged into 3k. I somewhat doubt that this gets resolved before the release, so bsddb users might need to skip 3.0. In fact, bsddb as packages in core Python has rarely been in good shape. Has anyone actually considered that bsddb might do better if maintained strictly as an external package? That would make it easier for the any maintainers to release updates, and removes a source of frustration for users who either don't need it or would rather wait for a happier version. I think this is worth considering. I vaguely recall that the bsddb module was maintained before it was incorporated into the core Python release. +1. In my recollection maintaining bsddb has been nothing but trouble right from the start when we were all sitting together at Zope Corp North in a rented office in McLean... We can remove it from 3.0. We can't really remove it from 2.6, but we can certainly start end-of-lifing it in 2.6. Unless I hear otherwise, I will add it to PEP 3108. Please do! Done. -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] [Python-3000] No beta2 tonight
Fred Drake wrote: On Jul 18, 2008, at 1:45 PM, Josiah Carlson wrote: It's entirely possible that I know very little about what was being made available via the bsddb module, but to match the API of what is included in the documentation (plus the dictionary interface that it supports) shouldn't be terribly difficult. It's also entirely possible that the API isn't interesting if you don't support existing databases, for many applications. And downloading pybsddb and installing really shouldn't be all that difficult :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] git repositories for trunk and py3k
On Fri, Jul 18, 2008 at 11:12 AM, Brett Cannon [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 11:54 PM, Neil Schemenauer [EMAIL PROTECTED] wrote: [back on the list] On Thu, Jul 17, 2008 at 11:24:16PM -0700, Brett Cannon wrote: Turned out to be a rebuild:: r65077 = 82d954e8c20c91562c4c660859d17756cba10992 r65082 = 1c75cce93c2ef2ec87e801888638cfdf5d2ff29a r65085 = 3143c2fbe7315afd29496dc0cdac3122bed30536 Done rebuilding .git/svn/git-svn/.rev_map.6015fed2-1504-0410-9fe1-9d1591cc4771 How do I know what is going to be sent? ``git log`` seems to suggest something by not listing a git-svn-id for my last commit, but is that really the best I got? The command git log git-svn.. And those two periods are significant for people who think they are line noise. Damn is Git quirky. OK, so I decided to trying committing through Git by doing ``git svn dcommit``. But it told me that Misc/NEWS was out of date. So I then did ``git fetch git-svn`` with a ``git merge git-svn``, which I realize now is a mistake since I am used to other DVCSs using merge for when there are changes and update when there are none. So Git tells me there is a conflict; fine. I go in, fix the file, and then try to commit Misc/NEWS. It says I can't do a partial commit, I have to commit everything; fine. So I do a full commit, but now I get: Misc/NEWS: needs merge Misc/NEWS: unmerged (3dc56ad4e5918676358c4e20be738b37ce8d50d0) Misc/NEWS: unmerged (ad4c19cecfb584be37d8b9c138791daa83ad9285) Misc/NEWS: unmerged (853df55fc6ac71bcea0eb340a8ab52b348db9e8c) error: Error building trees This is not winning me over on the usability side of things. =) So what do I do now to get this tree back in a usable state so I can commit (although, thanks to ``git show``, I might patch a svn checkout so I don't have to wait on this)? -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] git repositories for trunk and py3k
On Fri, Jul 18, 2008 at 11:12:41AM -0700, Brett Cannon wrote: And those two periods are significant for people who think they are line noise. Damn is Git quirky. Oh my, yes. We use git at work; there's a reason I now use Bazaar for personal projects. I assume the ^ operator means just before this commit. Correct; HEAD^^ is two commits ago, and you can do HEAD~35 for 35 commits ago. There's a git-rev-parse man page describing these. Does the abbreviation have to be exactly six characters? No, it has to be long enough to be unambiguous. 6cadb9c1b7 would also work, and 6cadb might, depending on the other commits in your repository. I tried that, but but format-patch didn't show me anything since I had just committed. And when I run ``git format-patch HEAD^`` it spits out what looks like a file name, but I don't see it anywhere. I think it writes the file to the current working directory, so I don't know why you're not seeing it. (The file is something like 0001-commit-message.patch.) --amk ___ 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] git repositories for trunk and py3k
On Fri, Jul 18, 2008 at 11:37 AM, Brett Cannon [EMAIL PROTECTED] wrote: On Fri, Jul 18, 2008 at 11:12 AM, Brett Cannon [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 11:54 PM, Neil Schemenauer [EMAIL PROTECTED] wrote: [back on the list] On Thu, Jul 17, 2008 at 11:24:16PM -0700, Brett Cannon wrote: Turned out to be a rebuild:: r65077 = 82d954e8c20c91562c4c660859d17756cba10992 r65082 = 1c75cce93c2ef2ec87e801888638cfdf5d2ff29a r65085 = 3143c2fbe7315afd29496dc0cdac3122bed30536 Done rebuilding .git/svn/git-svn/.rev_map.6015fed2-1504-0410-9fe1-9d1591cc4771 How do I know what is going to be sent? ``git log`` seems to suggest something by not listing a git-svn-id for my last commit, but is that really the best I got? The command git log git-svn.. And those two periods are significant for people who think they are line noise. Damn is Git quirky. OK, so I decided to trying committing through Git by doing ``git svn dcommit``. But it told me that Misc/NEWS was out of date. So I then did ``git fetch git-svn`` with a ``git merge git-svn``, which I realize now is a mistake since I am used to other DVCSs using merge for when there are changes and update when there are none. So Git tells me there is a conflict; fine. I go in, fix the file, and then try to commit Misc/NEWS. It says I can't do a partial commit, I have to commit everything; fine. So I do a full commit, but now I get: Misc/NEWS: needs merge Misc/NEWS: unmerged (3dc56ad4e5918676358c4e20be738b37ce8d50d0) Misc/NEWS: unmerged (ad4c19cecfb584be37d8b9c138791daa83ad9285) Misc/NEWS: unmerged (853df55fc6ac71bcea0eb340a8ab52b348db9e8c) error: Error building trees This is not winning me over on the usability side of things. =) So what do I do now to get this tree back in a usable state so I can commit (although, thanks to ``git show``, I might patch a svn checkout so I don't have to wait on this)? I figured this out. I just did ``git reset --hard``, did the proper fetch;rebase dance, resolved the conflict, did ``git add`` and then continued with the rebase. It all looks fine now. -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] git repositories for trunk and py3k
On Fri, Jul 18, 2008 at 11:12:41AM -0700, Brett Cannon wrote: git log git-svn.. And those two periods are significant for people who think they are line noise. Damn is Git quirky. I guess it would have been clearer if I had used git-svn..HEAD. The .. is similar to SVN's : so I don't see that as much of a quirk. However, if you look at the git-rev-parse man page you will see that git supports a very rich set of revision specifications and that can be overwhelming to a new user. You can probably mostly get by with rev and rev1..rev2 combined with ^. Sure, but I don't know what the heck I am looking at. The top left window shows a DAG of the commits. Each commit is a little ball. Parents are connected with a colored line. Tags and heads are shown as labels on specific commits. You can click on any commit to see the details (shown in the lower panels). I assume the ^ operator means just before this commit. Yes and you can use it more than once (e.g. ^^^). This is all documented in the git-rev-parse man page. Does the abbreviation have to be exactly six characters? No. I tried that, but but format-patch didn't show me anything since I had just committed. And when I run ``git format-patch HEAD^`` it spits out what looks like a file name, but I don't see it anywhere. By default it creates a file for each commit, prefixed by 0001, 0002, etc. Use git format-patch --stdout to have it spit the patches out as a mbox to stdout. ___ 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] git repositories for trunk and py3k
On Fri, Jul 18, 2008 at 11:57 AM, Brett Cannon [EMAIL PROTECTED] wrote: On Fri, Jul 18, 2008 at 11:37 AM, Brett Cannon [EMAIL PROTECTED] wrote: On Fri, Jul 18, 2008 at 11:12 AM, Brett Cannon [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 11:54 PM, Neil Schemenauer [EMAIL PROTECTED] wrote: [back on the list] On Thu, Jul 17, 2008 at 11:24:16PM -0700, Brett Cannon wrote: Turned out to be a rebuild:: r65077 = 82d954e8c20c91562c4c660859d17756cba10992 r65082 = 1c75cce93c2ef2ec87e801888638cfdf5d2ff29a r65085 = 3143c2fbe7315afd29496dc0cdac3122bed30536 Done rebuilding .git/svn/git-svn/.rev_map.6015fed2-1504-0410-9fe1-9d1591cc4771 How do I know what is going to be sent? ``git log`` seems to suggest something by not listing a git-svn-id for my last commit, but is that really the best I got? The command git log git-svn.. And those two periods are significant for people who think they are line noise. Damn is Git quirky. OK, so I decided to trying committing through Git by doing ``git svn dcommit``. But it told me that Misc/NEWS was out of date. So I then did ``git fetch git-svn`` with a ``git merge git-svn``, which I realize now is a mistake since I am used to other DVCSs using merge for when there are changes and update when there are none. So Git tells me there is a conflict; fine. I go in, fix the file, and then try to commit Misc/NEWS. It says I can't do a partial commit, I have to commit everything; fine. So I do a full commit, but now I get: Misc/NEWS: needs merge Misc/NEWS: unmerged (3dc56ad4e5918676358c4e20be738b37ce8d50d0) Misc/NEWS: unmerged (ad4c19cecfb584be37d8b9c138791daa83ad9285) Misc/NEWS: unmerged (853df55fc6ac71bcea0eb340a8ab52b348db9e8c) error: Error building trees This is not winning me over on the usability side of things. =) So what do I do now to get this tree back in a usable state so I can commit (although, thanks to ``git show``, I might patch a svn checkout so I don't have to wait on this)? I figured this out. I just did ``git reset --hard``, did the proper fetch;rebase dance, resolved the conflict, did ``git add`` and then continued with the rebase. It all looks fine now. I lied. Trying again complained about Mac/IDLE/Makefile.in which I have not touched, nor is it listed as changed. OK, so I deleted it in hopes that fetch; rebase would fix it; nope. So I did another ``git reset --hard``, but I am still stuck with being told that Mac/IDLE/Makefile.in is out of date:: Committing to svn+ssh://svn.python.org/python/trunk ... M Mac/IDLE/Makefile.in Transaction is out of date: Out of date: '/python/trunk/Mac/IDLE/Makefile.in' in transaction '65108-1' at /unix/bin/git-svn line 461 So I don't know how to deal with this since Git does not even list the file as being modified. -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] [Python-3000] No beta2 tonight
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 18, 2008, at 2:32 PM, A.M. Kuchling wrote: We can obviously drop the module for 3.0. For 2.x, should we just shrug and disable most of the BerkeleyDB tests (maybe just on Windows) by adding a new resource to enable them? If we're stuck with it for the remaining 2.x, at least we can stop the buildbots from going red for bugs that we can't debug and probably won't fix. +1 - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSIDsxXEjvBPtnXfVAQJ6egP+O0HQPj9X7te1X3CbPBRN8RhadJucaDmF 13a5bf13D/5D+gQ4iKlYMovd9l66J6lpFpSX+cHLgU3g/BZvFUXJFl4gZegWyD2p idQvGVFUrjGDL5TFIL4Dvg5D/b8pYSPfr5xWgJNSPHMeM5sEM6hDt/WhuvYSzuv+ lMROoc5c0NI= =isdz -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-3000] No beta2 tonight
Nick Coghlan writes: And downloading pybsddb and installing really shouldn't be all that difficult :) It shouldn't be, but lots of enterprise[1] environments will require qualifying the new package according to corporate standards. I won't argue that this is a sufficient reason to keep a package with bsddb's history in stdlib, but let's not joke about the difficulties. Footnotes: [1] Which apparently means that the company can be enterprising, but the people who do the work mustn't be! ___ 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] git repositories for trunk and py3k
On Fri, Jul 18, 2008 at 11:57:21AM -0700, Brett Cannon wrote: I figured this out. I just did ``git reset --hard``, did the proper fetch;rebase dance, resolved the conflict, did ``git add`` and then continued with the rebase. It all looks fine now. Doing a fetch followed by a rebase is similar to what svn up does and is what you want in this case. Rebase rewrites patches (commits) so that they apply to a different version of a tree (they will get new SHA ids). If you use merge then your patches (commits) stay unchanged and a new commit object is created that contains the info required to integrate them with the new tree. Using merge is also useful in certain cases (e.g. in a distributed environment, if you have published your changes already and people have them in their repositories) but the downside is the extra merge commit object. However, since in this specific case you are always pushing back to a central repo you should avoid merge. BTW, the rebase command is very handy if you are maintaing some change over a longer term. Here's an example workflow: start with git checkout git checkout -b my_feature # create a private branch edit code, commit changes git checkout master # back to main branch time passes git fetch git-svn git rebase git-svn # update master to latest code git checkout my_feature # back to private branch git rebase master # make my changes apply to latest code To generate a series of patches to send somewhere: git format-patch --stdout master..my_feature my_feature.txt Cheers, Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] git repositories for trunk and py3k
On Fri, Jul 18, 2008 at 12:31 PM, Neil Schemenauer [EMAIL PROTECTED] wrote: On Fri, Jul 18, 2008 at 11:57:21AM -0700, Brett Cannon wrote: I figured this out. I just did ``git reset --hard``, did the proper fetch;rebase dance, resolved the conflict, did ``git add`` and then continued with the rebase. It all looks fine now. Doing a fetch followed by a rebase is similar to what svn up does and is what you want in this case. Rebase rewrites patches (commits) so that they apply to a different version of a tree (they will get new SHA ids). If you use merge then your patches (commits) stay unchanged and a new commit object is created that contains the info required to integrate them with the new tree. Using merge is also useful in certain cases (e.g. in a distributed environment, if you have published your changes already and people have them in their repositories) but the downside is the extra merge commit object. However, since in this specific case you are always pushing back to a central repo you should avoid merge. BTW, the rebase command is very handy if you are maintaing some change over a longer term. Here's an example workflow: start with git checkout git checkout -b my_feature # create a private branch edit code, commit changes git checkout master # back to main branch time passes git fetch git-svn git rebase git-svn # update master to latest code git checkout my_feature # back to private branch git rebase master # make my changes apply to latest code That's what I have been doing, except using merge in the master branch. To generate a series of patches to send somewhere: git format-patch --stdout master..my_feature my_feature.txt OK, so that's how you use format-patch. -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] git repositories for trunk and py3k
On Fri, Jul 18, 2008 at 12:07:19PM -0700, Brett Cannon wrote: I lied. Trying again complained about Mac/IDLE/Makefile.in which I have not touched, nor is it listed as changed. I think you are running into the fact that the git tree on code.python.org is only updated every 30 minutes. Using the git:// protocol is fast but can't get changes that are in SVN and not yet in the git tree. If your repo is fairly up-to-date, you can just use git svn rebase. That will grab the latest changes from the SVN server and rebase your local changes, very similar to what svn up does. BTW, I'm on #python-dev at the moment if you run into more trouble. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] No beta2 tonight
On Friday 18 July 2008 07:57:01 am Josiah Carlson wrote: On Fri, Jul 18, 2008 at 7:21 AM, Guido van Rossum [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 10:43 PM, Brett Cannon [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 7:37 PM, Guido van Rossum [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake [EMAIL PROTECTED] wrote: On Jul 17, 2008, at 7:27 PM, Martin v. Löwis wrote: bsddb is in a very bad shape, as the 2.6 code hasn't been merged into 3k. I somewhat doubt that this gets resolved before the release, so bsddb users might need to skip 3.0. In fact, bsddb as packages in core Python has rarely been in good shape. Has anyone actually considered that bsddb might do better if maintained strictly as an external package? That would make it easier for the any maintainers to release updates, and removes a source of frustration for users who either don't need it or would rather wait for a happier version. I think this is worth considering. I vaguely recall that the bsddb module was maintained before it was incorporated into the core Python release. +1. In my recollection maintaining bsddb has been nothing but trouble right from the start when we were all sitting together at Zope Corp North in a rented office in McLean... We can remove it from 3.0. We can't really remove it from 2.6, but we can certainly start end-of-lifing it in 2.6. Unless I hear otherwise, I will add it to PEP 3108. Please do! Invariably, when someone goes and removes a module, someone else is going to complain, but I used feature X, not having feature X will break my code. We, as maintainers can then say, if you cared, maintain it. But I'm not sure that is the greatest thing to tell people. I suspect that we may have to include some sort of work-alike for 2.7 and if not 3.0, 3.1 . If I were to vote for a work-alike, it would be based on sqlite. For one of the most common use-cases (bsddb.btree), simple sqlite code can be written to do the right thing. Recno is a little more tricky, but can also be done. The bsddb hash may not be possible, because sqlite doesn't support hashed indices :/. Just an idea. - Josiah ___ 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/charleshixsn%40earthlink. net Were I to vote for something it would be a B+Tree in collections. One that didn't impose a requirement that the key be a string (and not, e.g., an integer or a float). OTOH, I don't care enough to build it. (I've proven this to myself repeatedly, as I've started to create such a thing, and then kludged a different solution.) ___ 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] git repositories for trunk and py3k
On Fri, Jul 18, 2008 at 12:35 PM, Neil Schemenauer [EMAIL PROTECTED] wrote: On Fri, Jul 18, 2008 at 12:07:19PM -0700, Brett Cannon wrote: I lied. Trying again complained about Mac/IDLE/Makefile.in which I have not touched, nor is it listed as changed. I think you are running into the fact that the git tree on code.python.org is only updated every 30 minutes. Using the git:// protocol is fast but can't get changes that are in SVN and not yet in the git tree. If your repo is fairly up-to-date, you can just use git svn rebase. That will grab the latest changes from the SVN server and rebase your local changes, very similar to what svn up does. Did that, still complained. BTW, I'm on #python-dev at the moment if you run into more trouble. If I get daring again I will try you in the IRC channel, but I just gave up and used a patch against svn so the change could get committed. -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] [Python-checkins] r65099 - python/trunk/Doc/library/string.rst
Eric Smith schrieb:
georg.brandl wrote:
Author: georg.brandl
Date: Fri Jul 18 13:15:06 2008
New Revision: 65099
Log:
Document the different meaning of precision for {:f} and {:g}.
Also document how inf and nan are formatted. #3404.
Thanks for doing this. But see this output:
http://www.python.org/dev/buildbot/all/sparc%20solaris10%20gcc%20trunk/builds/255/step-test/0
which shows that on Solaris with gcc it's 'NaN', not 'nan'. This is one
of the reasons I didn't get into documenting it. And on Windows, it's
even worse (no Windows box handy, sorry).
I see.
Do we want to document the actual behavior, or do we want to normalize
all platforms so that they all return 'nan' and 'inf'?
I'd find a consistent behavior nice, if it isn't too much work to
get one.
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.
___
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] git repositories for trunk and py3k
Why is it you're trying to use git? Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows buildbot trick
Sidnei da Silva schrieb: On Fri, Jul 18, 2008 at 12:42 PM, Sidnei da Silva [EMAIL PROTECTED] wrote: That's a great trick! I seem to remember that there is a way to turn that off globally though, but not sure where. Maybe running drwtsn32.exe and un-checking 'Visual Notification' does the trick? FWIW, here's a kb article that describes this. Although it refers to 32-bit apps on 64-bit XP, I'm pretty sure you can do the same for 32-bit XP? http://support.microsoft.com/kb/283150/EN-US/ Well, generally it is a good idea on a developer machine to automatically start the debugger when a problem in the tested application happens, so I prefer to not change this setting globally. However, some time ago I have tried to turn the notifications off in every way I could find but did not succeed. Although I'm not sure I found the article you mentioned. -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r65099 - python/trunk/Doc/library/string.rst
On Fri, Jul 18, 2008 at 6:10 PM, Eric Smith [EMAIL PROTECTED] wrote: Do we want to document the actual behavior, or do we want to normalize all platforms so that they all return 'nan' and 'inf'? I seem to recall that Christian Heimes recently put some work into making sure that repr() or str() of an infinity or nan is 'inf' or 'nan' (or '-inf'), regardless of platform. +1 for normalizing '%f' and '%F' behaviour across platforms. 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
Re: [Python-Dev] [Python-3000] No beta2 tonight
On 2008-07-18 21:35, Charles Hixson wrote: Invariably, when someone goes and removes a module, someone else is going to complain, but I used feature X, not having feature X will break my code. We, as maintainers can then say, if you cared, maintain it. But I'm not sure that is the greatest thing to tell people. I suspect that we may have to include some sort of work-alike for 2.7 and if not 3.0, 3.1 . If I were to vote for a work-alike, it would be based on sqlite. For one of the most common use-cases (bsddb.btree), simple sqlite code can be written to do the right thing. Recno is a little more tricky, but can also be done. The bsddb hash may not be possible, because sqlite doesn't support hashed indices :/. Just an idea. - Josiah Were I to vote for something it would be a B+Tree in collections. One that didn't impose a requirement that the key be a string (and not, e.g., an integer or a float). OTOH, I don't care enough to build it. (I've proven this to myself repeatedly, as I've started to create such a thing, and then kludged a different solution.) If pybsddb is sufficient as work-around for the stdlib bsddb module (or perhaps even better), then I don't see much of a problem removing the module from the stdlib using a PEP 4 process. Can't really say, since I've never used any of these myself... for on-disk dictionaries, we use mxBeeBase: http://www.egenix.com/products/python/mxBase/mxBeeBase/ For anything more complex, a SQL database. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 18 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX 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 ___ 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] git repositories for trunk and py3k
On Fri, Jul 18, 2008 at 12:54 PM, Bill Janssen [EMAIL PROTECTED] wrote: Why is it you're trying to use git? Neil set up a mirror and I was curious. Same with the bzr mirror. -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] Implementing restricted Python in Zope2
ranjith kannikara wrote: As a student I am not familiar with Restricted Python and python AST implementation.And in need of help to start the Restricted Python implementation. Here is some context for Python-Dev. RestrictedPython is a custom Python compiler that, when combined with a restricted environment, provides a sandbox safe enough to allow partly-trusted people to write and execute scripts on a Zope server. It has been used in Zope 2 for a long time and will have a future in Zope 3. The sandbox is more extensive than what the rexec module provides. The safety of RestrictedPython has been validated in a somewhat formal process with Python 2.4. Ranjith is working to validate it with Python 2.5. He is first working to discover all changes between Python 2.4 and 2.5 that might have affected the safety of a RestrictedPython sandbox. Any changes to the AST, builtin functions, methods of builtin types, etc., need to be evaluated for safety. So, in general, he is looking for detailed lists of changes between Python 2.4 and 2.5--more than the What's New doc. Shane ___ 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] Test, please ignore
... ___ 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] Implementing restricted Python in Zope2
On Thu, Jul 17, 2008 at 11:42 AM, Shane Hathaway [EMAIL PROTECTED] wrote: ranjith kannikara wrote: As a student I am not familiar with Restricted Python and python AST implementation.And in need of help to start the Restricted Python implementation. Here is some context for Python-Dev. RestrictedPython is a custom Python compiler that, when combined with a restricted environment, provides a sandbox safe enough to allow partly-trusted people to write and execute scripts on a Zope server. It has been used in Zope 2 for a long time and will have a future in Zope 3. The sandbox is more extensive than what the rexec module provides. The safety of RestrictedPython has been validated in a somewhat formal process with Python 2.4. Ranjith is working to validate it with Python 2.5. He is first working to discover all changes between Python 2.4 and 2.5 that might have affected the safety of a RestrictedPython sandbox. Any changes to the AST, builtin functions, methods of builtin types, etc., need to be evaluated for safety. So, in general, he is looking for detailed lists of changes between Python 2.4 and 2.5--more than the What's New doc. As it has been said, his best chance is to either diff between versions or look at the log output from svn on the files he cares about. -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] No beta2 tonight
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin v. Löwis wrote: | bsddb is in a very bad shape, as the 2.6 code hasn't been merged into | 3k. I somewhat doubt that this gets resolved before the release, so | bsddb users might need to skip 3.0. Working on the 3.0 port just now. 03:40 in the morning, in Spain. bsddb will be ready for python 3.0. (writting this while compiling new 2.6 and 3.0 beta2 :-) ) - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSIFGTJlgi5GaxT1NAQKTBAP/f2AiHwEmMCSE6xhYVKj/0Rkh3A9/7XWG f8CrJ8Dn//QoG7+FZ63mF1BoT9aJ3RGUIrkIePe7+XJUpa8Fq264sQMoz94Estkc KyzSN69j+O9fTBGdI3PByFuCkfrrcl3+i0sEg0WQylOzzTpEfwKcRT5hGG2qb8c1 RZKV8BxQVXA= =4fO2 -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-3000] No beta2 tonight
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brett Cannon wrote: | On Thu, Jul 17, 2008 at 7:37 PM, Guido van Rossum [EMAIL PROTECTED] wrote: | On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake [EMAIL PROTECTED] wrote: | On Jul 17, 2008, at 7:27 PM, Martin v. Löwis wrote: | bsddb is in a very bad shape, as the 2.6 code hasn't been merged into | 3k. I somewhat doubt that this gets resolved before the release, so | bsddb users might need to skip 3.0. | | In fact, bsddb as packages in core Python has rarely been in good shape. | | Has anyone actually considered that bsddb might do better if maintained | strictly as an external package? That would make it easier for the any | maintainers to release updates, and removes a source of frustration for | users who either don't need it or would rather wait for a happier version. | | I think this is worth considering. I vaguely recall that the bsddb module | was maintained before it was incorporated into the core Python release. | +1. In my recollection maintaining bsddb has been nothing but trouble | right from the start when we were all sitting together at Zope Corp | North in a rented office in McLean... We can remove it from 3.0. We | can't really remove it from 2.6, but we can certainly start | end-of-lifing it in 2.6. | | | Unless I hear otherwise, I will add it to PEP 3108. 03:31 AM in the morning in Spain. Just working in porting bsddb to python3000. I have a lot of issues compiling the C code and with the 2to3 automated conversion, but I'm pretty sure can get it ready for october release. I'm still loooking for a *GOOD* python2-python3 conversion guide for C language modules. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSIFFFJlgi5GaxT1NAQLHlQP/cXmobkxlEs5gL9MRVNOAhcCtmATJqkQd lpAkzExa+75cQSoP28iIa+GhxRuJJCAz9NxAw22VIkwab/93R1eFYVjdC9jqYprK gwZsZDHKs12RlRRHFk0562ZDMgtdFB4Ne9iJXsFOKNz6ZvOhMFHfoj/blZyyocsq zdS6SoxTtXM= =aIrU -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] Any PEP about 2.6 - 3000 code transition?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: | On Sun, May 25, 2008 at 6:25 AM, Jesus Cea [EMAIL PROTECTED] wrote: | Since I need to port bsddb3 to py3k, what I need to know?. Is any | *updated* document out there?. | | No, but there is a not yet complete, but quite updated set of examples. | | http://code.google.com/p/python-incompatibility/ | | This is a collection of code snippets that will show code that does | work under 2.x but not under 3.x, and the 3.x way of doing it (as well | as a way that works under both 2.6 and 3.0, in applicable cases). | | There is no tests for changes in the C-API, if you (or somebody else) | would like to add that (or any other tests) that would be very | appreciated! I can't checkout the code. What username/password must I use?. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSIFQnZlgi5GaxT1NAQL3LQP/ZxblxpJwZAQ9qIUXHAZpFlmK86y7UPfT DX707wR1YMOujiNazE2NuJSVCVkbbOlc1G2dxTAqDm7FAThkjuIeO74ijueUeFdN p6LP2dS5pHH8h8G9bUfDynGCjRQ4t1TUblksQgPDtrYiXlzIBqYL1qkHRf72w2c3 fyuZWBpaH0w= =nnN4 -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-3000] No beta2 tonight
Josiah Carlson wrote: It's entirely possible that I know very little about what was being made available via the bsddb module, but to match the API of what is included in the documentation (plus the dictionary interface that it supports) shouldn't be terribly difficult. Maybe for new databases, but what about people with existing bsddb files that they need to read? -- Greg ___ 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] Change in repr of Decimal in 2.6
[Originally posted to python-list but on further reflection and some
feedback I think it might be more appropriate here.]
I noticed when trying out Python's 2.6b2 release that the repr of Decimal
has changed since 2.5. On 2.5:
Python 2.5.1 (r251:54863, Mar 7 2008, 04:10:12)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type help, copyright, credits or license for more information.
import decimal
decimal.Decimal(7)
Decimal(7)
double quotes were used whereas on 2.6b2:
Python 2.6b2 (r26b2:65082, Jul 18 2008, 13:36:54)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type help, copyright, credits or license for more information.
import decimal
decimal.Decimal(7)
Decimal('7')
single quotes are used. Searching around I see this was done in r60773 with
the log message:
Fix decimal repr which should have used single quotes like other reprs.
but I can't find any discussion other than that.
My problem is this breaks a bunch of doctests that were written assuming the
prior repr. I can't just update the tests to assume the new single quotes
because they are for code that is supposed to run on everything back to
Python 2.3.
So my questions:
Is this backwards-incompatible change really necessary and could it be
reconsidered?
If it's here to stay, is there some straightforward way that I am unaware of
to construct tests that use Decimal repr but will work correctly on Python
2.3-2.6?
Thanks for any feedback,
Karen
___
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] Change in repr of Decimal in 2.6
From: Karen Tracey
I noticed when trying out Python's 2.6b2 release that the repr of Decimal has
changed since 2.5. On 2.5:
...
quotes were used whereas on 2.6b2:
...
single quotes are used. Searching around I see this was done in r60773 with
the log message:
Fix decimal repr which should have used single quotes like other reprs.
but I can't find any discussion other than that.
Guido requested this change so that the Decimal repr would match the style used
elsewhere (i.e. str(7) -- '7').
If it's here to stay, is there some straightforward way that I am unaware
of to construct tests that use Decimal repr but will work correctly on
Python 2.3-2.6?
A quick hack is to monkey patch the decimal module:
import decimal
decimal.Decimal.__repr__ = lambda s: 'Decimal(%s)' % str(s)
A better fix is to amend to doctests to not rely on the __repr__ format.
Instead of:
Decimal('7.1')
Decimal(7.1)
use:
print Decimal('7.1')
7.1
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python%40rcn.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change in repr of Decimal in 2.6
This is an example of the problem with doctest -- it's easy to
overspecify the tests. I don't think that whether the repr() of a
Decimal uses single or double quotes should be considered a spec cast
in stone by doctests.
On Fri, Jul 18, 2008 at 8:19 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
From: Karen Tracey
I noticed when trying out Python's 2.6b2 release that the repr of Decimal
has changed since 2.5. On 2.5:
...
quotes were used whereas on 2.6b2:
...
single quotes are used. Searching around I see this was done in r60773
with the log message:
Fix decimal repr which should have used single quotes like other reprs.
but I can't find any discussion other than that.
Guido requested this change so that the Decimal repr would match the style
used elsewhere (i.e. str(7) -- '7').
If it's here to stay, is there some straightforward way that I am unaware
of to construct tests that use Decimal repr but will work correctly on
Python 2.3-2.6?
A quick hack is to monkey patch the decimal module:
import decimal
decimal.Decimal.__repr__ = lambda s: 'Decimal(%s)' % str(s)
A better fix is to amend to doctests to not rely on the __repr__ format.
Instead of:
Decimal('7.1')
Decimal(7.1)
use:
print Decimal('7.1')
7.1
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/python%40rcn.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: Change in repr of Decimal in 2.6
Meant to copy list on reply, sorry.
-- Forwarded message --
From: Karen Tracey [EMAIL PROTECTED]
Date: Fri, Jul 18, 2008 at 11:48 PM
Subject: Re: [Python-Dev] Change in repr of Decimal in 2.6
To: Raymond Hettinger [EMAIL PROTECTED]
On Fri, Jul 18, 2008 at 11:19 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
From: Karen Tracey
I noticed when trying out Python's 2.6b2 release that the repr of Decimal
has changed since 2.5. On 2.5:
...
quotes were used whereas on 2.6b2:
...
single quotes are used. Searching around I see this was done in r60773
with the log message:
Fix decimal repr which should have used single quotes like other reprs.
but I can't find any discussion other than that.
Guido requested this change so that the Decimal repr would match the style
used elsewhere (i.e. str(7) -- '7').
Thanks for the background. Can't say I ever noticed the inconsistency
myself.
If it's here to stay, is there some straightforward way that I am unaware
of to construct tests that use Decimal repr but will work correctly on
Python 2.3-2.6?
A quick hack is to monkey patch the decimal module:
import decimal
decimal.Decimal.__repr__ = lambda s: 'Decimal(%s)' % str(s)
That is quick, but does seem hackish.
A better fix is to amend to doctests to not rely on the __repr__ format.
Instead of:
Decimal('7.1')
Decimal(7.1)
use:
print Decimal('7.1')
7.1
Yeah, but the testcases are not quite that simple. They're often testing
return values from functions and as much verifying that the type is correct
as the value, so I think I'd have to change stuff like:
f.clean('1')
Decimal(1)
to:
x = f.clean('1')
print type(x), x
class 'decimal.Decimal' 1
right?
Thanks for the answer,
Karen
___
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] Issue 3008: Binary repr of floats
The new float.hex() is really nice. Would like to augment it with a matching float.bin() method using the same notation and
normalization and leaving all the rightmost bits as Guido suggested. I think this would help demystify floats and make it
straightforward to show exactly what is happening during a floating point calculation that is losing precision.
def float_as_bin(x):
'3.125 -- -0b1.1101p+1'
hex2bin = {'0' : '', '1' : '0001', '2' : '0010', '3' : '0011',
'4' : '0100', '5' : '0101', '6' : '0110', '7' : '0111',
'8' : '1000', '9' : '1001', 'a' : '1010', 'b' : '1011',
'c' : '1100', 'd' : '1101', 'e' : '1110', 'f' : ''}
hex_pattern = '(\-)?0x([0-9a-f]+)\.([0-9a-f]*)(.*)'
sign, intpart, fracpart, exp = re.search(hex_pattern,
x.hex().lower()).groups()
return ((sign or '') + '0b' + intpart + '.' +
''.join(hex2bin[d] for d in fracpart)[:53] + exp)
The implementation would re-use Mark's code, substituting binary output for hex
in the fractional part.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change in repr of Decimal in 2.6
On Fri, Jul 18, 2008 at 11:55 PM, Guido van Rossum [EMAIL PROTECTED] wrote: This is an example of the problem with doctest -- it's easy to overspecify the tests. I don't think that whether the repr() of a Decimal uses single or double quotes should be considered a spec cast in stone by doctests. OK, but I'm just thinking of all the places in tests we have stuff like: var.method(params) expected_repr_of_return_value We should really be doing something else to guard against a potential future change in repr of whatever it is? Thanks, Karen ___ 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
