> On 28 Aug 2021, at 07:14, Christopher Barker wrote:
>
>
> SciPy should probably also be a data-point, it uses:
>
> nan_policy : {'propagate', 'raise', 'omit'}, optional
>
> +1
>
> Also +1 on a string flag, rather than an Enum.
Why do you prefer strings for the options rather than an
Hello developers.
I like the star expression.
It would be even better if we could extend the idea of PEP448 to
provide the following syntax at the time of assignment.
``` python
a, b, d, **_ = **{"a":0, " b":1, "c":2}, d=3
# Expressed as a function, it looks like this:
def func(a, b, d, **_):
On Mon, Aug 30, 2021 at 12:57 AM Ronald Oussoren
wrote:
> On 28 Aug 2021, at 07:14, Christopher Barker wrote:
>
>> Also +1 on a string flag, rather than an Enum.
>
> ou prefer strings for the options rather than an Enum? The enum clearly
> documents what the valid options are for the option.
>
On Tue, Aug 31, 2021 at 2:19 AM Christopher Barker wrote:
>
> On Mon, Aug 30, 2021 at 12:57 AM Ronald Oussoren
> wrote:
> > On 28 Aug 2021, at 07:14, Christopher Barker wrote:
>>>
>>>
>> Also +1 on a string flag, rather than an Enum.
>>
>> ou prefer strings for the options rather than an Enum?
Hi there python-ideas - I've been teaching Python as a first
programming language for a few years, and from that experience I want
to propose a change to PEP8. I'm sure the default position for PEP8 is
to avoid changing it. However, for this one rule I think a good case
can be made to make it optio
On Tue, Aug 31, 2021 at 4:46 AM Nick Parlante wrote:
> The problem for Python is what I will call the "mandatory-is" rule in
> PEP8, which reads:
>
> Comparisons to singletons like None should always be done with is or
> is not, never the equality operators.
The question is whether you're testing
>From my point of view as someone who sometimes help Scientist write
Python, this is a no go, there are too many cases where == and is are
different.
$ ipython
Python 3.8.5 | packaged by conda-forge | (default, Sep 16 2020, 17:43:11)
Type 'copyright', 'credits' or 'license' for more information
I
Hi Chris - thanks for the response,
so here you say:
I disagree; experienced programmers should be using "is" where it's
> correct.
>
I'd like to unpack that a little - like what do you mean by "correct"
there. My guess is "correct" means the code gets the right answer for all
inputs.
Like for
On Tue, Aug 31, 2021 at 5:34 AM Nick Parlante wrote:
>
> Hi Chris - thanks for the response,
>
> so here you say:
>
>> I disagree; experienced programmers should be using "is" where it's
>> correct.
>
>
> I'd like to unpack that a little - like what do you mean by "correct" there.
> My guess is "
On 2021-08-30 12:34, Nick Parlante wrote:
Like for "if x == None:" works right
By that definition, == is correct there. I think PEP8 has forced people
to use "is" so much, they've lost touch with the reality that in fact ==
would work perfectly in almost all cases. Situations where "is" is
requi
On Mon, Aug 30, 2021, 15:38 Nick Parlante wrote:
> Hi Chris - thanks for the response,
>
> so here you say:
>
> I disagree; experienced programmers should be using "is" where it's
>> correct.
>>
>
> I think PEP8 has forced people to use "is" so much, they've lost touch
> with the reality that in
I claimed that uses of "is" where it is needed for correctness
are quite rare. Let me back that up with a little data here.
Just as a random supply of Python code, let's look at
the first four Python modules where the name starts
with a letter from the Python standard modules list
https://docs.pyt
On Tue, Aug 31, 2021 at 6:52 AM Nick Parlante wrote:
>
> I claimed that uses of "is" where it is needed for correctness
> are quite rare. Let me back that up with a little data here.
>
> Just as a random supply of Python code, let's look at
> the first four Python modules where the name starts
> w
On Mon, Aug 30, 2021 at 1:50 PM Nick Parlante wrote:
> I claimed that uses of "is" where it is needed for correctness
> are quite rare. Let me back that up with a little data here.
>
.. snip...
BTW, it might be neat if someone could keep going through the Python module
code and find a case where
EVERY line you found would behave incorrectly if changed to "x == None".
Admittedly, doing so would require setting the various variables and
attributes to somewhat uncommon objects that act "funny" when comparing to
None. Or when doing equality comparisons in general.
As others have said, learn
>
> On what basis do you ascertain whether "==" would work correctly?
> Please explain.
Hi Chris, I'm just glancing at the line of code, and doing a little thought
experiment to see if it would get the same output if == was used instead.
For a singleton like None or False or the class like "list"
On Tue, Aug 31, 2021 at 7:17 AM Nick Parlante wrote:
>>
>> On what basis do you ascertain whether "==" would work correctly?
>> Please explain.
>
>
> Hi Chris, I'm just glancing at the line of code, and doing a little thought
> experiment to see if it would get the same output if == was used inst
On Tue, Aug 31, 2021 at 7:22 AM Chris Angelico wrote:
>
> On Tue, Aug 31, 2021 at 7:17 AM Nick Parlante wrote:
> >>
> >> On what basis do you ascertain whether "==" would work correctly?
> >> Please explain.
> >
> >
> > Hi Chris, I'm just glancing at the line of code, and doing a little thought
>
> EVERY line you found would behave incorrectly if changed to "x == None".
>
Hi David, well it seems possible, but I don't see it, so maybe you can give
an example.
So here's the first line from the list:
if file is not None:
I think we should allow the programmer to use != for that l
Chris Angelica and Matthias Bussonnier have provided numerous examples of
both "custom" objects and widely used libraries where the distinction
between equality and Identity is important.
Nearly every example you found is such a case. There is an attribute or a
variable (often a formal parameter)
>
> >>> class X:
> ... def __eq__(self, other): return True
> ...
> >>> x = X()
> >>> x is None
> False
> >>> x == None
> True
I don't know Chris, doesn't this just show that If you construct a class
with a, shall we say, "oddball" definition of ==, then using == on that
class gets oddball re
On Mon, 30 Aug 2021 at 23:27, Nick Parlante wrote:
> I don't know Chris, doesn't this just show that If you construct a class with
> a, shall we say, "oddball" definition of ==, then using == on that class gets
> oddball results. And it goes without saying that we all understand that None
> and
I agree that, of course, it's possible to construct a class where == has
this kind of weird behavior, like claiming that == to None is True.
So are you saying that the reason PEP8 should forbid writing the line like
this
if x == None:
is because x might be such a class?
Best,
Nick
On M
It really feels now like you are TRYING to miss the point of equality and
identity, and why 'is None' checks are the correct approach to recommend.
Here's a slightly contrived, but not absurd function. I've certainly
written a great many that follow this general form.
>>> def add_multiples(eleme
Nick Parlante wrote:
> Hi there python-ideas - I've been teaching Python as a first
> programming language for a few years, and from that experience I want
> to propose a change to PEP8. I'm sure the default position for PEP8 is
> to avoid changing it. However, for this one rule I think a good case
Hi Nick,
On Mon, Aug 30, 2021 at 4:25 PM Nick Parlante wrote:
> I don't know Chris, doesn't this just show that If you construct a class with
> a, shall we say, "oddball" definition of ==, then using == on that class gets
> oddball results. And it goes without saying that we all understand that
On Tue, Aug 31, 2021 at 8:54 AM Nick Parlante wrote:
>
> I agree that, of course, it's possible to construct a class where == has this
> kind of weird behavior, like claiming that == to None is True.
>
> So are you saying that the reason PEP8 should forbid writing the line like
> this
>
> if
On Mon, Aug 30, 2021 at 01:50:47PM -0700, Nick Parlante wrote:
> Just as a random supply of Python code, let's look at
> the first four Python modules where the name starts
> with a letter from the Python standard modules list
> https://docs.python.org/3/py-modindex.html :
> abc.py aifc.py argpars
I understand that Python itself should work with classes with any sort of
crazy semantics, and I appreciate your spelling it out. We could say that
the bar for the Python implementation is the highest, since who knows what
experimental == someone might cook up playing around, and you would like
the
On Tue, Aug 31, 2021 at 10:25 AM Nick Parlante wrote:
>
> I understand that Python itself should work with classes with any sort of
> crazy semantics, and I appreciate your spelling it out. We could say that the
> bar for the Python implementation is the highest, since who knows what
> experime
On Mon, Aug 30, 2021 at 11:32:20AM -0700, Nick Parlante wrote:
> Hi there python-ideas - I've been teaching Python as a first
> programming language for a few years, and from that experience I want
> to propose a change to PEP8. I'm sure the default position for PEP8 is
> to avoid changing it. Howe
On Mon, Aug 30, 2021 at 03:24:08PM -0700, Nick Parlante wrote:
> If we has a class, say, where == has some weird behavior, the solution is
> that the docs for that class explain how its definition of == is weird and
> so code should take care to use "is" or whatever. That's kind of canonical
> use
On Mon, Aug 30, 2021 at 11:32:20AM -0700, Nick Parlante wrote:
> As a practical matter, the way this comes up for my students is that
> IDEs by default will put warning marks around PEP8 violations in their
> code.
I'm not fond of linters that flag PEP 8 violations. And if I recall
correctly, I
On Tue, Aug 31, 2021 at 11:33:16AM +1000, Steven D'Aprano wrote:
> If you tell us what IDE your school or department uses, we might even be
> able to tell you what config you need.
Here are instructions for PyCharm:
http://iambigblind.blogspot.com/2013/02/configuring-pep8py-support-in-pycharm-2
On Tue, Aug 31, 2021 at 02:23:29AM +1000, Chris Angelico wrote:
> On Tue, Aug 31, 2021 at 2:19 AM Christopher Barker
> wrote:
> > I suppose they provide a real advantage for static typing, but other
> > than that I just don't see it.
>
> They provide a *huge* advantage when they can be combine
On Tue, Aug 31, 2021 at 11:47 AM Steven D'Aprano wrote:
>
> On Tue, Aug 31, 2021 at 02:23:29AM +1000, Chris Angelico wrote:
> > On Tue, Aug 31, 2021 at 2:19 AM Christopher Barker
> > wrote:
>
> > > I suppose they provide a real advantage for static typing, but other
> > > than that I just don't
On 2021-08-30 09:23, Chris Angelico wrote:
On Tue, Aug 31, 2021 at 2:19 AM Christopher Barker wrote:
To be honest, I haven't really used Enums much (in fact, only to mirror C enums
in extension code), but part of that is because I have yet to see what the
point is in Python, over simple strin
It's all been said, but a couple notes:
I also teach beginners Python -- and I absolutely teach them to use "is
None" (I'd have to look at my notes, but I think around lesson 3),
In fact, I also teach about what ``is`` means, and how it is very different
from ``==``.
I have seen all too many in
On Mon, Aug 30, 2021 at 6:50 PM Steven D'Aprano wrote:
> > They provide a *huge* advantage when they can be combined. It's easy
> > to accept a flags argument that is the bitwise Or of a collection of
> > flags,
>
> I'm not a big user of Enums, but I *think* that only applies for
> IntEnums?
>
On Mon, Aug 30, 2021 at 10:22 AM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:
> Christopher Barker writes:
>
> > e.g.: what are the valid values?
>
> That's easy: MyEnum.__members__.
>
Seriously? you are arguing that Enums are better because they are self
documenting, when you have t
40 matches
Mail list logo
