On Wed, Nov 17, 2010 at 5:08 PM, Ben Finney wrote:
> Steven D'Aprano writes:
>
>> 3. Treat "documented" and "public" as orthogonal, not synonymous:
>> undocumented public API is not an oxymoron, and neither is documented
>> private API.
>
> +1
>
>> The use of imported modules is possibly an excep
Steven D'Aprano writes:
> 3. Treat "documented" and "public" as orthogonal, not synonymous:
> undocumented public API is not an oxymoron, and neither is documented
> private API.
+1
> The use of imported modules is possibly an exception. If a user is
> writing something like (say) getopt.os.get
Nick Coghlan wrote:
The policy we're aiming to clarify here is what we should do when we
come across standard library APIs that land in the grey area, with
there being two appropriate ways to deal with them:
1. Document them and make them officially public
2. Deprecate the public names and make
Am 17.11.2010 22:39, schrieb Fred Drake:
> On Wed, Nov 17, 2010 at 4:22 PM, Georg Brandl wrote:
>> So it comes down again to what we'd like __all__ to mean foremost:
>> public API, or just a list for "import *"?
>
> It is and has been since its inception *the* list for "import *".
>
> Any additi
Hello,
I would like to announce that, following Guido's (private) suggestion
that I find a temporary dictator for PEP 3151, Barry has accepted to
fill in this role.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
On Wed, Nov 17, 2010 at 4:22 PM, Georg Brandl wrote:
> So it comes down again to what we'd like __all__ to mean foremost:
> public API, or just a list for "import *"?
It is and has been since its inception *the* list for "import *".
Any additional meaning will have to accommodate that usage as w
Am 17.11.2010 22:16, schrieb Éric Araujo:
>> Excluding a builtin name from __all__ sounds like a perfectly sensible
>> idea, so even if it wasn't deliberate, I'd say it qualifies as
>> fortuitous :)
>
> But then, a tool that looks into __all__ to find for example what
> objects to document will mi
> Excluding a builtin name from __all__ sounds like a perfectly sensible
> idea, so even if it wasn't deliberate, I'd say it qualifies as
> fortuitous :)
But then, a tool that looks into __all__ to find for example what
objects to document will miss open. I’d put open in __all__.
Regards
__
I see now that my previous reply went only to Stefan, so I'm re-submitting,
this time to the list.
> -Original Message-
> From: Stefan Behnel
> Sent: Saturday, 04 September, 2010 04:29
>
> What about adding an intermediate namespace called "cache", so that
> the new operations are availab
On Thu, Nov 18, 2010 at 7:08 AM, Éric Araujo wrote:
>> We may also revisit the rules used by help() to decide what to include
>> on the auto-generated module implementation. Note that currently
>> help() output excludes names not in __all__ is the module has __all__
>> defined. While I advocated
> We may also revisit the rules used by help() to decide what to include
> on the auto-generated module implementation. Note that currently
> help() output excludes names not in __all__ is the module has __all__
> defined. While I advocated this rule earlier in this thread, I now
> Consider the r
On 11/17/2010 10:52 AM, Guido van Rossum wrote:
That's not what I meant. In the case of style guides I think it is
totally appropriate to update the PEP as new rules are developed or
existing ones are clarified (or even changed).
Revising style guides is standard practice. The Chicago Manual o
On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlan wrote:
..
> The library documentation is *not* the right place for quibbling about
> what constitutes a public API when using other means than the library
> documentation to find APIs to call.
>
+1
People who bother to read the Library Reference most
Jesus Cea wrote:
> On 17/11/10 17:23, Antoine Pitrou wrote:
> > There is no incoming connection; however, a bunch of outgoing
> > connections are made to various hosts by various tests, so it's better
> > if there's no overzealous firewall in-between.
For those of us who can't do that, there's a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/11/10 18:10, Antoine Pitrou wrote:
>>
>> ¿Could you provide the connection credential?. I rather prefer to skip
>> the IRC (I am a XMPP guy), but I can connect to freenode if you need it.
>
> I've already sent you a private e-mail.
OK. Sorry. M
>
> ¿Could you provide the connection credential?. I rather prefer to skip
> the IRC (I am a XMPP guy), but I can connect to freenode if you need it.
I've already sent you a private e-mail.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
On Nov 17, 2010, at 11:38 AM, Guido van Rossum wrote:
> Deprecation doesn't *require* logging a warning or raising an
> exception. You can also add a note to the docs, or if it is
> undocumented, just add a comment to the code. (Though if it is in
> widespread use despite being undocumented, a bett
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/11/10 17:23, Antoine Pitrou wrote:
> There is no incoming connection; however, a bunch of outgoing
> connections are made to various hosts by various tests, so it's better
> if there's no overzealous firewall in-between.
I know that, just confir
On Wed, Nov 17, 2010 at 8:23 AM, James Y Knight wrote:
> On Nov 17, 2010, at 10:30 AM, Guido van Rossum wrote:
>> On Wed, Nov 17, 2010 at 7:24 AM, James Y Knight wrote:
>>> On Nov 17, 2010, at 9:19 AM, Nick Coghlan wrote:
(and is a little trickier in the case of module level globals, since t
On Nov 17, 2010, at 10:30 AM, Guido van Rossum wrote:
> On Wed, Nov 17, 2010 at 7:24 AM, James Y Knight wrote:
>> On Nov 17, 2010, at 9:19 AM, Nick Coghlan wrote:
>>> (and is a little trickier in the case of module level globals, since those
>>> can't be deprecated properly)
>>
>> People keep sa
On Wed, 17 Nov 2010 17:07:02 +0100
Jesus Cea wrote:
>
> I am reading http://wiki.python.org/moin/BuildBot . I have installed
> buildbotslave already, but I need passwords, etc., to link to python
> buildbot infraestructure.
>
> The machine is behind a NAT system, so any incoming connection will
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, everybody.
I am glad to say I am installing an OpenIndiana zone (Openindiana is a
fork of Indiana, a distribution of OpenSolaris) with the aim to be a
buildbot for python development.
This machine has plenty of disk (even SSD!), CPU and memory fo
On Tue, Nov 16, 2010 at 1:31 PM, Ben Finney wrote:
> I don't know about Guido, but I'd be -1 on suggestions to add more
> normative information to PEP 7, PEP 8, PEP 257, or any other established
> style guide PEP. I certainly don't want to have to keep going back to
> the same documents frequently
On Wed, Nov 17, 2010 at 7:24 AM, James Y Knight wrote:
> On Nov 17, 2010, at 9:19 AM, Nick Coghlan wrote:
>> (and is a little trickier in the case of module level globals, since those
>> can't be deprecated properly)
>
> People keep saying this, but there have already been examples shown of how t
On Nov 17, 2010, at 9:19 AM, Nick Coghlan wrote:
> (and is a little trickier in the case of module level globals, since those
> can't be deprecated properly)
People keep saying this, but there have already been examples shown of how to
do it. I actually think that python should include a way to
On Wed, Nov 17, 2010 at 9:19 AM, Nick Coghlan wrote:
..
> The standard library documentation should say that the public API is
> what the documentation says it is. Officially, anyone going outside
> those documented APIs should not be surprised if things get removed or
> changed arbitrarily withou
On Thu, Nov 18, 2010 at 12:58 AM, Nick Coghlan wrote:
> For what Amaury is talking about, what you can test is that the higher
> layers of the IO stack (e.g. BufferedReader) correctly pass the new
> flags down to the RawIO layer. You're correct that you can't really
> test that RawIO is actually p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/17/2010 09:16 AM, Steven D'Aprano wrote:
> Ben Finney wrote:
>
>> I don't know about Guido, but I'd be −1 on suggestions to add more
>> normative information to PEP 7, PEP 8, PEP 257, or any other established
>> style guide PEP. I certainly don'
On Thu, Nov 18, 2010 at 12:31 AM, Jesus Cea wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all. I am modifying IO module for Python 3.2, and I am unable to
> understand the mechanism used in IO testsuite to test both the C and the
> Python implementation.
>
> In particular I need
On Wed, Nov 17, 2010 at 09:19:35AM -0500, R. David Murray wrote:
> On Wed, 17 Nov 2010 07:36:37 -0600, Benjamin Peterson
> wrote:
> > 2010/11/17 Oleg Broytman :
> > > Seems to be rather a usage question, not a development question
> > > (python-dev
> > > is about *developing* python, not *using*
On Thu, Nov 18, 2010 at 12:25 AM, Michael Foord
wrote:
> We're *also* discussing codifying the naming conventions (or using __all__)
> within the standard library, so it isn't just about deprecations (which is
> why I think PEP 8 rather than PEP 5). This is so that in the future if a
> name looks
On Wed, 17 Nov 2010 15:31:02 +0100
Jesus Cea wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all. I am modifying IO module for Python 3.2, and I am unable to
> understand the mechanism used in IO testsuite to test both the C and the
> Python implementation.
>
> In particular I ne
The lists of Meta-PEPs and Other Informational PEPs at the beginning
of PEP 0 are starting to get a little long, and contain some outdated
information that doesn't really deserve pride of place at the top of
the PEP index.
If I don't hear any objections in this thread, I plan to make the
following
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all. I am modifying IO module for Python 3.2, and I am unable to
understand the mechanism used in IO testsuite to test both the C and the
Python implementation.
In particular I need to test that the implementation passes some
parameters to the OS.
On 17/11/2010 14:19, Nick Coghlan wrote:
On Wed, Nov 17, 2010 at 11:45 PM, Fred Drake wrote:
On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlan wrote:
The library documentation is *not* the right place for quibbling about
what constitutes a public API when using other means than the library
docume
On Wed, 17 Nov 2010 07:36:37 -0600, Benjamin Peterson
wrote:
> 2010/11/17 Oleg Broytman :
> > Seems to be rather a usage question, not a development question (python-dev
> > is about *developing* python, not *using* it).
>
> Well, technically I think it's a feature request.
>
> >
> > On Wed, No
On Wed, Nov 17, 2010 at 11:45 PM, Fred Drake wrote:
> On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlan wrote:
>> The library documentation is *not* the right place for quibbling about
>> what constitutes a public API when using other means than the library
>> documentation to find APIs to call.
>
>
Łukasz Langa wrote:
Mutating PEP8 is bad form. We fight mercilessly over source code
backwards compatibility so I think PEPs should be taken just as
seriously in that regard.
There's no comparison between the two.
If you change your library's API -- not "source code", it doesn't matter
if t
On Wednesday 17 November 2010 14:36:37 Benjamin Peterson wrote:
> I wouldn't object to adding them back if you want to file a bug report.
Ok, thank you for quick reply.
here is the issue : http://bugs.python.org/issue10445
--
Emile Anclin
http://www.logilab.fr/ http://www.logilab.org/
Info
Ben Finney wrote:
I don't know about Guido, but I'd be −1 on suggestions to add more
normative information to PEP 7, PEP 8, PEP 257, or any other established
style guide PEP. I certainly don't want to have to keep going back to
the same documents frequently just to see if the set of recommendati
On 17/11/2010 13:31, Łukasz Langa wrote:
Am 17.11.2010 14:11, schrieb Michael Foord:
I don't think those reasons are compelling and the cost of splitting
the Python development style guide into multiple documents are
higher. (They run the risk of contradicting each other, if you want
to find a
On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlan wrote:
> The library documentation is *not* the right place for quibbling about
> what constitutes a public API when using other means than the library
> documentation to find APIs to call.
Quibbling can happen on the mailing list, where it can be ign
2010/11/17 Oleg Broytman :
> Seems to be rather a usage question, not a development question (python-dev
> is about *developing* python, not *using* it).
Well, technically I think it's a feature request.
>
> On Wed, Nov 17, 2010 at 01:48:06PM +0100, Emile Anclin wrote:
>> hello everybody,
>>
>> m
Am 17.11.2010 14:11, schrieb Michael Foord:
I don't think those reasons are compelling and the cost of splitting
the Python development style guide into multiple documents are higher.
(They run the risk of contradicting each other, if you want to find a
particular rule you have multiple places
On Wed, Nov 17, 2010 at 11:21 PM, Fred Drake wrote:
> 2010/11/17 Michael Foord :
>> So -1 on splitting Python development style guide into multiple documents.
>
> I don't think that the publicness or API stability promises of the
> standard library are part of a style guide. They're an essential
Seems to be rather a usage question, not a development question (python-dev
is about *developing* python, not *using* it).
On Wed, Nov 17, 2010 at 01:48:06PM +0100, Emile Anclin wrote:
> hello everybody,
>
> migrating Pylint to python3.x, we encounter a little problem :
> in the tree generated by
On Wed, Nov 17, 2010 at 13:51, Jesus Cea wrote:
> I can't find the mail now, but I remember that months ago the Mercurial
> migration schedule was mid-december. I wonder if there is any update.
I'm still aiming for that date. I've had some problems getting the
test repository together. It's almos
On 17/11/2010 13:21, Fred Drake wrote:
2010/11/17 Michael Foord:
So -1 on splitting Python development style guide into multiple documents.
I don't think that the publicness or API stability promises of the
standard library are part of a style guide. They're an essential part
of the library do
2010/11/17 Michael Foord :
> I don't think those reasons are compelling and the cost of splitting the
> Python development style guide into multiple documents are higher. (They run
> the risk of contradicting each other, if you want to find a particular rule
> you have multiple places to check, the
2010/11/17 Michael Foord :
> So -1 on splitting Python development style guide into multiple documents.
I don't think that the publicness or API stability promises of the
standard library are part of a style guide. They're an essential part
of the library documentation. They aren't a guide for 3
On 17/11/2010 12:37, Łukasz Langa wrote:
Am 17.11.2010 12:57, schrieb Michael Foord:
On 17/11/2010 11:45, Nick Coghlan wrote:
The definition of the public/private policy in all its gory detail
should be in PEP 8 as Guido suggests.
+1
Guido did not said that, though.
I think that is a re
hello everybody,
migrating Pylint to python3.x, we encounter a little problem :
in the tree generated by _ast, if we consider a "args" node (representing
an argument of a function), the "lineno" (and the "col_offset")
information disappeared from those nodes. Is there a particular
reason for th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/11/10 08:18, Georg Brandl wrote:
> Am 16.11.2010 19:38, schrieb Jesus Cea:
>> Is there any updated mercurial schedule?.
>>
>> Any impact related with the new 3.2 schedule (three weeks offset)?
>
> I've been trying to contact Dirkjan and ask; gen
Am 17.11.2010 12:57, schrieb Michael Foord:
On 17/11/2010 11:45, Nick Coghlan wrote:
The definition of the public/private policy in all its gory detail
should be in PEP 8 as Guido suggests.
+1
Guido did not said that, though. I'm with Fred and other people that
agree that PEPs should be mo
On 17/11/2010 11:45, Nick Coghlan wrote:
On Wed, Nov 17, 2010 at 2:34 AM, wrote:
I don't think it belongs only in PEP 8 (that's "a style guide" you're
referring to, correct?). It needs to be front and center. This is
information that every single user of the stdlib needs in order to use the
s
On Wed, Nov 17, 2010 at 2:34 AM, wrote:
> I don't think it belongs only in PEP 8 (that's "a style guide" you're
> referring to, correct?). It needs to be front and center. This is
> information that every single user of the stdlib needs in order to use the
> stdlib correctly.
>
> Imagine trying
56 matches
Mail list logo
