Re: [Python-Dev] [Python-checkins] cpython: Issue #10639: reindent.py tool now accepts a --newline option to specify the
On Tue, Jul 26, 2011 at 18:59, jason.coombs python-check...@python.orgwrote: http://hg.python.org/cpython/rev/4feb889d3bed changeset: 71506:4feb889d3bed user:Jason R. Coombs jar...@jaraco.com date:Tue Jul 26 11:38:04 2011 -0400 summary: Issue #10639: reindent.py tool now accepts a --newline option to specify the newline to be used in the output of converted files. Jason, this breaks make patchcheck. Please see my comment on the issue. Eli ___ 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] Convention on functions that shadow existing stdlib functions
On Fri, Jul 29, 2011 at 08:48, Nick Coghlan ncogh...@gmail.com wrote: On Fri, Jul 29, 2011 at 3:24 PM, Eli Bendersky eli...@gmail.com wrote: I propose to just move 3K's docs to the devguide, and make both doc pages (in 3K and 2.7) point to it. Is this acceptable? Yeah, just include a note in the devguide version saying that anything added in 3.2 or later may not be available when writing tests for the 2.7 maintenance branch. Alright, and what should stay in the docs then? I guess only 25.5.2 (usage of regrtest). The rest is either documentation of support, or advice for people writing new tests, both of which belong to the devguide. Eli ___ 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] Convention on functions that shadow existing stdlib functions
On Fri, Jul 29, 2011 at 4:52 PM, Eli Bendersky eli...@gmail.com wrote: On Fri, Jul 29, 2011 at 08:48, Nick Coghlan ncogh...@gmail.com wrote: On Fri, Jul 29, 2011 at 3:24 PM, Eli Bendersky eli...@gmail.com wrote: I propose to just move 3K's docs to the devguide, and make both doc pages (in 3K and 2.7) point to it. Is this acceptable? Yeah, just include a note in the devguide version saying that anything added in 3.2 or later may not be available when writing tests for the 2.7 maintenance branch. Alright, and what should stay in the docs then? I guess only 25.5.2 (usage of regrtest). The rest is either documentation of support, or advice for people writing new tests, both of which belong to the devguide. How to run the test suite should stay, along with a pointer to the additional information in the devguide. 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
[Python-Dev] Moving documentation of test.support into the devguide
I've opened issue 12652 to track this task. Proposed workflow: 1. First, the devguide incorporates the documentation 2. Then, I'll clean up the official docs and add pointers to the devguide instead The transition of the documentation into the devguide also has a few steps: 1. Move the reference of the utilities test.support provides. This reference documentation isn't complete (not all functions are documented), but can be completed later in the devguide. 2. (Optionally) incorporate the test-writing advice given in 25.5.1 into the devguide (which currently has only a short couple of paragraphs 3. Move any other information from the official docs (chapter 25) into the devguide, leaving only a section on running the tests (which should be identical to the relevant section in the devguide) and a pointer to the devguide. Issue #12652 now has a patch for step (1) above. Eli ___ 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] Convention on functions that shadow existing stdlib functions
On Jul 29, 2011, at 08:24 AM, Eli Bendersky wrote: Alright, I think there's now a sufficiently wide consensus to move the documentation of Lib/test and Lib/test/support in particular to the devguide, which raises a question: I haven't been following this thread, so I caught up on Gmane. I'm somewhat uncomfortable with this decision. I understand why you want to do this, but I still think it might not be the right thing. For better or worse, test.support is part of the standard library, so moving its documentation elsewhere sets a bad precedent to me. Many times I work on Python while completely off-line. If I've had the foresight to build the docs before I go off-line, all the better, but even if not, I have the .rst files to consult. Now I'll have to remember to *also* grab the devguide so that I have the complete documentation of the stdlib. I also think this underestimates how blurry the line is between users and developers. Think about yourself: when did you suddenly graduate from user of Python to developer of Python? I know that I often talk to people who would consider themselves just users of Python, but feel comfortable with their occasional spelunking into the Python tree looking for whatever nugget of code or documentation will help them understand their problem. The devguide, as useful and cool as it is, is still immature and hard to discover. I think more time will improve its organization, and it's not even linked to from docs.python.org. So I'm curious, why is this move better than adding noindexes, or just trusting users to understand the difference between test.support.unlink() and os.unlink()? If I currently search for 'unlink', os.unlink comes up first, which is good, and that should be preserved. The presence or not of some test.support.unlink documentation isn't going to make the search results that much better or worse (there's already 14 hits). Cheers, -Barry signature.asc Description: 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] Convention on functions that shadow existing stdlib functions
Alright, I think there's now a sufficiently wide consensus to move the documentation of Lib/test and Lib/test/support in particular to the devguide, which raises a question: I haven't been following this thread, so I caught up on Gmane. I'm somewhat uncomfortable with this decision. I understand why you want to do this, but I still think it might not be the right thing. For better or worse, test.support is part of the standard library, so moving Why is it part of stdlib though? Isn't the stdlib something that's exposed to all Python programmers? How should an ordinary programmer (not a core dev) know some parts of stdlib are out of limits, if they are even documented and appear in the index - should he read the note at the top of the documentation page? Imagine a desperate programmer behind schedule who is looking for some particular functionality in stdlib and finds it in test.support - will he not use it and later complain we don't keep backwards-compatibility. Sure, he's at fault, but I think we can make such cases much rarer by making the distinction between user-exposed modules and core-dev-exposed modules more explicit. its documentation elsewhere sets a bad precedent to me. Many times I work on Python while completely off-line. If I've had the foresight to build the docs before I go off-line, all the better, but even if not, I have the .rst files to consult. Now I'll have to remember to *also* grab the devguide so that I have the complete documentation of the stdlib. I think this is because you're experienced and probably know all the contents of the devguide anyway. Junior core-devs need the devguide handy for other reasons as well. I also think this underestimates how blurry the line is between users and developers. Think about yourself: when did you suddenly graduate from user of Python to developer of Python? I know that I often talk to people who would consider themselves just users of Python, but feel comfortable with their occasional spelunking into the Python tree looking for whatever nugget of code or documentation will help them understand their problem. Isn't this what we're trying to prevent, though? One should never even have to look at test.support unless he's working *on Python*. The devguide, as useful and cool as it is, is still immature and hard to discover. I think more time will improve its organization, and it's not even linked to from docs.python.org. Maybe this is the main point here - what makes it immature? What makes it hard to discover? Maybe these issues can be fixed. So I'm curious, why is this move better than adding noindexes, or just trusting users to understand the difference between test.support.unlink() and os.unlink()? If I currently search for 'unlink', os.unlink comes up first, which is good, and that should be preserved. The presence or not of some test.support.unlink documentation isn't going to make the search results that much better or worse (there's already 14 hits). I think the unlinkrmtree functions are just a symptom. The real issue here is - what is the devguide for, and how is it different from Python's existing documentation? What should go into the official docs, and what should go into the devguide? Once we agree on these question, I think the test.support dilemma will solve itself. Eli ___ 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] HTMLParser and HTML5
On Fri, Jul 29, 2011 at 1:37 AM, Stefan Behnel stefan...@behnel.de wrote: Brett Cannon, 28.07.2011 23:49: On Thu, Jul 28, 2011 at 11:25, Matt wrote: - What policies are in place for keeping parity with other HTML parsers (such as those in web browsers)? There aren't any beyond it would be nice. [...] It's more of an issue of someone caring enough to do the coding work to bring the parser up to spec for HTML5 (or introduce new code to live beside the HTML4 parsing code). Which, given that html5lib readily exists, would likely be a lot more work than anyone who is interested in HTML5 handling would want to invest. I don't think we need a new HTML5 parsing implementation only to have it in the stdlib. That's the old sunny Java way of doing it. I disaagree. Having proper html parsing out of the box is part of the batteries included thing. And it is not a matter of having html 5 - as stated on this thread, fixing it for html5 will fix it for html that exists in the real world. Python _has_ to work with quick 30-50 lines scripts deliverable everywhere, not just has proper 3rd party libraries that can work as part of a huge project using buildout. js -- Stefan ___ 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/jsbueno%40python.org.br ___ 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] HTMLParser and HTML5
Joao S. O. Bueno, 29.07.2011 13:22: On Fri, Jul 29, 2011 at 1:37 AM, Stefan Behnel wrote: Brett Cannon, 28.07.2011 23:49: On Thu, Jul 28, 2011 at 11:25, Matt wrote: - What policies are in place for keeping parity with other HTML parsers (such as those in web browsers)? There aren't any beyond it would be nice. [...] It's more of an issue of someone caring enough to do the coding work to bring the parser up to spec for HTML5 (or introduce new code to live beside the HTML4 parsing code). Which, given that html5lib readily exists, would likely be a lot more work than anyone who is interested in HTML5 handling would want to invest. I don't think we need a new HTML5 parsing implementation only to have it in the stdlib. That's the old sunny Java way of doing it. I disaagree. Having proper html parsing out of the box is part of the batteries included thing. Well, you can easily prove me wrong by implementing this. Stefan ___ 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
Le 28/07/2011 11:28, Victor Stinner a écrit : Please do keep the original implementation around (e.g. renamed to codecs.open_stream()), though, so that it's still possible to get easy-to-use access to codec StreamReader/Writers. I will add your alternative to the PEP (except if you would like to do that yourself?). If I understood correctly, you propose to: * rename codecs.open() to codecs.open_stream() * change codecs.open() to reuse open() (and so io.TextIOWrapper) (and don't deprecate anything) I added your proposal to the PEP as an Alternative Approache. Victor ___ 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] cpython (3.2): Fix sorting or wording of some NEWS entries.
On Fri, 29 Jul 2011 14:35:19 +0200 eric.araujo python-check...@python.org wrote: http://hg.python.org/cpython/rev/97527f3f9829 changeset: 71555:97527f3f9829 branch: 3.2 user:Éric Araujo mer...@netwok.org date:Tue Jul 26 17:32:50 2011 +0200 summary: Fix sorting or wording of some NEWS entries. I would have put io and ctypes fixes into Extension Modules, but I respected the choice of Antoine or Victor and left them in Library. There's no practical difference (from the user's point of view) between extension modules and the library, so I think the Extension Modules section should simply die. 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] cpython: Remove indirection in threading (issue #10968).
On Fri, 29 Jul 2011 14:35:23 +0200 eric.araujo python-check...@python.org wrote: It is now possible to inherit from Thread and other classes, without having to import the private underscored names like multiprocessing did. A correction: it was already possible to inherit from Thread (since it's quite useful to do so). 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] cpython (3.2): Fix sorting or wording of some NEWS entries.
On Fri, Jul 29, 2011 at 2:46 PM, Antoine Pitrou solip...@pitrou.net wrote: There's no practical difference (from the user's point of view) between extension modules and the library, so I think the Extension Modules section should simply die. +1. This has been bugging me for a while 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] cpython (3.2): Stop ignoring Mercurial merge conflits files (#12255).
On Fri, 29 Jul 2011 14:35:24 +0200 eric.araujo python-check...@python.org wrote: http://hg.python.org/cpython/rev/bdad5bc9a2ed changeset: 71562:bdad5bc9a2ed branch: 3.2 user:Éric Araujo mer...@netwok.org date:Thu Jul 28 22:45:46 2011 +0200 summary: Stop ignoring Mercurial merge conflits files (#12255). R. David Murray and I think that it’s more useful to have these files show up in the output of “hg status”, to let the user know that some merged file have to be checked before commit. Mercurial will prevent you from committing before you have solved conflicts, so I'm not sure what this brings. hg res -l is the command to remember when you want to list files with conflicts. The fact that make clean doesn't wipe these files is an additional annoyance. 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] cpython: Remove indirection in threading (issue #10968).
Le 29/07/2011 14:48, Antoine Pitrou a écrit : It is now possible to inherit from Thread and other classes, without having to import the private underscored names like multiprocessing did. A correction: it was already possible to inherit from Thread (since it's quite useful to do so). Indeed, and Timer for example inherits from Thread. The other classes I changed however were not subclassable (the original bug report was about subclassing Timer, not Thread), I just picked the one wrong example when writing “X and other classes” :) Regards ___ 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] cpython (3.2): Stop ignoring Mercurial merge conflits files (#12255).
Le 29/07/2011 14:50, Antoine Pitrou a écrit : changeset: 71562:bdad5bc9a2ed user:Éric Araujo mer...@netwok.org summary: Stop ignoring Mercurial merge conflits files (#12255). R. David Murray and I think that it’s more useful to have these files show up in the output of “hg status”, to let the user know that some merged file have to be checked before commit. Mercurial will prevent you from committing before you have solved conflicts, so I'm not sure what this brings. hg res -l is the command to remember when you want to list files with conflicts. People confused by the merge/resolve system could exit their merge tool without actually merging the changes (I know it happened to me!), so these files act as a reminder that not everything is right. .orig is also created by hg revert; my usage is that I remove this file after I’ve checked that the revert is okay. The fact that make clean doesn't wipe these files is an additional annoyance. make clean removes generated files, but *.rej and *.orig are backups, which you may want to save or re-apply. I’m not sure it would be right to lose them. Maybe distclean? Regards ___ 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] cpython (3.2): Stop ignoring Mercurial merge conflits files (#12255).
On Fri, 29 Jul 2011 15:28:44 +0200 Éric Araujo mer...@netwok.org wrote: Le 29/07/2011 14:50, Antoine Pitrou a écrit : changeset: 71562:bdad5bc9a2ed user:Éric Araujo mer...@netwok.org summary: Stop ignoring Mercurial merge conflits files (#12255). R. David Murray and I think that it’s more useful to have these files show up in the output of “hg status”, to let the user know that some merged file have to be checked before commit. Mercurial will prevent you from committing before you have solved conflicts, so I'm not sure what this brings. hg res -l is the command to remember when you want to list files with conflicts. People confused by the merge/resolve system could exit their merge tool without actually merging the changes (I know it happened to me!), so these files act as a reminder that not everything is right. I don't know, I don't use a merge tool. But presumably the merge tool would only call hg resolve -m on those files which have actually been resolved? (if it calls that command at all) The fact that make clean doesn't wipe these files is an additional annoyance. make clean removes generated files, but *.rej and *.orig are backups, which you may want to save or re-apply. What use are these backups really? We are using a (D)VCS, you are not losing anything. 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] cpython (3.2): Fix sorting or wording of some NEWS entries.
Le 29/07/2011 14:46, Antoine Pitrou a écrit : changeset: 71555:97527f3f9829 branch: 3.2 user:Éric Araujo mer...@netwok.org summary: Fix sorting or wording of some NEWS entries. I would have put io and ctypes fixes into Extension Modules, but I respected the choice of Antoine or Victor and left them in Library. There's no practical difference (from the user's point of view) between extension modules and the library, so I think the Extension Modules section should simply die. +1 to that. Would built-in modules like imp belong to Library or Interpreter Core? (I’d say Core.) When merging 3.2 into 3.3, I started sorting the Misc/NEWS file there too but stopped after ~30 changes. On one hand, I know that developer time would be better spent on fixing bugs rather than reading a commit sorting NEWS entries, but on the other hand I thought it best for readers of this file to have something that makes sense. Build fixes were not in a dedicated section, Core and Library are happily mixed, so I thought that my sorting could help even the What’s New author. I wanted to ask python-dev first, though. Regards ___ 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] cpython (3.2): Stop ignoring Mercurial merge conflits files (#12255).
On Fri, 29 Jul 2011 15:28:44 +0200, =?UTF-8?B?w4lyaWMgQXJhdWpv?= mer...@netwok.org wrote: Le 29/07/2011 14:50, Antoine Pitrou a écrit : changeset: 71562:bdad5bc9a2ed user:Ãric Araujo mer...@netwok.org summary: Stop ignoring Mercurial merge conflits files (#12255). R. David Murray and I think that itâs more useful to have these files show up in the output of âhg statusâ, to let the user know that some merged file have to be checked before commit. Mercurial will prevent you from committing before you have solved conflicts, so I'm not sure what this brings. hg res -l is the command to remember when you want to list files with conflicts. People confused by the merge/resolve system could exit their merge tool without actually merging the changes (I know it happened to me!), so these files act as a reminder that not everything is right. Or people who decide the particular merge tool isn't going to help in a particular case. I do that reasonably often. .orig is also created by hg revert; my usage is that I remove this file after Iâve checked that the revert is okay. And by patch. This is my major reason for disliking having these files ignored. I want to know about the .rej and .orig files patch generates that I may have forgotten about, and not just to clean them up. Their existence is a signal that there's something I haven't finished working through (or that I at least need to check that I worked through it before deleting them). The fact that make clean doesn't wipe these files is an additional annoyance. make clean removes generated files, but *.rej and *.orig are backups, which you may want to save or re-apply. Iâm not sure it would be right to lose them. Maybe distclean? Exactly. Which is another reason these files should not be ignored: even distclean should probably not remove the backup files generated by patch, which means that hg status should show the files because they aren't part of the distribution. Which means (assuming there is agreement with my logic :) that make distclean probably *should* remove the stuff generated by coverage, given that we are ignoring that stuff now. --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] cpython (3.2): Stop ignoring Mercurial merge conflits files (#12255).
People confused by the merge/resolve system could exit their merge tool without actually merging the changes (I know it happened to me!), so these files act as a reminder that not everything is right. I don't know, I don't use a merge tool. But presumably the merge tool would only call hg resolve -m on those files which have actually been resolved? (if it calls that command at all) You have it backwards: it’s hg resolve that runs a merge tool. (BTW, how can you not use a merge tool? Even if you use internal hg tools like the one that adds merge conflict markers, that’s a merge tool.) What use are these backups really? We are using a (D)VCS, you are not losing anything. The .orig files after a revert could contain code that’s not committed anywhere. See also RDM’s reply to your message. Regards ___ 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] cpython (3.2): Stop ignoring Mercurial merge conflits files (#12255).
On Fri, 29 Jul 2011 15:38:31 +0200, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 29 Jul 2011 15:28:44 +0200 Ãric Araujo mer...@netwok.org wrote: make clean removes generated files, but *.rej and *.orig are backups, which you may want to save or re-apply. What use are these backups really? We are using a (D)VCS, you are not losing anything. As Ãric said, the .orig files may contain uncommitted changes. The .rej files are information about what parts of the patch were *not* applied, which is information that is not retained anywhere else. --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] cpython (3.2): Stop ignoring Mercurial merge conflits files (#12255).
On Fri, 29 Jul 2011 16:21:42 +0200 Éric Araujo mer...@netwok.org wrote: What use are these backups really? We are using a (D)VCS, you are not losing anything. The .orig files after a revert could contain code that’s not committed anywhere. See also RDM’s reply to your message. I would point out that by using hg revert, you deliberately want to forget some local changes. Besides, hg status is meant to show untracked files which could *potentially* be tracked. It's not like anybody wants to track .orig and .rej files, so having them in the ignore list is still the right thing to do. 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] cpython (3.2): Fix sorting or wording of some NEWS entries.
On Fri, 29 Jul 2011 15:22:08 +0200 Éric Araujo mer...@netwok.org wrote: There's no practical difference (from the user's point of view) between extension modules and the library, so I think the Extension Modules section should simply die. +1 to that. Would built-in modules like imp belong to Library or Interpreter Core? (I’d say Core.) As soon as you are fixing a library API, it should IMO go to Library. The fact that some modules are built-in is an implementation detail. For example, _io is compiled in the executable (for bootstrap reasons), yet it's still considered part of the library. When merging 3.2 into 3.3, I started sorting the Misc/NEWS file there too but stopped after ~30 changes. On one hand, I know that developer time would be better spent on fixing bugs rather than reading a commit sorting NEWS entries, but on the other hand I thought it best for readers of this file to have something that makes sense. Build fixes were not in a dedicated section, Core and Library are happily mixed, so I thought that my sorting could help even the What’s New author. I wanted to ask python-dev first, though. Well, sorting is fine, if you don't think your developer time could be used for more valuable tasks :) 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] Convention on functions that shadow existing stdlib functions
On Fri, Jul 29, 2011 at 7:26 PM, Barry Warsaw ba...@python.org wrote: The devguide, as useful and cool as it is, is still immature and hard to discover. I think more time will improve its organization, and it's not even linked to from docs.python.org. So I'm curious, why is this move better than adding noindexes, or just trusting users to understand the difference between test.support.unlink() and os.unlink()? If I currently search for 'unlink', os.unlink comes up first, which is good, and that should be preserved. The presence or not of some test.support.unlink documentation isn't going to make the search results that much better or worse (there's already 14 hits). It's worthwhile because it is what the devguide is for: documenting how to *change* Python, rather than just using it as it is delivered to you. There's a clear transition from user of Python to developer of Python: you stop treating the standard library (and perhaps even the interpreter core) as sacrosanct, and will actually change the code in those files if its wrong (and is affecting your own application). Agreed that docs.python.org front page should have a link to docs.python.org/devguide, though. 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] Convention on functions that shadow existing stdlib functions
On Jul 29, 2011, at 02:07 PM, Eli Bendersky wrote: Why is it part of stdlib though? Isn't the stdlib something that's exposed to all Python programmers? How should an ordinary programmer (not a core dev) know some parts of stdlib are out of limits, if they are even documented and appear in the index - should he read the note at the top of the documentation page? Imagine a desperate programmer behind schedule who is looking for some particular functionality in stdlib and finds it in test.support - will he not use it and later complain we don't keep backwards-compatibility. Sure, he's at fault, but I think we can make such cases much rarer by making the distinction between user-exposed modules and core-dev-exposed modules more explicit. How common are those mistakes right now? I get way more complaints about squishy APIs in third party libraries and actual *supported* parts of the stdlib than I do about test.support APIs. What's the real problem we're trying to solve anyway? Is it protect the harried user from some future breakage or eliminate complaints we Python developers get from harried users? I'd much rather solve this problem by adding markup to functions that explicitly disclaim our normal backward compatibility guarantees. Squirreling away documentation for some parts of the stdlib seems similar to security-by-obscurity arguments. test.support *is* part of the stdlib. If you want to propose moving it out of the stdlib, that's a different argument to make. Maybe Python's entire test suite should be in some Cheeseshop package instead of in the core source tree. (I wouldn't agree with that either, but I'm just saying.) So once again, is this a real actual problem you've witnessed in enough cases to go through all the trouble of moving the documentation, and making it more difficult to find? its documentation elsewhere sets a bad precedent to me. Many times I work on Python while completely off-line. If I've had the foresight to build the docs before I go off-line, all the better, but even if not, I have the .rst files to consult. Now I'll have to remember to *also* grab the devguide so that I have the complete documentation of the stdlib. I think this is because you're experienced and probably know all the contents of the devguide anyway. Junior core-devs need the devguide handy for other reasons as well. I'm not saying the devguide isn't handy - in fact it's incredibly handy! I love that it explains the nuances of how we structure our Mercurial branches, and define our workflow for example. I readily admit those are not things I know by heart. (But actually, those instructions are not always easy to find, which is why I think the organization is immature. I'm not faulting the devguide authors, I just think it needs more time to bake.) I also think this underestimates how blurry the line is between users and developers. Think about yourself: when did you suddenly graduate from user of Python to developer of Python? I know that I often talk to people who would consider themselves just users of Python, but feel comfortable with their occasional spelunking into the Python tree looking for whatever nugget of code or documentation will help them understand their problem. Isn't this what we're trying to prevent, though? One should never even have to look at test.support unless he's working *on Python*. Again, I think that line is blurred here. Let's say you're working on some off-beat or new hardware and you want to know if your basic tool chain works for it. You build Python, run the test suite, and something fails. You probably don't consider yourself a Python developer, but now you're digging through the test.support to figure out your problem. Yes, I've seen this happen. The devguide, as useful and cool as it is, is still immature and hard to discover. I think more time will improve its organization, and it's not even linked to from docs.python.org. Maybe this is the main point here - what makes it immature? What makes it hard to discover? Maybe these issues can be fixed. Sure, there are issues that can be fixed, but they're unrelated to documenting test.support. So I'm curious, why is this move better than adding noindexes, or just trusting users to understand the difference between test.support.unlink() and os.unlink()? If I currently search for 'unlink', os.unlink comes up first, which is good, and that should be preserved. The presence or not of some test.support.unlink documentation isn't going to make the search results that much better or worse (there's already 14 hits). I think the unlinkrmtree functions are just a symptom. The real issue here is - what is the devguide for, and how is it different from Python's existing documentation? What should go into the official docs, and what should go into the devguide? Once we agree on these question, I think the test.support dilemma will solve itself. Let's see! I think the devguide should
Re: [Python-Dev] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
On Thu, 28 Jul 2011 11:28:43 +0200 Victor Stinner victor.stin...@haypocalc.com wrote: I will add your alternative to the PEP (except if you would like to do that yourself?). If I understood correctly, you propose to: * rename codecs.open() to codecs.open_stream() * change codecs.open() to reuse open() (and so io.TextIOWrapper) (and don't deprecate anything) This may be an interesting approach. In a few years, we can evaluate whether users are calling open_stream(), and if there aren't any, we can deprecate the whole thing. 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] Convention on functions that shadow existing stdlib functions
On Fri, 29 Jul 2011 11:18:37 -0400 Barry Warsaw ba...@python.org wrote: I'd much rather solve this problem by adding markup to functions that explicitly disclaim our normal backward compatibility guarantees. Squirreling away documentation for some parts of the stdlib seems similar to security-by-obscurity arguments. Well, here the whole module should not be called by the user. I'm not sure we want to flag each function individually. test.support *is* part of the stdlib. We have lots of internal APIs which are not documented, though. And test.support *is* for internal use. 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] Convention on functions that shadow existing stdlib functions
Barry Warsaw wrote: On Jul 29, 2011, at 02:07 PM, Eli Bendersky wrote: I think the unlinkrmtree functions are just a symptom. The real issue here is - what is the devguide for, and how is it different from Python's existing documentation? What should go into the official docs, and what should go into the devguide? Once we agree on these question, I think the test.support dilemma will solve itself. Let's see! I think the devguide should document things like how to submit bugs, how to use Mercurial, how to propose changes to Python, how to ensure code works across all existing interpreter implementations, where to find continuous integration results and how to interpret them, what's the right forum to discuss Python, etc. I.e. processes, workflows, and conventions that are important cultural artifacts we've built up over 20 years. I don't think the devguide should document the actual code we ship. +1 ~Ethan~ ___ 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] Convention on functions that shadow existing stdlib functions
On Sat, Jul 30, 2011 at 1:18 AM, Barry Warsaw ba...@python.org wrote: On Jul 29, 2011, at 02:07 PM, Eli Bendersky wrote: I think the unlinkrmtree functions are just a symptom. The real issue here is - what is the devguide for, and how is it different from Python's existing documentation? What should go into the official docs, and what should go into the devguide? Once we agree on these question, I think the test.support dilemma will solve itself. Let's see! I think the devguide should document things like how to submit bugs, how to use Mercurial, how to propose changes to Python, how to ensure code works across all existing interpreter implementations, where to find continuous integration results and how to interpret them, what's the right forum to discuss Python, etc. I.e. processes, workflows, and conventions that are important cultural artifacts we've built up over 20 years. I don't think the devguide should document the actual code we ship. I think everything related to *changing* Python should be in the devguide, not the standard library docs. So the documentation on how to *run* the test suite belongs in the devguide, but the details of how the test suite works internally, including the APIs that are used to write new tests, belong in the dev guide. Now, perhaps a copy of the dev guide should be bundled with all future releases rather than relying on the availability of a net connection to access wart, but finally getting rid of the dodgy test.support sort-of-docs out of the standard library docs is an excellent change. As far as improving the arrangement goes, the checkin privileges are the same as those for the main source tree - patches welcome :) 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] Convention on functions that shadow existing stdlib functions
On Sat, Jul 30, 2011 at 1:32 AM, Nick Coghlan ncogh...@gmail.com wrote: So the documentation on how to *run* the test suite belongs in the devguide, but the details of how the test suite works internally, including the APIs that are used to write new tests, belong in the dev guide. Gah, that first instance of 'the devguide' should read 'the standard library docs'. 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
On Sat, Jul 30, 2011 at 1:17 AM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 28 Jul 2011 11:28:43 +0200 Victor Stinner victor.stin...@haypocalc.com wrote: I will add your alternative to the PEP (except if you would like to do that yourself?). If I understood correctly, you propose to: * rename codecs.open() to codecs.open_stream() * change codecs.open() to reuse open() (and so io.TextIOWrapper) (and don't deprecate anything) This may be an interesting approach. In a few years, we can evaluate whether users are calling open_stream(), and if there aren't any, we can deprecate the whole thing. Indeed. I'm also heavily influenced by MAL's opinion on this particular topic, so the fact he's OK with this approach counts for a lot. It achieves the main benefit I'm interested in (transparently migrating users of the codecs.open API to the new IO stack), while paving the way for eliminating the redundancy at some point in the future. 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] Convention on functions that shadow existing stdlib functions
On 7/29/2011 8:18 AM, Barry Warsaw wrote: I think the devguide should document things like ... how to ensure code works across all existing interpreter implementations, where to find continuous integration results and how to interpret them ... I don't think the devguide should document the actual code we ship. Seems to me that test.support documentation helps explain the above items. ___ 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] Convention on functions that shadow existing stdlib functions
On Jul 30, 2011, at 01:02 AM, Nick Coghlan wrote: It's worthwhile because it is what the devguide is for: documenting how to *change* Python, rather than just using it as it is delivered to you. There's a clear transition from user of Python to developer of Python: you stop treating the standard library (and perhaps even the interpreter core) as sacrosanct, and will actually change the code in those files if its wrong (and is affecting your own application). I'm not so sure the line's that bright. But anyway... Using the criteria in your first sentence, test.support is clearly what's delivered to you not changing Python. IOW, we ship test.support in the tarball, so *if* it's to be documented, then the stdlib is the right place to document it, IMO. If test.support is truly and only an internal implementation detail, then it should adhere to Pythonic convention for such things, and be renamed test._support. Then you won't need to document it at all except in the module. Here's another problem with moving the documentation for test.support to the devguide. They will invariably get out of sync. It's hard enough to keep stdlib code and stdlib docs in sync, but I think it will be even harder to keep stdlib code in sync with devguide documentation. It will also be harder to know what version of the devguide corresponds to what version of the code repository. -Barry signature.asc Description: 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] Convention on functions that shadow existing stdlib functions
On Jul 29, 2011, at 05:25 PM, Antoine Pitrou wrote: test.support *is* part of the stdlib. We have lots of internal APIs which are not documented, though. And test.support *is* for internal use. The solution then is to rename test.support to test._support to make it clear it's an internal implementation detail. Then you can remove the entire section from the stdlib docs and just document it in the code. -Barry signature.asc Description: 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
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2011-07-22 - 2011-07-29) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open2889 ( +3) closed 21547 (+40) total 24436 (+43) Open issues with patches: 1259 Issues opened (31) == #12612: Valgrind suppressions http://bugs.python.org/issue12612 opened by Paul.Price #12613: itertools fixer fails http://bugs.python.org/issue12613 opened by VPeric #12614: Allow to explicitly set the method of urllib.request.Request http://bugs.python.org/issue12614 opened by tebeka #12616: zip fixer fails on zip()[:-1] http://bugs.python.org/issue12616 opened by VPeric #12617: Mutable Sequence Type can work not only with iterable in slice http://bugs.python.org/issue12617 opened by py.user #12618: py_compile cannot create files in current directory http://bugs.python.org/issue12618 opened by sjdv1982 #12619: Automatically regenerate platform-specific modules http://bugs.python.org/issue12619 opened by Arfrever #12622: failfast argument to TextTestRunner not documented http://bugs.python.org/issue12622 opened by pitrou #12623: universal newlines subprocess support broken with select- an http://bugs.python.org/issue12623 opened by pitrou #12625: sporadic test_unittest failure http://bugs.python.org/issue12625 opened by pitrou #12626: run test cases based on a glob filter http://bugs.python.org/issue12626 opened by pitrou #12627: Implement PEP 394: The python Command on Unix-Like Systems http://bugs.python.org/issue12627 opened by Kerrick.Staley #12629: HTMLParser silently stops parsing with malformed attributes http://bugs.python.org/issue12629 opened by teoryn #12631: Mutable Sequence Type in .remove() is consistent only with lis http://bugs.python.org/issue12631 opened by py.user #12632: Windows GPF with Code Page 65001 http://bugs.python.org/issue12632 opened by bferris57 #12633: sys.modules doc entry should reflect restrictions http://bugs.python.org/issue12633 opened by ericsnow #12634: Random Remarks in class documentation http://bugs.python.org/issue12634 opened by ats.engg #12636: IDLE ignores -*- coding -*- with -r option http://bugs.python.org/issue12636 opened by ledave123 #12638: urllib.URLopener prematurely deletes files on cleanup http://bugs.python.org/issue12638 opened by carlbook #12639: msilib Directory.start_component() fails if keyfile is not Non http://bugs.python.org/issue12639 opened by john.keeping #12640: test_ctypes seg fault (test_callback_register_double); armv7; http://bugs.python.org/issue12640 opened by python272 #12641: Remove -mno-cygwin from distutils http://bugs.python.org/issue12641 opened by jonforums #12643: code.InteractiveConsole ignores sys.excepthook http://bugs.python.org/issue12643 opened by aliles #12645: test.support. import_fresh_module - incorrect doc http://bugs.python.org/issue12645 opened by eli.bendersky #12646: zlib.Decompress.decompress/flush do not raise any exceptions w http://bugs.python.org/issue12646 opened by chortos #12648: Wrong import module search order on Windows http://bugs.python.org/issue12648 opened by kota #12649: email.Header ignores maxlinelen when wrapping encoded words http://bugs.python.org/issue12649 opened by dandre #12650: Subprocess leaks fd upon kill() http://bugs.python.org/issue12650 opened by gabriele.trombetti #12652: Move documentation of test.support into the devguide http://bugs.python.org/issue12652 opened by eli.bendersky #12653: Provide accelerators for all buttons in Windows installers http://bugs.python.org/issue12653 opened by cool-RR #12654: sum() works with bytes objects http://bugs.python.org/issue12654 opened by pitrou Most recent 15 issues with no replies (15) == #12654: sum() works with bytes objects http://bugs.python.org/issue12654 #12653: Provide accelerators for all buttons in Windows installers http://bugs.python.org/issue12653 #12648: Wrong import module search order on Windows http://bugs.python.org/issue12648 #12645: test.support. import_fresh_module - incorrect doc http://bugs.python.org/issue12645 #12640: test_ctypes seg fault (test_callback_register_double); armv7; http://bugs.python.org/issue12640 #12639: msilib Directory.start_component() fails if keyfile is not Non http://bugs.python.org/issue12639 #12623: universal newlines subprocess support broken with select- an http://bugs.python.org/issue12623 #12622: failfast argument to TextTestRunner not documented http://bugs.python.org/issue12622 #12616: zip fixer fails on zip()[:-1] http://bugs.python.org/issue12616 #12613: itertools fixer fails http://bugs.python.org/issue12613 #12612: Valgrind suppressions http://bugs.python.org/issue12612 #12599: Use 'is not None' where appropriate in importlib http://bugs.python.org/issue12599 #12598: Move sys variable initialization from
Re: [Python-Dev] Convention on functions that shadow existing stdlib functions
On Fri, 29 Jul 2011 11:18:37 -0400, Barry Warsaw ba...@python.org wrote: On Jul 29, 2011, at 02:07 PM, Eli Bendersky wrote: Isn't this what we're trying to prevent, though? One should never even have to look at test.support unless he's working *on Python*. Again, I think that line is blurred here. Let's say you're working on some off-beat or new hardware and you want to know if your basic tool chain works for it. You build Python, run the test suite, and something fails. You probably don't consider yourself a Python developer, but now you're digging through the test.support to figure out your problem. Yes, I've seen this happen. In that case, you are working *on Python*. Not using Python. Personally, I'd expect such information to be in a devguide, although really I'd not expect it to be documented at all, for most projects. Making the devguide a more prominent part of the documentation would be good: it would invite more people to cross that line and help us improve Python. As someone else pointed out, there is lots of stuff in the stdlib that is not public API, and therefore not documented. The problem with test.support is that it is not a public API, but *is* documented. So logically either we should remove the documentation, or we should not only do as you suggested by marking each function as not-a-stable-API, but also document as many of the other internal APIs as we care to in the same way. That would doubtless help our users, but more care than just marking functions as unstable would be required, I think. Personally, I always thought the devguide should be part of Docs anyway. It isn't because people didn't want it versioned along side Python, but I still don't see why that would be a problem. -- R. David Murray http://www.bitdance.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] cpython (3.2): Stop ignoring Mercurial merge conflits files (#12255).
On Fri, 29 Jul 2011 16:49:35 +0200, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 29 Jul 2011 16:21:42 +0200 mer...@netwok.org wrote: What use are these backups really? We are using a (D)VCS, you are not losing anything. The .orig files after a revert could contain code thatâs not committed anywhere. See also RDMâs reply to your message. I would point out that by using hg revert, you deliberately want to forget some local changes. But *I'm* talking about 'patch'. That has nothing to do with either merge or revert. Besides, hg status is meant to show untracked files which could *potentially* be tracked. It's not like anybody wants to track .orig and .rej files, so having them in the ignore list is still the right thing to do. That's one view. My view is that 'hg status' tells me all the files that have appeared in my tree that I'm either not currently tracking or explicitly ignoring (because the project's automated tools will deal with them). Nothing in there about limiting it to files I *might* want to track. That is how I've always used my version control systems. -- R. David Murray http://www.bitdance.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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
On Fri, Jul 29, 2011 at 8:37 AM, Nick Coghlan ncogh...@gmail.com wrote: On Sat, Jul 30, 2011 at 1:17 AM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 28 Jul 2011 11:28:43 +0200 Victor Stinner victor.stin...@haypocalc.com wrote: I will add your alternative to the PEP (except if you would like to do that yourself?). If I understood correctly, you propose to: * rename codecs.open() to codecs.open_stream() * change codecs.open() to reuse open() (and so io.TextIOWrapper) (and don't deprecate anything) This may be an interesting approach. In a few years, we can evaluate whether users are calling open_stream(), and if there aren't any, we can deprecate the whole thing. Indeed. I'm also heavily influenced by MAL's opinion on this particular topic, so the fact he's OK with this approach counts for a lot. It achieves the main benefit I'm interested in (transparently migrating users of the codecs.open API to the new IO stack), while paving the way for eliminating the redundancy at some point in the future. +1 -- --Guido van Rossum (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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
Victor Stinner wrote: Le 28/07/2011 11:28, Victor Stinner a écrit : Please do keep the original implementation around (e.g. renamed to codecs.open_stream()), though, so that it's still possible to get easy-to-use access to codec StreamReader/Writers. I will add your alternative to the PEP (except if you would like to do that yourself?). If I understood correctly, you propose to: * rename codecs.open() to codecs.open_stream() * change codecs.open() to reuse open() (and so io.TextIOWrapper) (and don't deprecate anything) I added your proposal to the PEP as an Alternative Approache. Thanks. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 29 2011) 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] Convention on functions that shadow existing stdlib functions
On Jul 29, 2011, at 12:13 PM, R. David Murray wrote: In that case, you are working *on Python*. Not using Python. My point was, it's a fine line between the two. Personally, I always thought the devguide should be part of Docs anyway. It isn't because people didn't want it versioned along side Python, but I still don't see why that would be a problem. +1 -Barry signature.asc Description: 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] HTMLParser and HTML5
On Jul 29, 2011, at 7:46 AM, Stefan Behnel wrote: Joao S. O. Bueno, 29.07.2011 13:22: On Fri, Jul 29, 2011 at 1:37 AM, Stefan Behnel wrote: Brett Cannon, 28.07.2011 23:49: On Thu, Jul 28, 2011 at 11:25, Matt wrote: - What policies are in place for keeping parity with other HTML parsers (such as those in web browsers)? There aren't any beyond it would be nice. [...] It's more of an issue of someone caring enough to do the coding work to bring the parser up to spec for HTML5 (or introduce new code to live beside the HTML4 parsing code). Which, given that html5lib readily exists, would likely be a lot more work than anyone who is interested in HTML5 handling would want to invest. I don't think we need a new HTML5 parsing implementation only to have it in the stdlib. That's the old sunny Java way of doing it. I disaagree. Having proper html parsing out of the box is part of the batteries included thing. Well, you can easily prove me wrong by implementing this. Stefan Please don't implement this just to profe Stefan wrong :). The thing to do, if you want html parsing in the stdlib, is to _incorporate_ html5lib, which is already a perfectly good, thoroughly tested HTML parser, and simply deprecate HTMLParser and friends. Implementing a new parser would serve no purpose I can see. -glyph ___ 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] HTMLParser and HTML5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/29/2011 07:22 AM, Joao S. O. Bueno wrote: I disaagree. Having proper html parsing out of the box is part of the batteries included thing. And it is not a matter of having html 5 - as stated on this thread, fixing it for html5 will fix it for html that exists in the real world. Python _has_ to work with quick 30-50 lines scripts deliverable everywhere, not just has proper 3rd party libraries that can work as part of a huge project using buildout. Assuming it were merged today, that parser would only be available on Python 3.3 and later: how is that everywhere? Having scripts that work against html5lib (which *doesn't* need buildout to install, or even setuptools) makes them portable to any version of Python supported by the library (Python 2.3+, AFAICT). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4y/JYACgkQ+gerLs4ltQ4KKwCgkyOlmb8xxhxg1qWH9RRbEpEw ne0AoL6NgRElbY61QRqnXJjiKoHq0ToW =fk3k -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] Convention on functions that shadow existing stdlib functions
On Fri, 29 Jul 2011 11:49:01 -0400, Barry Warsaw ba...@python.org wrote: If test.support is truly and only an internal implementation detail, then it should adhere to Pythonic convention for such things, and be renamed test._support. Then you won't need to document it at all except in the module. I'd be fine with renaming it and not documenting it, myself. Other developers prefer to have as much as practical documented in html form. Here's another problem with moving the documentation for test.support to the devguide. They will invariably get out of sync. It's hard enough to keep stdlib code and stdlib docs in sync, but I think it will be even harder to keep stdlib code in sync with devguide documentation. It will also be harder to know what version of the devguide corresponds to what version of the code repository. Which wouldn't be any more of a problem than the regular python docs if the devguide were in the normal doc tree. Just saying :) -- R. David Murray http://www.bitdance.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] HTMLParser and HTML5
On Fri, Jul 29, 2011 at 11:03 AM, Glyph Lefkowitz gl...@twistedmatrix.comwrote: On Jul 29, 2011, at 7:46 AM, Stefan Behnel wrote: Joao S. O. Bueno, 29.07.2011 13:22: On Fri, Jul 29, 2011 at 1:37 AM, Stefan Behnel wrote: Brett Cannon, 28.07.2011 23:49: On Thu, Jul 28, 2011 at 11:25, Matt wrote: - What policies are in place for keeping parity with other HTML parsers (such as those in web browsers)? There aren't any beyond it would be nice. [...] It's more of an issue of someone caring enough to do the coding work to bring the parser up to spec for HTML5 (or introduce new code to live beside the HTML4 parsing code). Which, given that html5lib readily exists, would likely be a lot more work than anyone who is interested in HTML5 handling would want to invest. I don't think we need a new HTML5 parsing implementation only to have it in the stdlib. That's the old sunny Java way of doing it. I disaagree. Having proper html parsing out of the box is part of the batteries included thing. Well, you can easily prove me wrong by implementing this. As far as the issue described in my initial message goes, there is a patch and tests for the patch. Please don't implement this just to profe Stefan wrong :). The thing to do, if you want html parsing in the stdlib, is to _incorporate_ html5lib, which is already a perfectly good, thoroughly tested HTML parser, and simply deprecate HTMLParser and friends. Implementing a new parser would serve no purpose I can see. I don't see any real reason to drop a decent piece of code (HTMLParser, that is) in favor of a third party library when only relatively minor updates are needed to bring it up to speed with the latest spec. As far as structure goes, HTML4 and HTML5 are practically identical. The differences between the two that are applicable to HTMLParser involve the way the specs deal with special element types and broken syntax. For what it's worth, the rules HTML4 does define are (in many cases) ignored in favor of more modern, Postel's Law-agreeable rules. HTML5 simply standardized what browsers actually do. Deprecating HTMLParser in favor of a newer/better/faster HTML library is a bad thing for everybody that's already using HTMLParser, whether directly or indirectly. html5lib does not have an interface compatible with HTMLParser, so code would largely need to be rewritten from scratch to gain the benefits of HTML5's support for broken code. Developers using HTMLParser would be permanently stuck using a library that throws exceptions for perfectly valid HTML. Keep in mind that these are solved problems: all of the thinking on how to handle broken code has been done for us by the folks at the WHATWG. It's simply a matter of updating our existing code with these new rules. While I agree that there are merits to dropping support for the old code, it does not solve the existing problems that folks are having right now (namely incorrect parser output or exceptions). It would be more ideal to perhaps patch the obvious issues stemming from HTML4 support for now, leaving anything that goes beyond parity with browsers for a later time or implementing as an opt-in feature (i.e.: enabled by a parameter). Matt ___ 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] cpython: Issue 12647: Add __bool__() method to the None object.
On Thu, Jul 28, 2011 at 09:55, raymond.hettinger python-check...@python.org
wrote:
http://hg.python.org/cpython/rev/ccce01988603
changeset: 71542:ccce01988603
user:Raymond Hettinger pyt...@rcn.com
date:Thu Jul 28 09:55:13 2011 -0700
summary:
Issue 12647: Add __bool__() method to the None object.
files:
Lib/test/test_descr.py | 3 -
Misc/NEWS | 4 ++
Objects/object.c | 46 -
3 files changed, 48 insertions(+), 5 deletions(-)
diff --git a/Lib/test/test_descr.py b/Lib/test/test_descr.py
--- a/Lib/test/test_descr.py
+++ b/Lib/test/test_descr.py
@@ -2068,9 +2068,6 @@
# Two essentially featureless objects, just inheriting stuff from
# object.
self.assertEqual(dir(NotImplemented), dir(Ellipsis))
-if support.check_impl_detail():
-# None differs in PyPy: it has a __nonzero__
-self.assertEqual(dir(None), dir(Ellipsis))
Wasn't this change only in 3.3 where __nonzero__ doesn't exist? So when PyPy
eventually supports Python 3 they will have to update to support __bool__ on
None but this test won't exercise that for them. IOW I think the guard is
wrong and should go.
-Brett
# Nasty test case for proxied objects
class Wrapper(object):
diff --git a/Misc/NEWS b/Misc/NEWS
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -13,6 +13,10 @@
- Verify the types of AST strings and identifiers provided by the user
before
compiling them.
+- Issue #12647: The None object now has a __bool__() method that returns
False.
+ Formerly, bool(None) returned False only because of special case logic
+ in PyObject_IsTrue().
+
- Issue #12579: str.format_map() now raises a ValueError if used on a
format string that contains positional fields. Initial patch by
Julian Berman.
diff --git a/Objects/object.c b/Objects/object.c
--- a/Objects/object.c
+++ b/Objects/object.c
@@ -1255,7 +1255,7 @@
}
/*
-None is as a non-NULL undefined value.
+None is a non-NULL undefined value.
There is (and should be!) no way to create other objects of this type,
so there is exactly one (which is indestructible, by the way).
*/
@@ -1277,6 +1277,48 @@
Py_FatalError(deallocating None);
}
+static int
+none_bool(PyObject *v)
+{
+return 0;
+}
+
+static PyNumberMethods none_as_number = {
+0, /* nb_add */
+0, /* nb_subtract */
+0, /* nb_multiply */
+0, /* nb_remainder */
+0, /* nb_divmod */
+0, /* nb_power */
+0, /* nb_negative */
+0, /* nb_positive */
+0, /* nb_absolute */
+(inquiry)none_bool, /* nb_bool */
+0, /* nb_invert */
+0, /* nb_lshift */
+0, /* nb_rshift */
+0, /* nb_and */
+0, /* nb_xor */
+0, /* nb_or */
+0, /* nb_int */
+0, /* nb_reserved */
+0, /* nb_float */
+0, /* nb_inplace_add */
+0, /* nb_inplace_subtract */
+0, /* nb_inplace_multiply */
+0, /* nb_inplace_remainder */
+0, /* nb_inplace_power */
+0, /* nb_inplace_lshift */
+0, /* nb_inplace_rshift */
+0, /* nb_inplace_and */
+0, /* nb_inplace_xor */
+0, /* nb_inplace_or */
+0, /* nb_floor_divide */
+0, /* nb_true_divide */
+0, /* nb_inplace_floor_divide */
+0, /* nb_inplace_true_divide */
+0, /* nb_index */
+};
static PyTypeObject PyNone_Type = {
PyVarObject_HEAD_INIT(PyType_Type, 0)
@@ -1289,7 +1331,7 @@
0, /*tp_setattr*/
0, /*tp_reserved*/
none_repr, /*tp_repr*/
-0, /*tp_as_number*/
+none_as_number,/*tp_as_number*/
0, /*tp_as_sequence*/
0, /*tp_as_mapping*/
0, /*tp_hash */
--
Repository URL: http://hg.python.org/cpython
___
Python-checkins mailing list
python-check...@python.org
http://mail.python.org/mailman/listinfo/python-checkins
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Re: [Python-Dev] HTMLParser and HTML5
On Jul 29, 2011, at 3:00 PM, Matt wrote: I don't see any real reason to drop a decent piece of code (HTMLParser, that is) in favor of a third party library when only relatively minor updates are needed to bring it up to speed with the latest spec. I am not really one to throw stones here, as Twisted contains a lenient pseudo-XML parser which I still maintain - one which decidedly does not agree with html5's requirements for dealing with invalid data, but just a bunch of ad-hoc guesses of my own. My impression of HTML5 is that HTMLParser would require significant modifications and possibly a drastic re-architecture in order to really do HTML5 right; especially the parts that the html5lib authors claim makes HTML5 streaming-unfriendly, i.e. subtree reordering when encountering certain types of invalid data. But if I'm wrong about that, and there are just a few spec updates and bugfixes that need to be applied, by all means, ignore my comment. -glyph ___ 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] HTMLParser and HTML5
On Fri, Jul 29, 2011 at 11:31, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/29/2011 07:22 AM, Joao S. O. Bueno wrote: I disaagree. Having proper html parsing out of the box is part of the batteries included thing. And it is not a matter of having html 5 - as stated on this thread, fixing it for html5 will fix it for html that exists in the real world. Python _has_ to work with quick 30-50 lines scripts deliverable everywhere, not just has proper 3rd party libraries that can work as part of a huge project using buildout. Assuming it were merged today, that parser would only be available on Python 3.3 and later: how is that everywhere? Well, everywhere, eventually. This gets down to the usual philosophical debate of what should (not) be in the stdlib so that those who have strict third-party code get access to useful libraries while balancing the desire of those who want to keep the stdlib lean or prevent stagnating the API of a module. Having scripts that work against html5lib (which *doesn't* need buildout to install, or even setuptools) makes them portable to any version of Python supported by the library (Python 2.3+, AFAICT). If the library was brought in they could probably continue to be portable with possibly just the addition of a try/finally on the import line. -Brett Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4y/JYACgkQ+gerLs4ltQ4KKwCgkyOlmb8xxhxg1qWH9RRbEpEw ne0AoL6NgRElbY61QRqnXJjiKoHq0ToW =fk3k -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/brett%40python.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] HTMLParser and HTML5
On Fri, Jul 29, 2011 at 13:16, Glyph Lefkowitz gl...@twistedmatrix.comwrote: On Jul 29, 2011, at 3:00 PM, Matt wrote: I don't see any real reason to drop a decent piece of code (HTMLParser, that is) in favor of a third party library when only relatively minor updates are needed to bring it up to speed with the latest spec. I am not really one to throw stones here, as Twisted contains a lenient pseudo-XML parser which I still maintain - one which decidedly does *not* agree with html5's requirements for dealing with invalid data, but just a bunch of ad-hoc guesses of my own. My impression of HTML5 is that HTMLParser would require significant modifications and possibly a drastic re-architecture in order to really do HTML5 right; especially the parts that the html5lib authors claim makes HTML5 streaming-unfriendly, i.e. subtree reordering when encountering certain types of invalid data. We could also have the code live side-by-side for a while (or indefinitely if that was really desired) by bringing html5lib in as either a separate module or having the relevant classes live in htmllib under different names. But all of this is just hypothetical until someone decides to do the legwork to actually make a proposal and get the coding done. -Brett But if I'm wrong about that, and there are just a few spec updates and bugfixes that need to be applied, by all means, ignore my comment. -glyph ___ 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/brett%40python.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] Convention on functions that shadow existing stdlib functions
On Fri, 29 Jul 2011 11:51:18 -0400 Barry Warsaw ba...@python.org wrote: On Jul 29, 2011, at 05:25 PM, Antoine Pitrou wrote: test.support *is* part of the stdlib. We have lots of internal APIs which are not documented, though. And test.support *is* for internal use. The solution then is to rename test.support to test._support to make it clear it's an internal implementation detail. Then you can remove the entire section from the stdlib docs and just document it in the code. Ideally so. Practically, it's a lot of churn and additional pain merging 3.2 bugfixes into default. The lack of an underscore doesn't always mean the API is public, because it hasn't always worked like this (we have many private APIs without an underscore). 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] cpython (3.2): Stop ignoring Mercurial merge conflits files (#12255).
On Fri, 29 Jul 2011 12:19:45 -0400 R. David Murray rdmur...@bitdance.com wrote: Besides, hg status is meant to show untracked files which could *potentially* be tracked. It's not like anybody wants to track .orig and .rej files, so having them in the ignore list is still the right thing to do. That's one view. My view is that 'hg status' tells me all the files that have appeared in my tree that I'm either not currently tracking or explicitly ignoring (because the project's automated tools will deal with them). Nothing in there about limiting it to files I *might* want to track. That is how I've always used my version control systems. Ok, I understand. However, it also makes things more tedious for other people who don't user their VCS in such a way, so it would be nice how other people feel about this. 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] HTMLParser and HTML5
On Fri, 29 Jul 2011 13:34:13 -0700 Brett Cannon br...@python.org wrote: On Fri, Jul 29, 2011 at 13:16, Glyph Lefkowitz gl...@twistedmatrix.comwrote: On Jul 29, 2011, at 3:00 PM, Matt wrote: I don't see any real reason to drop a decent piece of code (HTMLParser, that is) in favor of a third party library when only relatively minor updates are needed to bring it up to speed with the latest spec. I am not really one to throw stones here, as Twisted contains a lenient pseudo-XML parser which I still maintain - one which decidedly does *not* agree with html5's requirements for dealing with invalid data, but just a bunch of ad-hoc guesses of my own. My impression of HTML5 is that HTMLParser would require significant modifications and possibly a drastic re-architecture in order to really do HTML5 right; especially the parts that the html5lib authors claim makes HTML5 streaming-unfriendly, i.e. subtree reordering when encountering certain types of invalid data. We could also have the code live side-by-side for a while (or indefinitely if that was really desired) by bringing html5lib in as either a separate module or having the relevant classes live in htmllib under different names. Unless html5lib is better in some fundamental ways which are difficult to fix in htmllib, I'm not sure there's any point in adding it to the stdlib. We don't really do users a service if we keep adding alternative APIs for common functionality. 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] Convention on functions that shadow existing stdlib functions
On 7/29/2011 11:18 AM, Barry Warsaw wrote: I'd much rather solve this problem by adding markup to functions that explicitly disclaim our normal backward compatibility guarantees. I suggested adding a footnote marker (1) to each one. test.support *is* part of the stdlib. So once again, is this a real actual problem you've witnessed in enough cases to go through all the trouble of moving the documentation, and making it more difficult to find? I agree with this. When working on tests, I would prefer to have test.support doc in the same offine doc set as unittest docs. I only supported *moving* as an alternative to *deleting*. Terry J. 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] Convention on functions that shadow existing stdlib functions
On 7/29/2011 11:25 AM, Antoine Pitrou wrote: t We have lots of internal APIs which are not documented, though. They are generally used only within the module itself as helper functions. So one only needs to even know about them when looking at the module code. And test.support *is* for internal use. No, the stuff in there is *not* for internal use within the module but for external use is possiby every test module. Terry J. 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] Convention on functions that shadow existing stdlib functions
On Fri, 29 Jul 2011 18:47:07 -0400 Terry Reedy tjre...@udel.edu wrote: And test.support *is* for internal use. No, the stuff in there is *not* for internal use within the module but for external use is possiby every test module. I meant internal use for us. Really, whether or not it's used cross-module is irrelevant. 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] Convention on functions that shadow existing stdlib functions
On 7/29/2011 5:32 PM, Antoine Pitrou wrote: On Fri, 29 Jul 2011 11:51:18 -0400 Barry Warsawba...@python.org wrote: On Jul 29, 2011, at 05:25 PM, Antoine Pitrou wrote: test.support *is* part of the stdlib. We have lots of internal APIs which are not documented, though. And test.support *is* for internal use. The solution then is to rename test.support to test._support to make it clear it's an internal implementation detail. Then you can remove the entire section from the stdlib docs and just document it in the code. Ideally so. The effect of this will be to discourage new people (including myself in the category) from writing or reviewing patches. 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] Convention on functions that shadow existing stdlib functions
On Fri, 29 Jul 2011 19:02:32 -0400 Terry Reedy tjre...@udel.edu wrote: On 7/29/2011 5:32 PM, Antoine Pitrou wrote: On Fri, 29 Jul 2011 11:51:18 -0400 Barry Warsawba...@python.org wrote: On Jul 29, 2011, at 05:25 PM, Antoine Pitrou wrote: test.support *is* part of the stdlib. We have lots of internal APIs which are not documented, though. And test.support *is* for internal use. The solution then is to rename test.support to test._support to make it clear it's an internal implementation detail. Then you can remove the entire section from the stdlib docs and just document it in the code. Ideally so. The effect of this will be to discourage new people (including myself in the category) from writing or reviewing patches. I'm sorry, can you be more precise. The effect of what? And why would that be so? ___ 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] cpython (3.2): Stop ignoring Mercurial merge conflits files (#12255).
Antoine Pitrou solip...@pitrou.net writes: Besides, hg status is meant to show untracked files which could *potentially* be tracked. And if you don't want to track them, you need to deal with them somehow. It's not like anybody wants to track .orig and .rej files, so having them in the ignore list is still the right thing to do. No, because their appearance in the working tree means something needs to be dealt with by the programmer. That's unlike other files which are generated and *don't* need to be dealt with by the programmer (or can be deterministically regenerated at will), so can safely be ignored. -- \ “When I was a kid I used to pray every night for a new bicycle. | `\Then I realised that the Lord doesn't work that way so I stole | _o__) one and asked Him to forgive me.” —Emo Philips | Ben Finney ___ 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] cpython (3.2): Stop ignoring Mercurial merge conflits files (#12255).
On Fri, 29 Jul 2011 23:36:03 +0200, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 29 Jul 2011 12:19:45 -0400 R. David Murray rdmur...@bitdance.com wrote: Besides, hg status is meant to show untracked files which could *potentially* be tracked. It's not like anybody wants to track .orig and .rej files, so having them in the ignore list is still the right thing to do. That's one view. My view is that 'hg status' tells me all the files that have appeared in my tree that I'm either not currently tracking or explicitly ignoring (because the project's automated tools will deal with them). Nothing in there about limiting it to files I *might* want to track. That is how I've always used my version control systems. Ok, I understand. However, it also makes things more tedious for other people who don't user their VCS in such a way, so it would be nice how other people feel about this. They can add those files to their personal .hgrc. I can't *remove* those ignores via mine. -- R. David Murray http://www.bitdance.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] cpython (3.2): Stop ignoring Mercurial merge conflits files (#12255).
On Fri, Jul 29, 2011 at 7:22 PM, R. David Murray rdmur...@bitdance.com wrote: On Fri, 29 Jul 2011 23:36:03 +0200, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 29 Jul 2011 12:19:45 -0400 R. David Murray rdmur...@bitdance.com wrote: Besides, hg status is meant to show untracked files which could *potentially* be tracked. It's not like anybody wants to track .orig and .rej files, so having them in the ignore list is still the right thing to do. That's one view. My view is that 'hg status' tells me all the files that have appeared in my tree that I'm either not currently tracking or explicitly ignoring (because the project's automated tools will deal with them). Nothing in there about limiting it to files I *might* want to track. That is how I've always used my version control systems. Ok, I understand. However, it also makes things more tedious for other people who don't user their VCS in such a way, so it would be nice how other people feel about this. They can add those files to their personal .hgrc. I can't *remove* those ignores via mine. Well, *I* don't ever want to check in .orig or .rej files (because various tools create them) so I want them in my .hgignore file. Here's a sample .hgignore file I carry around with me: http://code.google.com/p/appengine-ndb-experiment/source/browse/.hgignore -- --Guido van Rossum (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] the history of tests being inside Lib/ in Python
The other thread had some claims (*) that made me wonder - why are the tests in Python kept in Lib/ at all? AFAIK, this is rather an unusual project structure. Tests usually have a top-level directory of their own, in parallel to Lib/, Doc/ and others. Some effects of this in other projects: * The tests usually aren't even installed. The user can run them during installation, but once it goes through, tests are not copied into /usr/whatever... * Tests naturally become developer-domain, removed from the user-domain. No sane user would even consider using code from inside the Tests/ directory and somehow expect it to keep working in later versions. In addition, tests are then usually documented in special hacking guides and developer docs instead of in the official documentation of the project. This mail can appear as if advocating the transfer of Lib/test into Tests/, but this is not my intention here. Honest :-) I'm just trying to understand the history and rationale behind this structure in the CPython project. Eli (*) I refer to this reasoning someone raised: test.support is part of the tests + tests are part of stdlib -- test.support must be documented where the rest of stdlib is ___ 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] the history of tests being inside Lib/ in Python
2011/7/29 Eli Bendersky eli...@gmail.com: The other thread had some claims (*) that made me wonder - why are the tests in Python kept in Lib/ at all? AFAIK, this is rather an unusual project structure. Not really. It seems to be about half/half to me. -- 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] the history of tests being inside Lib/ in Python
On Sat, Jul 30, 2011 at 06:36, Benjamin Peterson benja...@python.orgwrote: 2011/7/29 Eli Bendersky eli...@gmail.com: The other thread had some claims (*) that made me wonder - why are the tests in Python kept in Lib/ at all? AFAIK, this is rather an unusual project structure. Not really. It seems to be about half/half to me. I guess I'm mis-informed then :) Out of curiosity, could you point to a few projects that also place tests inside their code? Eli ___ 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] the history of tests being inside Lib/ in Python
In article CAF-Rda-M5QL3bhzAcf2d=0u94qdr_-u_kvprai9hwzkhtkh...@mail.gmail.com, Eli Bendersky eli...@gmail.com wrote: * The tests usually aren't even installed. The user can run them during installation, but once it goes through, tests are not copied into /usr/whatever... That's not true across the board. For instance, the python.org Mac OS X installers do install the tests permanently and, with the addition of the -m test (or -m test.regrtest in 2.7) command line options, the tests can be easily run at any time on the end user's system. That's one of the reasons why it is important that additions and changes to the tests need to ensure that auxiliary directories and files are installed by the Makefile install targets and not just resident in the build directory. -- Ned Deily, n...@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] the history of tests being inside Lib/ in Python
On Fri, Jul 29, 2011 at 8:44 PM, Eli Bendersky eli...@gmail.com wrote: On Sat, Jul 30, 2011 at 06:36, Benjamin Peterson benja...@python.org wrote: 2011/7/29 Eli Bendersky eli...@gmail.com: The other thread had some claims (*) that made me wonder - why are the tests in Python kept in Lib/ at all? AFAIK, this is rather an unusual project structure. Not really. It seems to be about half/half to me. I guess I'm mis-informed then :) Out of curiosity, could you point to a few projects that also place tests inside their code? You're asking too many questions. Please do some research of your own. Really, this isn't going to change, and asking why it is so or stating that it is rather unusual is just going to irritate the experienced developers. If you want a friendlier answer, please sign up for core-mentors...@python.org, where asking questions about why or why not are welcome. -- --Guido van Rossum (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] the history of tests being inside Lib/ in Python
2011/7/29 Eli Bendersky eli...@gmail.com: On Sat, Jul 30, 2011 at 06:36, Benjamin Peterson benja...@python.org wrote: 2011/7/29 Eli Bendersky eli...@gmail.com: The other thread had some claims (*) that made me wonder - why are the tests in Python kept in Lib/ at all? AFAIK, this is rather an unusual project structure. Not really. It seems to be about half/half to me. I guess I'm mis-informed then :) Out of curiosity, could you point to a few projects that also place tests inside their code? Twisted, PyPy, simplejson, Bazaar, buildbot, pyramid, SAGE, Jinja2, Portage, pylint, and Tahoe-LAFS for starters. -- 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] cpython: make the types of None and Ellipsis callable
Am 30.07.2011 01:20, schrieb benjamin.peterson: http://hg.python.org/cpython/rev/84c3be27b4c7 changeset: 71614:84c3be27b4c7 parent: 71611:a6afd26caa8a user:Benjamin Peterson benja...@python.org date:Fri Jul 29 18:19:43 2011 -0500 summary: make the types of None and Ellipsis callable files: Lib/test/test_builtin.py | 7 + Misc/NEWS| 3 ++ Objects/object.c | 34 Objects/sliceobject.c| 29 +++ 4 files changed, 73 insertions(+), 0 deletions(-) Shouldn't there be a matching Doc change somewhere? Georg ___ 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
