Am 29.07.2011 11:26, schrieb Barry Warsaw:
> 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 tha
Hi Senthil,
> +if source_address: self.source_address = source_address
Could you try to follow PEP 8?
(I know PEP 8 is not always followed in old code, but there's no reason
not to follow it in code that we add to the stdlib)
> +SMTP.__init__(self, host, port, local_hostname = l
On Fri, 29 Jul 2011 22:22:05 -0400
"R. David Murray" wrote:
> On Fri, 29 Jul 2011 23:36:03 +0200, Antoine Pitrou
> wrote:
> > On Fri, 29 Jul 2011 12:19:45 -0400
> > "R. David Murray" wrote:
> > >
> > > > Besides, "hg status" is meant to show untracked files which could
> > > > *potentially* b
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
> date:Fri Jul 29 18:19:43 2011 -0500
> summary:
> make the types of None and Ellipsis call
2011/7/29 Eli Bendersky :
>
> On Sat, Jul 30, 2011 at 06:36, Benjamin Peterson
> wrote:
>>
>> 2011/7/29 Eli Bendersky :
>> > 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 stru
On Fri, Jul 29, 2011 at 8:44 PM, Eli Bendersky wrote:
>
> On Sat, Jul 30, 2011 at 06:36, Benjamin Peterson
> wrote:
>>
>> 2011/7/29 Eli Bendersky :
>> > The other thread had some claims (*) that made me wonder - why are the
>> > tests
>> > in Python kept in Lib/ at all?
>> >
>> > AFAIK, this is r
In article
,
Eli Bendersky 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
On Sat, Jul 30, 2011 at 06:36, Benjamin Peterson wrote:
> 2011/7/29 Eli Bendersky :
> > 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
2011/7/29 Eli Bendersky :
> 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
_
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:
* Th
On Fri, Jul 29, 2011 at 7:22 PM, R. David Murray wrote:
> On Fri, 29 Jul 2011 23:36:03 +0200, Antoine Pitrou
> wrote:
>> On Fri, 29 Jul 2011 12:19:45 -0400
>> "R. David Murray" wrote:
>> >
>> > > Besides, "hg status" is meant to show untracked files which could
>> > > *potentially* be tracked.
On Fri, 29 Jul 2011 23:32:57 +0200, Antoine Pitrou wrote:
> On Fri, 29 Jul 2011 11:51:18 -0400
> Barry Warsaw 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.
On Fri, 29 Jul 2011 23:36:03 +0200, Antoine Pitrou wrote:
> On Fri, 29 Jul 2011 12:19:45 -0400
> "R. David Murray" 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, s
Antoine Pitrou 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 sti
On Fri, 29 Jul 2011 19:02:32 -0400
Terry Reedy wrote:
> On 7/29/2011 5:32 PM, Antoine Pitrou wrote:
> > On Fri, 29 Jul 2011 11:51:18 -0400
> > Barry Warsaw wrote:
> >> On Jul 29, 2011, at 05:25 PM, Antoine Pitrou wrote:
> >>
> test.support *is* part of the stdlib.
> >>>
> >>> We have lots of
On 7/29/2011 5:32 PM, Antoine Pitrou wrote:
On Fri, 29 Jul 2011 11:51:18 -0400
Barry Warsaw 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
On Fri, 29 Jul 2011 18:47:07 -0400
Terry Reedy 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-mo
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 int
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
On Fri, 29 Jul 2011 13:34:13 -0700
Brett Cannon wrote:
> On Fri, Jul 29, 2011 at 13:16, Glyph Lefkowitz wrote:
>
> > 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 re
On Fri, 29 Jul 2011 12:19:45 -0400
"R. David Murray" 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.
>
On Fri, 29 Jul 2011 11:51:18 -0400
Barry Warsaw 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
On Fri, Jul 29, 2011 at 13:16, Glyph Lefkowitz wrote:
> 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
On Fri, Jul 29, 2011 at 11:31, Tres Seaver 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
> >
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 Thu, Jul 28, 2011 at 09:55, raymond.hettinger wrote:
> http://hg.python.org/cpython/rev/ccce01988603
> changeset: 71542:ccce01988603
> user:Raymond Hettinger
> date:Thu Jul 28 09:55:13 2011 -0700
> summary:
> Issue 12647: Add __bool__() method to the None object.
>
> files:
On Fri, Jul 29, 2011 at 11:03 AM, Glyph Lefkowitz
wrote:
>
> 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, Mat
On Fri, 29 Jul 2011 11:49:01 -0400, Barry Warsaw 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
-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
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 w
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 si
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
On Fri, Jul 29, 2011 at 8:37 AM, Nick Coghlan wrote:
> On Sat, Jul 30, 2011 at 1:17 AM, Antoine Pitrou wrote:
>> On Thu, 28 Jul 2011 11:28:43 +0200
>> Victor Stinner wrote:
>>>
>>> I will add your alternative to the PEP (except if you would like to do
>>> that yourself?). If I understood correct
On Fri, 29 Jul 2011 16:49:35 +0200, Antoine Pitrou wrote:
> On Fri, 29 Jul 2011 16:21:42 +0200 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.
On Fri, 29 Jul 2011 11:18:37 -0400, Barry Warsaw 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. Le
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 wit
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 i
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 standa
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
On Sat, Jul 30, 2011 at 1:17 AM, Antoine Pitrou wrote:
> On Thu, 28 Jul 2011 11:28:43 +0200
> Victor Stinner 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.
On Sat, Jul 30, 2011 at 1:32 AM, Nick Coghlan 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
On Sat, Jul 30, 2011 at 1:18 AM, Barry Warsaw wrote:
> On Jul 29, 2011, at 02:07 PM, Eli Bendersky wrote:
>>I think the unlink&rmtree 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 in
Barry Warsaw wrote:
On Jul 29, 2011, at 02:07 PM, Eli Bendersky wrote:
I think the unlink&rmtree 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 g
On Fri, 29 Jul 2011 11:18:37 -0400
Barry Warsaw 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-obscur
On Thu, 28 Jul 2011 11:28:43 +0200
Victor Stinner 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
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 Fri, Jul 29, 2011 at 7:26 PM, Barry Warsaw 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
On Fri, 29 Jul 2011 15:22:08 +0200
Éric Araujo 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 t
On Fri, 29 Jul 2011 16:21:42 +0200
Éric Araujo 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 tha
On Fri, 29 Jul 2011 15:38:31 +0200, Antoine Pitrou wrote:
> On Fri, 29 Jul 2011 15:28:44 +0200 > Ãric Araujo 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,
>> 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 c
On Fri, 29 Jul 2011 15:28:44 +0200, =?UTF-8?B?w4lyaWMgQXJhdWpv?=
wrote:
> Le 29/07/2011 14:50, Antoine Pitrou a écrit :
> >> changeset: 71562:bdad5bc9a2ed
> >> user:Ãric Araujo
> >> 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
>> 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
On Fri, 29 Jul 2011 15:28:44 +0200
Éric Araujo wrote:
> Le 29/07/2011 14:50, Antoine Pitrou a écrit :
> >> changeset: 71562:bdad5bc9a2ed
> >> user:Éric Araujo
> >> summary:
> >> Stop ignoring Mercurial merge conflits files (#12255).
> >>
> >> R. David Murray and I think that it’s more
Le 29/07/2011 14:50, Antoine Pitrou a écrit :
>> changeset: 71562:bdad5bc9a2ed
>> user:Éric Araujo
>> 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”,
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).
Ind
On Fri, 29 Jul 2011 14:35:24 +0200
eric.araujo wrote:
> http://hg.python.org/cpython/rev/bdad5bc9a2ed
> changeset: 71562:bdad5bc9a2ed
> branch: 3.2
> user:Éric Araujo
> date:Thu Jul 28 22:45:46 2011 +0200
> summary:
> Stop ignoring Mercurial merge conflits files (#12255).
On Fri, Jul 29, 2011 at 2:46 PM, Antoine Pitrou 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:23 +0200
eric.araujo 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
On Fri, 29 Jul 2011 14:35:19 +0200
eric.araujo wrote:
> http://hg.python.org/cpython/rev/97527f3f9829
> changeset: 71555:97527f3f9829
> branch: 3.2
> user:Éric Araujo
> date:Tue Jul 26 17:32:50 2011 +0200
> summary:
> Fix sorting or wording of some NEWS entries.
>
> I wo
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 t
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 bey
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 n
> >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
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 s
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 referenc
On Fri, Jul 29, 2011 at 4:52 PM, Eli Bendersky wrote:
> On Fri, Jul 29, 2011 at 08:48, Nick Coghlan wrote:
>>
>> On Fri, Jul 29, 2011 at 3:24 PM, Eli Bendersky 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 acc
On Fri, Jul 29, 2011 at 08:48, Nick Coghlan wrote:
> On Fri, Jul 29, 2011 at 3:24 PM, Eli Bendersky 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 sayi
68 matches
Mail list logo
