2013/7/12 Andrea Griffini :
> Is there any semantic difference between
>
> BUILD_TUPLE 0
> LOAD_CONST
> MAKE_CLOSURE 0
>
> and
>
> LOAD_CONST
> MAKE_FUNCTION 0
>
> ?
>
> In other words is there any difference between a function and a closure that
> doesn't capture anything? Is
On Jul 14, 2013, at 6:32 AM, David Beazley wrote:
> I honestly don't have any particular thoughts about PLY vs. other parser
> generators and the merits of their inclusion (or not) in the standard
> library.
I would love to have PLY in the standard library.
It would open up a whole new world
Nick Coghlan writes:
>> Of course private modules are sane. I never suggested "no new private
>> modules at all". But putting them in the same namespace as public
>> modules is not, just to save a leading underscore in the file name.
> It's not to save a leading underscore - it's to avoid ren
On Mon, Jul 15, 2013 at 6:17 AM, Nick Coghlan wrote:
> =
> Private interfaces
>
> Unless explicitly documented otherwise, a leading underscore on any
> name indicates that it is an internal implementation detail and any
> backwards compatibility guarantees do not apply. It is stron
On 15 July 2013 02:15, Gregory P. Smith wrote:
> On Sun, Jul 14, 2013 at 4:09 AM, Nick Coghlan wrote:
>> as Python users may rely on introspection to identify available
>> functionality and may be misled into believing an API without a leading
>> underscore is in fact a public API with the standa
On 15 Jul 2013 13:46, "Steven D'Aprano" wrote:
>
> On Mon, Jul 15, 2013 at 10:01:17AM +1000, Cameron Simpson wrote:
> > On 15Jul2013 09:48, Steven D'Aprano wrote:
>
> > | I'd go further, and say that no more private modules should be
> > | accepted for the std lib unless they have a leading under
On 15 Jul 2013 13:43, "Steven D'Aprano" wrote:
>
> On Mon, Jul 15, 2013 at 10:30:02AM +1000, Nick Coghlan wrote:
> > On 15 July 2013 09:48, Steven D'Aprano wrote:
> > > On 14/07/13 21:09, Nick Coghlan wrote:
> > >
> > >> Slight adjustment to the proposed wording to ensure completely
> > >> undocu
On Mon, Jul 15, 2013 at 03:34:08PM +1200, Ben Hoyt wrote:
> Thanks, Nick -- that's helpful info. Writing such a PEP is a nice idea, but
> I think it'd be beyond me (I'm not familiar enough with CPython internals,
> protocols, etc).
>
> Can you explain what you mean by "symmetric protocol rather th
On Mon, Jul 15, 2013 at 10:01:17AM +1000, Cameron Simpson wrote:
> On 15Jul2013 09:48, Steven D'Aprano wrote:
> | I'd go further, and say that no more private modules should be
> | accepted for the std lib unless they have a leading underscore. I
> | suppose for backwards compatibility reasons,
On Mon, Jul 15, 2013 at 10:30:02AM +1000, Nick Coghlan wrote:
> On 15 July 2013 09:48, Steven D'Aprano wrote:
> > On 14/07/13 21:09, Nick Coghlan wrote:
> >
> >> Slight adjustment to the proposed wording to ensure completely
> >> undocumented
> >> modules are also considered private:
> >
> >
> > -
Thanks, Nick -- that's helpful info. Writing such a PEP is a nice idea, but
I think it'd be beyond me (I'm not familiar enough with CPython internals,
protocols, etc).
Can you explain what you mean by "symmetric protocol rather than the
current only-controlled-by-the-container behaviour"?
-Ben
On 7/14/2013 7:09 AM, Nick Coghlan wrote:
Slight adjustment to the proposed wording to ensure completely
undocumented modules are also considered private:
=
Private interfaces
Unless explicitly documented otherwise, a leading underscore on any name
indicates that it is an inter
On 15 July 2013 10:21, Ben Hoyt wrote:
> I'm sure there's a good reason for why "in" is different here, but I can't
> see why right now.
It depends on what you mean by "good reason" - PEP 207 (which is what
allows arbitrary objects to be returned from comparison operations)
was entirely about rep
On 15 July 2013 09:48, Steven D'Aprano wrote:
> On 14/07/13 21:09, Nick Coghlan wrote:
>
>> Slight adjustment to the proposed wording to ensure completely
>> undocumented
>> modules are also considered private:
>
>
> -1 on this adjustment. If somebody cannot be bothered writing a one-line doc
> st
Oh, just to show what I mean here with some code (same in both Python 2.x
and 3.x):
-
from __future__ import print_function
class C(object):
def __contains__(self, x):
print('__contains__({0!r})'.format(x))
return x
def __lt__(self, x):
print('__lt__({0!r})'.f
On Sun, Jul 14, 2013 at 8:01 PM, Cameron Simpson wrote:
> On 15Jul2013 09:48, Steven D'Aprano wrote:
> | On 14/07/13 21:09, Nick Coghlan wrote:
> |
> | >Slight adjustment to the proposed wording to ensure completely
> undocumented
> | >modules are also considered private:
> |
> | -1 on this adju
I'm curious why the return value of __contains__ is coerced to True or
False, whereas the return value of "normal" comparison operators like
__lt__ and the like are not. The latter return the value directly without
forcing it to be True or False.
This makes overriding __contains__ significantly le
On 15Jul2013 09:48, Steven D'Aprano wrote:
| On 14/07/13 21:09, Nick Coghlan wrote:
|
| >Slight adjustment to the proposed wording to ensure completely undocumented
| >modules are also considered private:
|
| -1 on this adjustment. If somebody cannot be bothered writing a one-line doc
string:
|
On 14/07/13 21:09, Nick Coghlan wrote:
Slight adjustment to the proposed wording to ensure completely undocumented
modules are also considered private:
-1 on this adjustment. If somebody cannot be bothered writing a one-line doc
string:
"This module is private, don't touch."
then they certa
+1 This is already how we've been behaving for years.
On Sun, Jul 14, 2013 at 4:09 AM, Nick Coghlan wrote:
> On 14 July 2013 18:11, Nick Coghlan wrote:
>
>> Currently, the naming section of PEP 8 doesn't say very much about what a
>> leading underscore *means* in the Python standard library.
On Sun, Jul 14, 2013 at 7:09 AM, Nick Coghlan wrote:
> On 14 July 2013 18:11, Nick Coghlan wrote:
>
>> Currently, the naming section of PEP 8 doesn't say very much about what a
>> leading underscore *means* in the Python standard library.
>>
>> I would like to add a new "Private interfaces" subs
On Jul 14, 2013, at 8:13 AM, Brett Cannon wrote:
>
>
>
> On Sun, Jul 14, 2013 at 2:54 AM, Nick Coghlan wrote:
> On 13 July 2013 23:26, David Beazley wrote:
> I'm in favor of PLY going into stdlib with the caveat that there are some
> things about it that should probably be cleaned up and mod
On Sun, Jul 14, 2013 at 2:54 AM, Nick Coghlan wrote:
> On 13 July 2013 23:26, David Beazley wrote:
>
>> I'm in favor of PLY going into stdlib with the caveat that there are some
>> things about it that should probably be cleaned up and modernized. For
>> instance, the method by which it writes
On 14 July 2013 18:11, Nick Coghlan wrote:
> Currently, the naming section of PEP 8 doesn't say very much about what a
> leading underscore *means* in the Python standard library.
>
> I would like to add a new "Private interfaces" subsection under "Naming
> Conventions" to say the following:
>
>
Ben Finney writes:
> "Stephen J. Turnbull" writes:
>
> > I don't see any good reason to take into account what Microsoft does
> > or doesn't support.
>
> It seems you're advocating a position quite ad odds with
> http://www.python.org/dev/peps/pep-0011/#id7>.
Not at all. The first thing
Currently, the naming section of PEP 8 doesn't say very much about what a
leading underscore *means* in the Python standard library.
I would like to add a new "Private interfaces" subsection under "Naming
Conventions" to say the following:
=
Private interfaces
Unless explicitly d
26 matches
Mail list logo
