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
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
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
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
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
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
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
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
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
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
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
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.
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
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,
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
-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
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
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,
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__()
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,
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
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
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
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
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
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,
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
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
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*
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
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
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
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
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:
*
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
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
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
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
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
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
65 matches
Mail list logo
