14.07.19 05:09, Raymond Hettinger пише:
On Jul 13, 2019, at 1:56 PM, Serhiy Storchaka wrote:
Could we strictly define what is considered a public module interface in Python?
The RealDefinition™ is that whatever we include in the docs is public,
otherwise not.
Beyond that, there is a questio
17.07.19 03:26, Brett Cannon пише:
I agree with Raymond that if the calendar module was following the leading
underscore practice (which we should probably encourage all new modules to
follow for consistency going forward) then I think the module should be updated
to keep the practice going.
Brett Cannon wrote:
> I agree with Raymond that if the calendar module was following the leading
> underscore practice (which we should probably encourage all new modules to
> follow for
> consistency going forward) then I think the module should be updated to keep
> the practice
> going.
> -Bre
Usually the order of operands of the == operator does not matter. bool(a
== b) should return the same as bool(b == a). Correct __eq__ should look
like:
def __eq__(self, other):
if not know how to compare with other:
return NotImplemented
return the result of comp
20.07.19 09:03, Kyle Stanley пише:
Rather than it being on a case-by-case basis, would it be reasonable to
establish a universal standard across stdlib for defining modules as public to
apply to older modules as well? I think that it would prove to be quite
beneficial to create an explicit def
In an ideal world, needle is on the right. Let's replace needle with a
constant: which of the following looks more natural?
for x in sequence:
if x == 5: return True
or
for x in sequence:
if 5 == x: return True
For me, 'x == 5' wins with a huge margin. (There is a subculture of
Serhiy Storchaka wrote:
> Either we establish the rule that all non-public names must be
> underscored, and do mass renaming through the whole stdlib. Or allow to
> use non-underscored names for internal things and leave the sources in
Personally, I would be the most in favor of doing a mass re
On Sat, Jul 20, 2019 at 06:03:39AM -, Kyle Stanley wrote:
> Rather than it being on a case-by-case basis, would it be reasonable
> to establish a universal standard across stdlib for defining modules
> as public to apply to older modules as well?
No, I don't think so. That would require cod
