On Wed, Nov 17, 2010 at 2:34 AM, exar...@twistedmatrix.com 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
On 17/11/2010 11:45, Nick Coghlan wrote:
On Wed, Nov 17, 2010 at 2:34 AM,exar...@twistedmatrix.com 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
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
-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; generally,
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 that ?
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
2010/11/17 Michael Foord fuzzy...@voidspace.org.uk:
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.
2010/11/17 Michael Foord fuzzy...@voidspace.org.uk:
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
On 17/11/2010 13:21, Fred Drake wrote:
2010/11/17 Michael Foordfuzzy...@voidspace.org.uk:
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
On Wed, Nov 17, 2010 at 13:51, Jesus Cea j...@jcea.es 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.
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 11:21 PM, Fred Drake fdr...@acm.org wrote:
2010/11/17 Michael Foord fuzzy...@voidspace.org.uk:
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
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
2010/11/17 Oleg Broytman p...@phd.pp.ru:
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
On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlan ncogh...@gmail.com 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,
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
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
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 emile.anc...@logilab.fr
http://www.logilab.fr/
Ł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
On Wed, Nov 17, 2010 at 11:45 PM, Fred Drake fdr...@acm.org wrote:
On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlan ncogh...@gmail.com 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
On Wed, 17 Nov 2010 07:36:37 -0600, Benjamin Peterson benja...@python.org
wrote:
2010/11/17 Oleg Broytman p...@phd.pp.ru:
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
On 17/11/2010 14:19, Nick Coghlan wrote:
On Wed, Nov 17, 2010 at 11:45 PM, Fred Drakefdr...@acm.org wrote:
On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlanncogh...@gmail.com wrote:
The library documentation is *not* the right place for quibbling about
what constitutes a public API when using
-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.
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
On Wed, 17 Nov 2010 15:31:02 +0100
Jesus Cea j...@jcea.es 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
On Thu, Nov 18, 2010 at 12:25 AM, Michael Foord
fuzzy...@voidspace.org.uk 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
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 benja...@python.org
wrote:
2010/11/17 Oleg Broytman p...@phd.pp.ru:
Seems to be rather a usage question, not a development question
(python-dev
is about
On Thu, Nov 18, 2010 at 12:31 AM, Jesus Cea j...@jcea.es 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
-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't want
On Thu, Nov 18, 2010 at 12:58 AM, Nick Coghlan ncogh...@gmail.com 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
On Wed, Nov 17, 2010 at 9:19 AM, Nick Coghlan ncogh...@gmail.com 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
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 7:24 AM, James Y Knight f...@fuhm.net 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
On Tue, Nov 16, 2010 at 1:31 PM, Ben Finney ben+pyt...@benfinney.id.au 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
-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
On Wed, 17 Nov 2010 17:07:02 +0100
Jesus Cea j...@jcea.es 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
On Nov 17, 2010, at 10:30 AM, Guido van Rossum wrote:
On Wed, Nov 17, 2010 at 7:24 AM, James Y Knight f...@fuhm.net 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
On Wed, Nov 17, 2010 at 8:23 AM, James Y Knight f...@fuhm.net 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 f...@fuhm.net wrote:
On Nov 17, 2010, at 9:19 AM, Nick Coghlan wrote:
(and is a little trickier in the case of module level
-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
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 better
¿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
-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. My mail
Jesus Cea j...@jcea.es 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,
On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlan ncogh...@gmail.com 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
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
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
On Thu, Nov 18, 2010 at 7:08 AM, Éric Araujo mer...@netwok.org 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
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 available like
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
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 miss open.
On Wed, Nov 17, 2010 at 4:22 PM, Georg Brandl g.bra...@gmx.net 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
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
Am 17.11.2010 22:39, schrieb Fred Drake:
On Wed, Nov 17, 2010 at 4:22 PM, Georg Brandl g.bra...@gmx.net 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
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
Steven D'Aprano st...@pearwood.info 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)
On Wed, Nov 17, 2010 at 5:08 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Steven D'Aprano st...@pearwood.info 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
56 matches
Mail list logo
