[Python-ideas] Re: NAN handling in statistics functions

[Finn Mason]

I've honestly never really used an Enum, so I'm not an expert here.
An idea might be using string flags, but setting module level constants
equal to the string flag, so that you can use either. For example (using
the ipython shell because it's easier in email with quoting and all):

In [1]: import statistics as stats
In [2]: stats.NAN_IGNORE
Out [2]: 'ignore'
In [3]: stats.median([3, float('nan'), 5], nan_policy=stats.NAN_IGNORE) ==
stats.median([3, float('nan'), 5], nan_policy='ignore')
Out [3]: True

I do think that it doesn't matter too much and an issue should be submitted
soon.

On Tue, Aug 31, 2021, 4:59 PM Christopher Barker 
wrote:

> First:
>
> I started this specifically in the context of the stats package and the
> NaN handling flag, but it did turn into a ore general discussion of Enums,
> so a final thought:
>
> On Tue, Aug 31, 2021 at 4:17 AM Ronald Oussoren 
> wrote:
>
>>
>> Not just static typing, but static analysis in general. Tools like flake8
>> will complain about typos, completion tools can help typing, ….
>>
> ...
>
>
>> I tend to use constants instead of string literals because of better
>> static analysis, and try to convert uses to enums over time.  String flags
>> work as well, but I’ve had too much problems due to typo’s in string
>> literals that weren’t caught by incomplete tests.  Being able to at least
>> run a listing tool to find basic issues like typo’s is very convenient.
>> But YMMV.
>>
>
> I think this is the crux or it -- Enums are far more suited to static
> analysis.
>
> And that reflects a shift in Python over the years. Most of the changes in
> Python have made it a better "systems" language, and some have made it a
> somewhat more awkward "scripting" language.
>
> Features to support static analysis are a good example -- far less
> important for "scripting' that "systems programming".
>
> Personally, I find it odd -- I've spent literally a couple decades telling
> people that Python's dynamic nature is a net plus, and the bugs that static
> typing (and static analysis I suppose) catch for you are generally shallow
> bugs. (for example: misspelling a string flag is a shallow bug).
>
> But here we are.
>
> Anyway, if you are writing a quick script to calculate a few statistics, I
> think a string flag is easier. If you are writing a big system with some
> statistical calculations built in, you will appreciate the additional
> safety of an Enum. It's hard to optimize for different use cases.
>
> - CHB
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/LJ334TFG67PR3G2E6WNZC7YEG3K2XMEN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LRJFFW25UJIH6HNQ6LOTZ5T6M27Y23KC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Steven D'Aprano]

On Tue, Aug 31, 2021 at 11:15:22AM -0700, Nick Parlante wrote:

> As a practical matter, the IDEs just default to having PEP8 checking on,
> and they do it in a very visual way - akin to a text editor which puts
> little squiggles under words it thinks are misspelled.
> 
> This maybe sounds annoying, but looking at how people learn to code, it's
> actually fantastic, and a giant success for the goals of PEP8.

You have convinced me that having IDEs run linters by default is a great 
advantage to both educators and students. But I'd like to point out 
that, good as it may be, it is not a success for the goals of PEP-8 
because PEP-8 isn't about teaching newbies to code.

It's more of an unexpected bonus.

We're unlikely to change PEP-8 to recommend equality checks with None. 
For non-student experienced Python programmers, `is None` is the correct 
way to check for None. I suggest you approach the people who write IDEs 
are make a stong case for "education mode" where `== None` checks are 
disabled. If there are IDEs that sell to the education market, they may 
jump on board the idea.

-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2JCGFQQP55AB2TZMFHGWSSDJS2STDLHN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Oscar Benjamin]

On Wed, 1 Sept 2021 at 01:20, Matthias Bussonnier <
bussonniermatth...@gmail.com> wrote:

> > Are there other such classes?
>
[snip]

> ... stuff, let's pick a few:
>
> sympy.physics.optics.Medium:
>
> def __eq__(self, other):
> return self.refractive_index == other.refractive_index
>
> Will crash with None has no attribute refractive_index,
>

I think that particular __eq__ method is buggy. There should be a general
expectation that __eq__ can be used with unexpected types and should return
NotImplemented or False rather than raise an exception.


Oscar
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7Q2R3AEV5GL4Y3JMZXQWZJGJQ4HELB5T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Steven D'Aprano]

On Wed, Sep 01, 2021 at 10:29:24AM +1000, Chris Angelico wrote:

> In the classic demonstration that 0.1 + 0.2 != 0.3, the problem isn't
> equality, it's that none of those values is what you think it is.

That is a wonderful way of putting it.

-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HYGSDX5CDPXOEBKLGRA5FYYC2PDD6EZQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Chris Angelico]

On Wed, Sep 1, 2021 at 10:23 AM Steven D'Aprano  wrote:
> What doesn't work, for some definition of "doesn't", is everything
> else about floats: addition, subtraction, multiplication, conversion
> from decimal, etc. But *equality* is one of the few operations that
> works exactly.
>

Really, the only thing that BADLY doesn't work is conversion from
decimal. All the others are accurate to within the available
precision. The problem with binary floating point isn't equality; it's
that humans assume that 0.1 is a precise value. We don't expect
0.3 to be a precise representation of one third, yet we expect a
computer to be able to store one tenth with perfect accuracy. That's
where ALL the problems come from.

In the classic demonstration that 0.1 + 0.2 != 0.3, the problem isn't
equality, it's that none of those values is what you think it is. If I
told you that 33/100 + 66/100 != 100/100, nobody would bat an eyelid.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WR5TGCMY37LF2F7SXWTQLXHWPII35Y5K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Steven D'Aprano]

On Tue, Aug 31, 2021 at 12:35:05PM -0700, Nick Parlante wrote:

> You will be relieved to know that  we have great fun showing them how ==
> does not work for floating point numbers. It is super memorable how that
> all comes unglued.

Of course `==` works for floating point numbers. For floats, `x == y` 
returns True if and only if:

- x and y are both zeroes
- x and y are both +INF
- x and y are both -INF
- or x and y have the same numeric value.

In other words, it is the intuitive and correct meaning of "equals" for 
all numbers capable of being represented as a float.

People who remember floating point maths on computers prior to the 
widespread adoption of IEEE-754 will know that this is actually quite a 
big deal, and not something to sneer at.

What doesn't work, for some definition of "doesn't", is everything 
else about floats: addition, subtraction, multiplication, conversion 
from decimal, etc. But *equality* is one of the few operations that 
works exactly.



-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/I3XVILQC5KRXXLJ6DCHRKFKCLBLBNP66/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Matthias Bussonnier]

> Are there other such classes?

from the top of my head, Pandas:

In [13]: pd.DataFrame([[1,2], [3, 4]]) == None
Out[13]:
   0  1
0  False  False
1  False  False

and any zarr container, or xarray will behave like numpy and broadcast.
Ah, that means probably Dask, and Ray. Also maybe CuPy ?
But I'm not going to list all that behave like numpy or pandas, but
that's a big chunk of things that return non boolean values.

Let's grep into my dev folder for other weird __eq__

$ rg  'def __eq__' -A3

... stuff, let's pick a few:

sympy.physics.optics.Medium:

def __eq__(self, other):
return self.refractive_index == other.refractive_index

Will crash with None has no attribute refractive_index,

IPython's internal Completions objects around Jedi also assume they
are compared against instances of the same class and will crash, but
likely with 'NoneType' object is not subscriptable.

matplotlib FontProperties have a small but non-zero change of telling
you that the current (object == None) is True as it compares hashes,
so if the hash of the FontProp is the same as None... well.


Basically anything that implements __eq__ and assumes it will be
compared only against things that are of the same type will not be
happy to be compared with None using ==.
or implement broadcasting like abilities.
-- 
Matthias

On Tue, 31 Aug 2021 at 16:22, Nick Parlante  wrote:
>
> To argue that == is unreliable, I think Matthias has the best, non-contrived 
> example with numpy, which I did not know about:
>
> >>> x = np.array([1, 2, 3])
> >>> x == None
> array([False, False, False])
>
> This certainly is a good example of == not being reliable. Point taken there.
>
> Are there other such classes? Like if I write code that just uses Python and 
> its standard library classes, can I get a value where == None is flaky like 
> the numpy example? I wouldn't think so, just as a matter of 
> principle-of-least-surprise API design. Anyway, that would be very 
> interesting example to argue against my claim that == None is reliable.
>
> Best,
>
> Nick
>
> On Mon, Aug 30, 2021 at 12:06 PM Matthias Bussonnier 
>  wrote:
>>
>> 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
>> IPython 7.25.0 -- An enhanced Interactive Python. Type '?' for help.
>>
>> In [1]: import numpy as np
>>
>> In [2]: a = np.array([True, False, None])
>>
>> In [3]: a == True, a == False, a == None
>> Out[3]:
>> (array([ True, False, False]),
>>  array([False,  True, False]),
>>  array([False, False,  True]))
>>
>> In [4]: a is True, a is False, a is None
>> Out[4]: (False, False, False)
>>
>> if `a == True` can even raise errors when in ifs:
>>
>> In [5]: if a == True:
>>...: pass
>>...:
>> ---
>> ValueErrorTraceback (most recent call last)
>>  in 
>> > 1 if a == True:
>>   2 pass
>>   3
>>
>> ValueError: The truth value of an array with more than one element is
>> ambiguous. Use a.any() or a.all()
>>
>> Basic types are just too simple to expose the real need between `==`
>> and `is`, but that's not a reason not to give the right advice from
>> the start.
>> IMHO It would be like teaching English and saying that it's ok not to
>> put s after nouns when there is a number in front as it's obvious
>> there are many.
>>
>> I do understand your concern, but I believe that would be just pushing
>> the problem to later, when it would be much more difficult to explain
>> and have students get a wrong mental model from the start, which is
>> really hard to overcome.
>>
>> --
>> Matthias
>>
>> On Mon, 30 Aug 2021 at 11:45, 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
>> > can be made to make it optional, so let me know what you think.
>> >
>> > Let me start with what I've learned from teaching students in Java and
>> > now in Python. In Java, you use == for ints, but you need to use
>> > equals() for strings. Of course students screw this up constantly,
>> > using == in a context that calls for equals() and their code does not
>> > work right. Then for Java arrays a different comparison function is
>> > required, and so it goes. To teach comparisons in Python, I simply say
>> > "just use ==" - it works for ints, for strings, even for lists.
>> > Students are blown away by how nice and simple this is. This is how
>> > things should work. Python really gets this right.
>> >
>> > So what is the problem?
>> 

[Python-ideas] Re: PEP8 mandatory-is rule

[Nick Parlante]

To argue that == is unreliable, I think Matthias has the best,
non-contrived example with numpy, which I did not know about:

>>> x = np.array([1, 2, 3])
>>> x == None
array([False, False, False])

This certainly is a good example of == not being reliable. Point taken
there.

Are there other such classes? Like if I write code that just uses Python
and its standard library classes, can I get a value where == None is flaky
like the numpy example? I wouldn't think so, just as a matter of
principle-of-least-surprise API design. Anyway, that would be very
interesting example to argue against my claim that == None is reliable.

Best,

Nick

On Mon, Aug 30, 2021 at 12:06 PM Matthias Bussonnier <
bussonniermatth...@gmail.com> wrote:

> 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
> IPython 7.25.0 -- An enhanced Interactive Python. Type '?' for help.
>
> In [1]: import numpy as np
>
> In [2]: a = np.array([True, False, None])
>
> In [3]: a == True, a == False, a == None
> Out[3]:
> (array([ True, False, False]),
>  array([False,  True, False]),
>  array([False, False,  True]))
>
> In [4]: a is True, a is False, a is None
> Out[4]: (False, False, False)
>
> if `a == True` can even raise errors when in ifs:
>
> In [5]: if a == True:
>...: pass
>...:
> ---
> ValueErrorTraceback (most recent call last)
>  in 
> > 1 if a == True:
>   2 pass
>   3
>
> ValueError: The truth value of an array with more than one element is
> ambiguous. Use a.any() or a.all()
>
> Basic types are just too simple to expose the real need between `==`
> and `is`, but that's not a reason not to give the right advice from
> the start.
> IMHO It would be like teaching English and saying that it's ok not to
> put s after nouns when there is a number in front as it's obvious
> there are many.
>
> I do understand your concern, but I believe that would be just pushing
> the problem to later, when it would be much more difficult to explain
> and have students get a wrong mental model from the start, which is
> really hard to overcome.
>
> --
> Matthias
>
> On Mon, 30 Aug 2021 at 11:45, 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
> > can be made to make it optional, so let me know what you think.
> >
> > Let me start with what I've learned from teaching students in Java and
> > now in Python. In Java, you use == for ints, but you need to use
> > equals() for strings. Of course students screw this up constantly,
> > using == in a context that calls for equals() and their code does not
> > work right. Then for Java arrays a different comparison function is
> > required, and so it goes. To teach comparisons in Python, I simply say
> > "just use ==" - it works for ints, for strings, even for lists.
> > Students are blown away by how nice and simple this is. This is how
> > things should work. Python really gets this right.
> >
> > So what is the problem?
> >
> > 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.
> >
> > For the students, this comes up in the first week of the course with
> > lines like "if x == None:" which work perfectly with == but should use
> > is/is-not for PEP8 conformance.
> >
> > My guess is that this rule is in PEP8 because, within a Python
> > implementation, it is within the programmer's mental model that, say,
> > False is a singleton. The mandatory-is rule is in PEP8 to reinforce
> > that mental model by requiring the is operator. Plus it probably runs
> > a tiny bit faster.
> >
> > However, for "regular" Python code, not implementing Python, forcing
> > the use of is instead of the simpler == is unneeded and unhelpful (and
> > analogously forcing "is not" when != works correctly). What is the
> > benefit of forcing the is operator there? I would say it spreads an
> > awareness of the details of how certain values are allocated within
> > Python. That's not much of a benefit, and it's kind of circular. Like
> > if programmers were permitted to use ==, they wouldn't need to know
> > the details of how Python allocates those values. Being shielded from
> > implementation details is a Python strength - think of the Java vs.
> > Python story above. Is Java better because it builds an awareness in
> > the programmer of the 

[Python-ideas] Re: NAN handling in statistics functions

[Christopher Barker]

First:

I started this specifically in the context of the stats package and the NaN
handling flag, but it did turn into a ore general discussion of Enums, so a
final thought:

On Tue, Aug 31, 2021 at 4:17 AM Ronald Oussoren 
wrote:

>
> Not just static typing, but static analysis in general. Tools like flake8
> will complain about typos, completion tools can help typing, ….
>
...


> I tend to use constants instead of string literals because of better
> static analysis, and try to convert uses to enums over time.  String flags
> work as well, but I’ve had too much problems due to typo’s in string
> literals that weren’t caught by incomplete tests.  Being able to at least
> run a listing tool to find basic issues like typo’s is very convenient.
> But YMMV.
>

I think this is the crux or it -- Enums are far more suited to static
analysis.

And that reflects a shift in Python over the years. Most of the changes in
Python have made it a better "systems" language, and some have made it a
somewhat more awkward "scripting" language.

Features to support static analysis are a good example -- far less
important for "scripting' that "systems programming".

Personally, I find it odd -- I've spent literally a couple decades telling
people that Python's dynamic nature is a net plus, and the bugs that static
typing (and static analysis I suppose) catch for you are generally shallow
bugs. (for example: misspelling a string flag is a shallow bug).

But here we are.

Anyway, if you are writing a quick script to calculate a few statistics, I
think a string flag is easier. If you are writing a big system with some
statistical calculations built in, you will appreciate the additional
safety of an Enum. It's hard to optimize for different use cases.

- CHB

--
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LJ334TFG67PR3G2E6WNZC7YEG3K2XMEN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Christopher Barker]

Nick,

On teh one hand, I teach a lot of beginners, and I share most of your
experience with PEP8 and linters -- indeed, I encourage my studetns to use
a linter right off the bat. (I don't require a particular editor, but I do
provide recommendations for a handful of common ones (PyCharm, VS Code,
Sublime), and I always recommend a linter.

I also agree that the linter can be kind of distracting, and that some
"problems" are more important than others, so it makes sense to turn off
some particular issues. (not turned off, but I do extend the minimum line
length myself)

However, the "is None" recommendation is one I would NOT suggest my
students turn off -- for all the reasons posted here. FRankly, I student
that learns to write code with some not great spacing or naming conventions
is much better shape than one that doesn't learn what `is` means in Python.
I"ll say it again: recommending ``is None`` is not just "style" -- it has
real different meaning.

Also: it's not the job of the PEP 8 authors to rank the importance of the
various recommendations. If you have an idea about a better linter
configuration for beginners, then by all means create one, use it in your
classes, publish it for other instructors to use, etc.

-CHB

NOTE: you must have different students than I do -- I have more problem
with students ignoring a massive amount of cruft the linter is putting on
their code ("I just want to get it to work!") than I do students obsessing
over getting it lint free.

NOTE 2: David Mertz had a very good point -- you can get very far in Python
without using None at all (or at least not checking it - after all,
functions do return None by default). Probably the most common use is to
mean "not specified" in keyword parameters -- how early do you introduce
those?

-CHB

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/K4WYSFVPDQVYZJITE76KSFDLGSMBN6I7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: NAN handling in statistics functions

[Christopher Barker]

On Tue, Aug 31, 2021 at 12:09 AM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:

> *sigh* __members__ is just the mechanism.  As a consequence, Enums are
> iterable, and they automatically DTRT with dir() and help() even if
> there are no docstrings.


but you didn't say dir(), you said __members__ ;-)

But my bad, yes, dir() is easy and obvious, and works.

As for help() -- for some reason, I never use it -- not sure why. I do use
iPython's ?, which gives me:

In [15]: NaNflag?

Init signature:

NaNflag(

value,

names=None,

*,

module=None,

qualname=None,

type=None,

start=1,

)

Docstring:  An enumeration.

File:
/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/enum.py

Type:   EnumMeta
Subclasses:

which is not that useful, because the docstring is pretty worthless.

help() on the other hand, is useful:

class NaNflag(enum.Enum)
 |  NaNflag(value, names=None, *, module=None, qualname=None, type=None,
start=1
)
 |
 |  An enumeration.
 |
 |  Method resolution order:
 |  NaNflag
 |  enum.Enum
 |  builtins.object
 |
 |  Data and other attributes defined here:
 |
 |  Propogate = 
 |
 |  Raise = 
 |
 |  Skip = 
 |
 |  --
 |  Data descriptors inherited from enum.Enum:

 |  name
 |  The name of the Enum member.
 |
 |  value
 |  The value of the Enum member.
 |
 |  --
 |  Readonly properties inherited from enum.EnumMeta:
 |
 |  __members__
 |  Returns a mapping of member name->value.
 |
 |  This mapping lists all enum members, including aliases. Note that
this
 |  is a read-only view of the internal mapping.

Hmm - maybe that's why I don't use help() much -- If an object has a decent
docstring, I'd rather not see all that other cruft :-)

So if you want a well documented Enum, you need to write a docstring, which
is, or course, the case with everything in Python, so no problem there.

(though a nice auto-generated docstring would be good -- maybe a feature
request for the future)

I've been convinced, Enums do provide a nice way to document flag options.
But unfortunately, it doesn't put that documentation where I'd want it --
in the docstring of the functions that use it.

DRY is hard with documentation -- this reminds me of when there's a big
class hierarchy, and you have go read the docs way up the tree to know how
to use a class.

Now show me how to do any of those with str
> codes.
>

In that case, the documentation needs to go in the docstring of the
function where they are used, which is where I want it anyway.

That's a documentation style matter, though.  Since just about every
> function in the statistics package will take the 'nans' argument, not
> only the writer, but most readers of the documentation will favor
> DRYing it once, IMHO YMMV.
>

I don't think readers will have a preference for having
something documented in one place that is not the place you actually use
it. They WILL appreciate that all functions in the statistics package work
the same way though, that's for sure.

Anyway, I was expressing a preference, and I still have that preference,
but Enums are a fine option as well.  And the proposed idea of using the
string value for the Enum, so that users can use either has its appeal.

For me, it's like Lays potato chips; I can't call just one.  Almost
> all my use cases call for mean, standard deviation, and median.
>

hmm, another topic, but computing mean and standard deviation at the same
time would make sense.

Bringing back to the decision Steven needs to make:

I still prefer string flags, but there are certainly good arguments to be
made for an Enum. If you do go with an Enum, I suggest:

- The flag names are put in the statistics module namespace.
- The Enum gets a good docstring.
- The functions that use the Enum also document the flags and what they
mean.
- to keep that dry, you could automatically insert the Enum docstring
into each function's docstring, so that it would be there where users need
it.

That's my $ 0.2

-CHB



-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GHWK5GKZOQYDWG5SXLU3JK77SWCPIWH7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Todd]

On Tue, Aug 31, 2021, 17:24 Nick Parlante  wrote:

> Hi Chris - well maybe we're looking at different questions. Your examples
> show it is possible to construct a data type where == None does not work.
> Clearly that is possible.
>
> 1. One conclusion is that the possibility of such == means that in general
> the == None form is unreliable. This is the proper mindset of the Python
> implementation, where the classes that need to work are practically
> unlimited, so relying on == would be unreliable as shown.
>
> 2. However, I am interested in the mass of ordinary looking programs that
> use strings, lists, ints, dicts, tuples, functions etc. to solve some
> problem. It's extremely likely that all of the classes in such a program
> have a reasonable definitions of ==. So if the programmer knows that, they
> can use the "== None" form in complete confidence. It works perfectly.
>
> It's possible to treat (1) as kind definitive, like that possibility ends
> the argument. I agree (1) is true, but do not find it convincing about the
> (2) case. I think (2) is more useful for thinking about Python programs in
> the world.
>
> Best,
>
> Nick
>

We have two approaches:

  1. An approach that is guaranteed to always work no matter what.
  2. An approach that will randomly break depending on potentially
undocumented implementation details of the data you are using, including
for some of th most common uses-cases for python.

Both approaches use the same number of characters, the same complexity as
far as users are concerned, and rely on concepts that anyone with a basic
understanding of the language needs to know. So why would anyone choose to
you approach 2?

You insist that both approaches should be treated as equally valid. But
they simply aren't. In the real world, where people are trying to do almost
anything useful with python, approach 2 is too dangerous to rely on. There
are just not that many real-world uses-cases that use nothing but the core
python types.

As you said, there are things that are subconsciously hard for people to
avoid. One is leaving warnings in the IDE unfixed. Another, however, is
forming habits. We want to encourage people to make good habits that will
serve them well generally, not bad habits that wil usually work okay in a
narrow context but will break everything as soon as they are applied in
common, real-world situations.

What you are advocating is a bad habit. Yes, it can work okay in some
situations, but why should we be encouraging bad habits when there is no
downside whatsoever to the good alternative? If you want to encourage bad
habits you should be using perl or MATLAB.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WUXRDJ4A4DG2CJRGJE3S7QUVQWER6DR6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[David Mertz, Ph.D.]

If it is not 100% obvious, I would strongly advice any IDE or linter
against disabling E711 as a default.

I'm not a contributors to any of those, so it's not my decision. But were
anyone to ask me...

Moreover, I would strongly discourage any instructor from papering over the
difference between equality and Identity. I guess in a pure functional
language there's no difference. But in Python it's of huge importance.

As noted REPEATEDLY, this isn't just about 'is None'. As soon as you see
these, it is a CRUCIAL distinction:

a = b = []
c, d = [], []

Nary a None in sight, yet the distinction is key.

On Tue, Aug 31, 2021, 5:23 PM Nick Parlante  wrote:

> Hi Chris - well maybe we're looking at different questions. Your examples
> show it is possible to construct a data type where == None does not work.
> Clearly that is possible.
>
> 1. One conclusion is that the possibility of such == means that in general
> the == None form is unreliable. This is the proper mindset of the Python
> implementation, where the classes that need to work are practically
> unlimited, so relying on == would be unreliable as shown.
>
> 2. However, I am interested in the mass of ordinary looking programs that
> use strings, lists, ints, dicts, tuples, functions etc. to solve some
> problem. It's extremely likely that all of the classes in such a program
> have a reasonable definitions of ==. So if the programmer knows that, they
> can use the "== None" form in complete confidence. It works perfectly.
>
> It's possible to treat (1) as kind definitive, like that possibility ends
> the argument. I agree (1) is true, but do not find it convincing about the
> (2) case. I think (2) is more useful for thinking about Python programs in
> the world.
>
> Best,
>
> Nick
>
>
> On Tue, Aug 31, 2021 at 1:31 PM Chris Angelico  wrote:
>
>> On Wed, Sep 1, 2021 at 6:06 AM Nick Parlante 
>> wrote:
>> > Is there anyone other than me who would like to push for "== None
>> tolerant" carve out for non-Python-implementation code?
>>
>> What you're asking is: Is there anyone other than you who would prefer
>> for Python to officially encourage people to write buggy and
>> unreliable code?
>>
>> No.
>>
>> I'm done discussing this; if you still genuinely think that "== None"
>> is actually better than "is None", despite all the demonstrations
>> posted, there's no convincing you.
>>
>> ChrisA
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/KE4C6L63CLEG65ZTCTJKCQ6OPMU3UBIA/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/KXWBSEO34MKUDATUEJ5U3YCIZXFH7KE2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SVKJYS4WM3WSY22BCT5BY36GA5UXBJZC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Michael Lee]

Another idea -- have you considered deferring teaching students about None
until after they've had a chance to learn about writing custom objects and
operator overloading?

None is primarily useful for representing the absence of some value, and
I'm not sure if that's something beginners actually need to write
interesting and useful code. As an example, take a look at intro courses
that teach Java. Assuming they take an objects-late approach, you can stick
with having students work with just primitive types (e.g. types where
'null' isn't permitted) for a fairly decent portion of the course.

If you do the same in your Python course, you can defer introducing the
'==' vs 'is' distinction until your students have enough background to
fully understand and appreciate it. It would also arguably help them
develop good habits early on: code that minimizes the use of union types
(and subtyping, etc) is usually easier to maintain.

-- Michael


On Tue, Aug 31, 2021 at 1:08 PM Nick Parlante  wrote:

> Thanks to everyone for many thoughtful comments. I'm going to try to wrap
> this up.
>
> So I talked above about how the IDEs have this very visual way of nudging
> beginning students to write their code to conform to PEP8, and this is the
> IDE default. Mostly this is a great, constructive dynamic, nudging students
> to follow the community standard.
>
> As someone who spends all their time in the land of Python-beginners, I
> hope this little report of how the IDEs nudge the beginners can be taken as
> a success story by people who care about PEP8.
>
> I should say, I'm not worried about Stanford students, they're going to be
> fine. In reality, I'm playing a long game here. I'm pushing for Python to
> grow to be the dominant intro teaching language (currently it's Java). I do
> not want the tooling by default to be flagging correct uses of == for, say,
> a highschool student a few years from now who is firing up the IDE to get
> started coding. Anyway, this is why I'm trying to get a little shift in the
> IDE default now.
>
> I want to get a phrasing into PEP8 so I can go to PyCharm et al, and get a
> little shift in their default behavior. PEP8 coloring in the IDE should
> remain on by default. That has many fantastic qualities as it works with
> the beginning students. But in the default configuration, I want the PEP8
> scoring to be tolerant about "== None" for non-Python-implementation code.
>
> My original proposal was to add this parenthetical to the mandatory-is
> rule: "(this rule is optional for code that is not part of a Python
> implementation)".
>
> Or maybe just a weak nudge to the tooling, like "(it's permissible for
> tooling to leave E711 off by default, though it is required for Python
> implementation code)". (ht Steven D'Aprano pointing out the proper numbers
> https://pep8.readthedocs.io/en/release-1.7.x/intro.html#error-codes)
>
> Then I can go to PyCharm et al and say - hey, for new empty projects could
> you please default to PEP8 checking on but E711 off.
>
> Is there support for such a change? The replies on this thread I would say
> are mostly not supportive...
>
> Just using Todd recent reply as an example - describing == as "brittle".
> Then some point out that understanding equality and identity is important,
> so in effect this justifies getting "is" in front of the students even
> where == works. Then there's a practical view that being tolerant of "==
> None" may be a thing, but messing with PEP8 is not the way.
>
> Is there anyone other than me who would like to push for "== None
> tolerant" carve out for non-Python-implementation code?
>
> Best,
>
> Nick
>
> On Tue, Aug 31, 2021 at 12:19 PM <2qdxy4rzwzuui...@potatochowder.com>
> wrote:
>
>> On 2021-08-31 at 11:15:22 -0700,
>> Nick Parlante  wrote:
>>
>> > As mentioned, PEP8 is formally for narrow cases, and includes
>> > disclaimers about not applying it mechanically, reflecting a basic
>> > reasonableness.  Nothing to complain about there.
>>
>> > As a practical matter, the IDEs just default to having PEP8 checking
>> > on, and they do it in a very visual way - akin to a text editor which
>> > puts little squiggles under words it thinks are misspelled.
>>
>> Aha:  The IDEs are the zealots.  :-)
>>
>> (I might liken PEP8 violations to natural language grammar
>> recommendations rather than spelling mistakes:  words are either
>> misspelled or they're not; many grammar "violations" are matters of
>> style, individual preference, or accepted norms that change over time.)
>>
>> I'm not sure I have much to add that hasn't been said already, except
>> perhaps that your issue is, indeed, with the IDEs and the linters rather
>> than with PEP8.
>>
>> Do you tell your students which IDE(s) and linters to use, and/or how to
>> set them up?
>>
>> [...]
>>
>> > I want to get to a world that is, let's say, "== tolerant" ...
>>
>> Do you use floating point values in your course?
>> ___
>> Python-ideas 

[Python-ideas] Re: PEP8 mandatory-is rule

[Nick Parlante]

Hi Chris - well maybe we're looking at different questions. Your examples
show it is possible to construct a data type where == None does not work.
Clearly that is possible.

1. One conclusion is that the possibility of such == means that in general
the == None form is unreliable. This is the proper mindset of the Python
implementation, where the classes that need to work are practically
unlimited, so relying on == would be unreliable as shown.

2. However, I am interested in the mass of ordinary looking programs that
use strings, lists, ints, dicts, tuples, functions etc. to solve some
problem. It's extremely likely that all of the classes in such a program
have a reasonable definitions of ==. So if the programmer knows that, they
can use the "== None" form in complete confidence. It works perfectly.

It's possible to treat (1) as kind definitive, like that possibility ends
the argument. I agree (1) is true, but do not find it convincing about the
(2) case. I think (2) is more useful for thinking about Python programs in
the world.

Best,

Nick


On Tue, Aug 31, 2021 at 1:31 PM Chris Angelico  wrote:

> On Wed, Sep 1, 2021 at 6:06 AM Nick Parlante  wrote:
> > Is there anyone other than me who would like to push for "== None
> tolerant" carve out for non-Python-implementation code?
>
> What you're asking is: Is there anyone other than you who would prefer
> for Python to officially encourage people to write buggy and
> unreliable code?
>
> No.
>
> I'm done discussing this; if you still genuinely think that "== None"
> is actually better than "is None", despite all the demonstrations
> posted, there's no convincing you.
>
> ChrisA
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/KE4C6L63CLEG65ZTCTJKCQ6OPMU3UBIA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KXWBSEO34MKUDATUEJ5U3YCIZXFH7KE2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Chris Angelico]

On Wed, Sep 1, 2021 at 6:06 AM Nick Parlante  wrote:
> Is there anyone other than me who would like to push for "== None tolerant" 
> carve out for non-Python-implementation code?

What you're asking is: Is there anyone other than you who would prefer
for Python to officially encourage people to write buggy and
unreliable code?

No.

I'm done discussing this; if you still genuinely think that "== None"
is actually better than "is None", despite all the demonstrations
posted, there's no convincing you.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KE4C6L63CLEG65ZTCTJKCQ6OPMU3UBIA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Nick Parlante]

Thanks to everyone for many thoughtful comments. I'm going to try to wrap
this up.

So I talked above about how the IDEs have this very visual way of nudging
beginning students to write their code to conform to PEP8, and this is the
IDE default. Mostly this is a great, constructive dynamic, nudging students
to follow the community standard.

As someone who spends all their time in the land of Python-beginners, I
hope this little report of how the IDEs nudge the beginners can be taken as
a success story by people who care about PEP8.

I should say, I'm not worried about Stanford students, they're going to be
fine. In reality, I'm playing a long game here. I'm pushing for Python to
grow to be the dominant intro teaching language (currently it's Java). I do
not want the tooling by default to be flagging correct uses of == for, say,
a highschool student a few years from now who is firing up the IDE to get
started coding. Anyway, this is why I'm trying to get a little shift in the
IDE default now.

I want to get a phrasing into PEP8 so I can go to PyCharm et al, and get a
little shift in their default behavior. PEP8 coloring in the IDE should
remain on by default. That has many fantastic qualities as it works with
the beginning students. But in the default configuration, I want the PEP8
scoring to be tolerant about "== None" for non-Python-implementation code.

My original proposal was to add this parenthetical to the mandatory-is
rule: "(this rule is optional for code that is not part of a Python
implementation)".

Or maybe just a weak nudge to the tooling, like "(it's permissible for
tooling to leave E711 off by default, though it is required for Python
implementation code)". (ht Steven D'Aprano pointing out the proper numbers
https://pep8.readthedocs.io/en/release-1.7.x/intro.html#error-codes)

Then I can go to PyCharm et al and say - hey, for new empty projects could
you please default to PEP8 checking on but E711 off.

Is there support for such a change? The replies on this thread I would say
are mostly not supportive...

Just using Todd recent reply as an example - describing == as "brittle".
Then some point out that understanding equality and identity is important,
so in effect this justifies getting "is" in front of the students even
where == works. Then there's a practical view that being tolerant of "==
None" may be a thing, but messing with PEP8 is not the way.

Is there anyone other than me who would like to push for "== None tolerant"
carve out for non-Python-implementation code?

Best,

Nick

On Tue, Aug 31, 2021 at 12:19 PM <2qdxy4rzwzuui...@potatochowder.com> wrote:

> On 2021-08-31 at 11:15:22 -0700,
> Nick Parlante  wrote:
>
> > As mentioned, PEP8 is formally for narrow cases, and includes
> > disclaimers about not applying it mechanically, reflecting a basic
> > reasonableness.  Nothing to complain about there.
>
> > As a practical matter, the IDEs just default to having PEP8 checking
> > on, and they do it in a very visual way - akin to a text editor which
> > puts little squiggles under words it thinks are misspelled.
>
> Aha:  The IDEs are the zealots.  :-)
>
> (I might liken PEP8 violations to natural language grammar
> recommendations rather than spelling mistakes:  words are either
> misspelled or they're not; many grammar "violations" are matters of
> style, individual preference, or accepted norms that change over time.)
>
> I'm not sure I have much to add that hasn't been said already, except
> perhaps that your issue is, indeed, with the IDEs and the linters rather
> than with PEP8.
>
> Do you tell your students which IDE(s) and linters to use, and/or how to
> set them up?
>
> [...]
>
> > I want to get to a world that is, let's say, "== tolerant" ...
>
> Do you use floating point values in your course?
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/WFXZV25SNM6HRXTURTKK7FJWWRFZO2ZY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3CDZCKRAW3XRKW477ENYTBJ2CKISK7JS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Chris Angelico]

On Wed, Sep 1, 2021 at 5:35 AM Nick Parlante  wrote:
>>
>> > I want to get to a world that is, let's say, "== tolerant" ...
>>
>> Do you use floating point values in your course?
>
>
> You will be relieved to know that  we have great fun showing them how == does 
> not work for floating point numbers. It is super memorable how that all comes 
> unglued.
>

*sigh*

Falsehoods programmers believe about floating point: "Equality is broken".

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4UGAX5HJGSBK6XWFPRISPGLLIC6OT65T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Nick Parlante]

>
> > I want to get to a world that is, let's say, "== tolerant" ...
>
> Do you use floating point values in your course?


You will be relieved to know that  we have great fun showing them how ==
does not work for floating point numbers. It is super memorable how that
all comes unglued.

Best,

Nick


On Tue, Aug 31, 2021 at 12:19 PM <2qdxy4rzwzuui...@potatochowder.com> wrote:

> On 2021-08-31 at 11:15:22 -0700,
> Nick Parlante  wrote:
>
> > As mentioned, PEP8 is formally for narrow cases, and includes
> > disclaimers about not applying it mechanically, reflecting a basic
> > reasonableness.  Nothing to complain about there.
>
> > As a practical matter, the IDEs just default to having PEP8 checking
> > on, and they do it in a very visual way - akin to a text editor which
> > puts little squiggles under words it thinks are misspelled.
>
> Aha:  The IDEs are the zealots.  :-)
>
> (I might liken PEP8 violations to natural language grammar
> recommendations rather than spelling mistakes:  words are either
> misspelled or they're not; many grammar "violations" are matters of
> style, individual preference, or accepted norms that change over time.)
>
> I'm not sure I have much to add that hasn't been said already, except
> perhaps that your issue is, indeed, with the IDEs and the linters rather
> than with PEP8.
>
> Do you tell your students which IDE(s) and linters to use, and/or how to
> set them up?
>
> [...]
>
> > I want to get to a world that is, let's say, "== tolerant" ...
>
> Do you use floating point values in your course?
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/WFXZV25SNM6HRXTURTKK7FJWWRFZO2ZY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DAUPK5LTMWO25FKP22CVLOHNBLLCFBKA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[2QdxY4RzWzUUiLuE]

On 2021-08-31 at 11:15:22 -0700,
Nick Parlante  wrote:

> As mentioned, PEP8 is formally for narrow cases, and includes
> disclaimers about not applying it mechanically, reflecting a basic
> reasonableness.  Nothing to complain about there.

> As a practical matter, the IDEs just default to having PEP8 checking
> on, and they do it in a very visual way - akin to a text editor which
> puts little squiggles under words it thinks are misspelled.

Aha:  The IDEs are the zealots.  :-)

(I might liken PEP8 violations to natural language grammar
recommendations rather than spelling mistakes:  words are either
misspelled or they're not; many grammar "violations" are matters of
style, individual preference, or accepted norms that change over time.)

I'm not sure I have much to add that hasn't been said already, except
perhaps that your issue is, indeed, with the IDEs and the linters rather
than with PEP8.

Do you tell your students which IDE(s) and linters to use, and/or how to
set them up?

[...]

> I want to get to a world that is, let's say, "== tolerant" ...

Do you use floating point values in your course?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WFXZV25SNM6HRXTURTKK7FJWWRFZO2ZY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Todd]

On Tue, Aug 31, 2021 at 2:18 PM Nick Parlante  wrote:

> Hi Steven, I wish I could blame this on zealots, so let me talk a little
> bit about how PEP8 works in education, and I'll talk about moving forward
> in another message.
>
> As mentioned, PEP8 is formally for narrow cases, and includes disclaimers
> about not applying it mechanically, reflecting a basic reasonableness.
> Nothing to complain about there.
>
> As a practical matter, the IDEs just default to having PEP8 checking on,
> and they do it in a very visual way - akin to a text editor which puts
> little squiggles under words it thinks are misspelled.
>
> This maybe sounds annoying, but looking at how people learn to code, it's
> actually fantastic, and a giant success for the goals of PEP8. Instead of
> spending lecture time at some point reviewing rules about spacing or
> whatever, the students are absorbing that stuff just imperceptibly as the
> IDE is nudging them the right way by putting little colored marks around
> code it doesn't like. PEP8 contains a bunch of conventions, and now you
> have this crop of junior programmers who have absorbed the important ones,
> thus avoiding future pointless bikeshed wars.
>
> I hope people who care about PEP8 can have a moment of satisfaction,
> appreciating how IDEs have become a sort of gamified instrument to bring
> PEP8 to the world at low cost. So that's the good news.
>
> The visual quality that makes the IDEs so effective, also loses all the
> nuance. I have tried to explain to the students this or that they can let
> slide, but as a matter of human nature, it's hopeless. They want to get rid
> of the IDE marked code. And keep in mind, their devotion to that is mostly
> a force for good.
>
> So this basically great, but rather inflexible dynamic of the students,
> the IDEs, and PEP8 is what brings me here.
>
> I want to get to a world that is, let's say, "== tolerant". I claim you
> can teach a nice intro course using == early in the course, and many people
> have chimed in that they feel there's value in "is". I want to work out a
> solution between PEP8 and the IDEs where both approaches are permitted.
>
> Let me write up some proposals in a separate message, and people can
> comment on those.
>
> Best,
>
> Nick
>

Before we can start talking about solutions, we need to first establish
there is an actual problem to be solved to begin with. Nobody who has
commented here agrees with you on that. So you need to convince people this
is actually something that needs to be fixed in the first place before
anyone will consider any fixes. Using "==" is a brittle approach that will
only work if you are lucky and only get certain sort of data types. "is"
works no matter what. The whole point of Python in general and pep8 in
particular is to encourage good behavior and discourage bad behavior, so
you have an uphill battle convincing people to remove a rule that does
exactly that.

People learning Python MUST know the difference between equality and
identity. It is one of the most central aspects of the language, and they
WILL write horribly broken code if they don't, even at a beginner level. So
we are talking about an issue that will only ever slightly and briefly
surprise the very most beginning students, assuming they have an IDE
that marks pep8 violations and assuming their lecturers don't just tell
them to turn that feature off until it is needed or give them a config file
to change it. That is not sufficient justification to throw away a good
rule that exists for a good reason.

So my proposal is for you to treat it as a learning opportunity for your
students rather than an obstacle. They need to learn about the distinction
between equality and identity, ideally sooner rather than later, and this
is a great jumping-off point for that.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PZIX5G5L3OXVXINAKOM7Q2PYJLVN5JT5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[Nick Parlante]

Hi Steven, I wish I could blame this on zealots, so let me talk a little
bit about how PEP8 works in education, and I'll talk about moving forward
in another message.

As mentioned, PEP8 is formally for narrow cases, and includes disclaimers
about not applying it mechanically, reflecting a basic reasonableness.
Nothing to complain about there.

As a practical matter, the IDEs just default to having PEP8 checking on,
and they do it in a very visual way - akin to a text editor which puts
little squiggles under words it thinks are misspelled.

This maybe sounds annoying, but looking at how people learn to code, it's
actually fantastic, and a giant success for the goals of PEP8. Instead of
spending lecture time at some point reviewing rules about spacing or
whatever, the students are absorbing that stuff just imperceptibly as the
IDE is nudging them the right way by putting little colored marks around
code it doesn't like. PEP8 contains a bunch of conventions, and now you
have this crop of junior programmers who have absorbed the important ones,
thus avoiding future pointless bikeshed wars.

I hope people who care about PEP8 can have a moment of satisfaction,
appreciating how IDEs have become a sort of gamified instrument to bring
PEP8 to the world at low cost. So that's the good news.

The visual quality that makes the IDEs so effective, also loses all the
nuance. I have tried to explain to the students this or that they can let
slide, but as a matter of human nature, it's hopeless. They want to get rid
of the IDE marked code. And keep in mind, their devotion to that is mostly
a force for good.

So this basically great, but rather inflexible dynamic of the students, the
IDEs, and PEP8 is what brings me here.

I want to get to a world that is, let's say, "== tolerant". I claim you can
teach a nice intro course using == early in the course, and many people
have chimed in that they feel there's value in "is". I want to work out a
solution between PEP8 and the IDEs where both approaches are permitted.

Let me write up some proposals in a separate message, and people can
comment on those.

Best,

Nick






On Mon, Aug 30, 2021 at 6:36 PM Steven D'Aprano  wrote:

> 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 think Guido is likewise not convinced that they are a good
> idea.
>
> Anyway, it doesn't matter. Your IDE ought to be configurable to enable
> or disable that rule. For example:
>
> https://www.jetbrains.com/help/pycharm/configuring-code-style.html
>
> You ought to be able to come up with a config that disables that
> specific rule, and distribute it to your students automatically. You may
> need to determine which linter the IDE uses to check for style
> violations, and provide a config specifically for that linter.
>
> If you tell us what IDE your school or department uses, we might even be
> able to tell you what config you need.
>
> And in practical terms, that will likely be much, much faster than
> waiting for us to change PEP 8, the linters to change their tests, and
> the IDEs to be updated to use the new versions of the linters.
>
> > Here is my proposal:
> >
> > Add the following parenthetical to the mandatory-is rule: (this rule
> > is optional for code that is not part of an implementation of Python).
>
> None of PEP-8 is mandatory except for the stdlib, and even there, it's
> more of a guideline than a rule.
>
> Why do PEP-8 zealots never, ever read the most important rule of PEP-8?
> It's right at the top too, just after the introduction. (Sorry Nick,
> this is not aimed at you personally.)
>
>
> https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds
>
>
>
> --
> Steve
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/QSECKF7K4MKOMJGINJFZGLBW4MOKY74Q/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CMI3MVFKT6A6FA5KBR2AUWNHL5YLZZUE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP8 mandatory-is rule

[David Mertz, Ph.D.]

There doesn't SEEM to be any way to get a non-singleton None in Python 1.0

% python
Python 1.0.1 (Jul 15 2016)
Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam
>>> x = None
>>> type(x)

>>> id(None)
6587488
>>> y = None
>>> x is y
1
>>> id(x)
6587488

Restarting the interpreter, I even get the same id():

% python
Python 1.0.1 (Jul 15 2016)
Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam
>>> id(None)
6587488

There might be some weird and clever way to get a non-unique None out of
Python 1.0.  But it's not anything obvious.

Btw. The date given isn't the release date, obviously. It's when Anaconda
Inc. made a package of 1.0.1 as a cute gesture on conda-forge.  But they
just did it with the original source code, it's not enhanced functionally.

On Tue, Aug 31, 2021 at 9:51 AM Calvin Spealman  wrote:

> I think the provenance of the "is None" rule comes from before None was a
> guaranteed singleton. In older versions of Python, it was *possible* to
> instantiate more instances of None. So it was possible for "x == None" to
> fail even if x was *a* None.
>
> While the community is very used to and invested in the style, from a
> practical perspective I don't think "x == None" is necessary wrong anymore.
>
> On Mon, Aug 30, 2021 at 2:45 PM 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
>> can be made to make it optional, so let me know what you think.
>>
>> Let me start with what I've learned from teaching students in Java and
>> now in Python. In Java, you use == for ints, but you need to use
>> equals() for strings. Of course students screw this up constantly,
>> using == in a context that calls for equals() and their code does not
>> work right. Then for Java arrays a different comparison function is
>> required, and so it goes. To teach comparisons in Python, I simply say
>> "just use ==" - it works for ints, for strings, even for lists.
>> Students are blown away by how nice and simple this is. This is how
>> things should work. Python really gets this right.
>>
>> So what is the problem?
>>
>> 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.
>>
>> For the students, this comes up in the first week of the course with
>> lines like "if x == None:" which work perfectly with == but should use
>> is/is-not for PEP8 conformance.
>>
>> My guess is that this rule is in PEP8 because, within a Python
>> implementation, it is within the programmer's mental model that, say,
>> False is a singleton. The mandatory-is rule is in PEP8 to reinforce
>> that mental model by requiring the is operator. Plus it probably runs
>> a tiny bit faster.
>>
>> However, for "regular" Python code, not implementing Python, forcing
>> the use of is instead of the simpler == is unneeded and unhelpful (and
>> analogously forcing "is not" when != works correctly). What is the
>> benefit of forcing the is operator there? I would say it spreads an
>> awareness of the details of how certain values are allocated within
>> Python. That's not much of a benefit, and it's kind of circular. Like
>> if programmers were permitted to use ==, they wouldn't need to know
>> the details of how Python allocates those values. Being shielded from
>> implementation details is a Python strength - think of the Java vs.
>> Python story above. Is Java better because it builds an awareness in
>> the programmer of the different comparison functions for different
>> types? Of course not! Python is better in that case because it lets
>> the programmer simply use == and not think about those details.
>> Understanding the singleton strategy is important in some corners of
>> coding, but forcing the is operator on all Python code is way out of
>> proportion to the benefit.
>>
>> 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. Mostly this IDE-coaching is very helpful for students learning
>> Python. For example, It's great that beginning Python programmers
>> learn to put one space around operators right from the first day.
>> Having taught thousands of introductory Python students, the one PEP8
>> rule that causes problems is this mandatory-is rule.
>>
>> As a teacher, this is especially jarring since the "just use ==" rule
>> is so effortless to use correctly. In contrast, the mandatory-is rule
>> adds a little pause where the programmer should think about which
>> comparison operator is the correct one to use. It's not hard, but it
>> feels unnecessary.
>>
>> As a contrasting example, in the language C, programmers need to
>> 

[Python-ideas] Re: PEP8 mandatory-is rule

[Richard Damon]

> On Aug 31, 2021, at 9:52 AM, Calvin Spealman  wrote:
> 
> 
> I think the provenance of the "is None" rule comes from before None was a 
> guaranteed singleton. In older versions of Python, it was possible to 
> instantiate more instances of None. So it was possible for "x == None" to 
> fail even if x was *a* None.
> 
> While the community is very used to and invested in the style, from a 
> practical perspective I don't think "x == None" is necessary wrong anymore.

Unless x is a type that redefines == like numpy does. Then you don’t get the 
answer you might expect.
> 
>> On Mon, Aug 30, 2021 at 2:45 PM 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
>> can be made to make it optional, so let me know what you think.
>> 
>> Let me start with what I've learned from teaching students in Java and
>> now in Python. In Java, you use == for ints, but you need to use
>> equals() for strings. Of course students screw this up constantly,
>> using == in a context that calls for equals() and their code does not
>> work right. Then for Java arrays a different comparison function is
>> required, and so it goes. To teach comparisons in Python, I simply say
>> "just use ==" - it works for ints, for strings, even for lists.
>> Students are blown away by how nice and simple this is. This is how
>> things should work. Python really gets this right.
>> 
>> So what is the problem?
>> 
>> 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.
>> 
>> For the students, this comes up in the first week of the course with
>> lines like "if x == None:" which work perfectly with == but should use
>> is/is-not for PEP8 conformance.
>> 
>> My guess is that this rule is in PEP8 because, within a Python
>> implementation, it is within the programmer's mental model that, say,
>> False is a singleton. The mandatory-is rule is in PEP8 to reinforce
>> that mental model by requiring the is operator. Plus it probably runs
>> a tiny bit faster.
>> 
>> However, for "regular" Python code, not implementing Python, forcing
>> the use of is instead of the simpler == is unneeded and unhelpful (and
>> analogously forcing "is not" when != works correctly). What is the
>> benefit of forcing the is operator there? I would say it spreads an
>> awareness of the details of how certain values are allocated within
>> Python. That's not much of a benefit, and it's kind of circular. Like
>> if programmers were permitted to use ==, they wouldn't need to know
>> the details of how Python allocates those values. Being shielded from
>> implementation details is a Python strength - think of the Java vs.
>> Python story above. Is Java better because it builds an awareness in
>> the programmer of the different comparison functions for different
>> types? Of course not! Python is better in that case because it lets
>> the programmer simply use == and not think about those details.
>> Understanding the singleton strategy is important in some corners of
>> coding, but forcing the is operator on all Python code is way out of
>> proportion to the benefit.
>> 
>> 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. Mostly this IDE-coaching is very helpful for students learning
>> Python. For example, It's great that beginning Python programmers
>> learn to put one space around operators right from the first day.
>> Having taught thousands of introductory Python students, the one PEP8
>> rule that causes problems is this mandatory-is rule.
>> 
>> As a teacher, this is especially jarring since the "just use ==" rule
>> is so effortless to use correctly. In contrast, the mandatory-is rule
>> adds a little pause where the programmer should think about which
>> comparison operator is the correct one to use. It's not hard, but it
>> feels unnecessary.
>> 
>> As a contrasting example, in the language C, programmers need to
>> understand == vs. is right from the first day. You can't get anything
>> done in C without understanding that distinction. However that is just
>> not true for regular (not-Python-implementation) Python code, where ==
>> works correctly for the great majority of cases.
>> 
>> Here is my proposal:
>> 
>> Add the following parenthetical to the mandatory-is rule: (this rule
>> is optional for code that is not part of an implementation of Python).
>> 
>> So in effect, programmers outside of a Python implementation can
>> choose to use == or is for the "if x == None:" case. In this way, PEP8
>> conforming code before the change is still conforming. Moving 

[Python-ideas] Re: PEP8 mandatory-is rule

[Calvin Spealman]

I think the provenance of the "is None" rule comes from before None was a
guaranteed singleton. In older versions of Python, it was *possible* to
instantiate more instances of None. So it was possible for "x == None" to
fail even if x was *a* None.

While the community is very used to and invested in the style, from a
practical perspective I don't think "x == None" is necessary wrong anymore.

On Mon, Aug 30, 2021 at 2:45 PM 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
> can be made to make it optional, so let me know what you think.
>
> Let me start with what I've learned from teaching students in Java and
> now in Python. In Java, you use == for ints, but you need to use
> equals() for strings. Of course students screw this up constantly,
> using == in a context that calls for equals() and their code does not
> work right. Then for Java arrays a different comparison function is
> required, and so it goes. To teach comparisons in Python, I simply say
> "just use ==" - it works for ints, for strings, even for lists.
> Students are blown away by how nice and simple this is. This is how
> things should work. Python really gets this right.
>
> So what is the problem?
>
> 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.
>
> For the students, this comes up in the first week of the course with
> lines like "if x == None:" which work perfectly with == but should use
> is/is-not for PEP8 conformance.
>
> My guess is that this rule is in PEP8 because, within a Python
> implementation, it is within the programmer's mental model that, say,
> False is a singleton. The mandatory-is rule is in PEP8 to reinforce
> that mental model by requiring the is operator. Plus it probably runs
> a tiny bit faster.
>
> However, for "regular" Python code, not implementing Python, forcing
> the use of is instead of the simpler == is unneeded and unhelpful (and
> analogously forcing "is not" when != works correctly). What is the
> benefit of forcing the is operator there? I would say it spreads an
> awareness of the details of how certain values are allocated within
> Python. That's not much of a benefit, and it's kind of circular. Like
> if programmers were permitted to use ==, they wouldn't need to know
> the details of how Python allocates those values. Being shielded from
> implementation details is a Python strength - think of the Java vs.
> Python story above. Is Java better because it builds an awareness in
> the programmer of the different comparison functions for different
> types? Of course not! Python is better in that case because it lets
> the programmer simply use == and not think about those details.
> Understanding the singleton strategy is important in some corners of
> coding, but forcing the is operator on all Python code is way out of
> proportion to the benefit.
>
> 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. Mostly this IDE-coaching is very helpful for students learning
> Python. For example, It's great that beginning Python programmers
> learn to put one space around operators right from the first day.
> Having taught thousands of introductory Python students, the one PEP8
> rule that causes problems is this mandatory-is rule.
>
> As a teacher, this is especially jarring since the "just use ==" rule
> is so effortless to use correctly. In contrast, the mandatory-is rule
> adds a little pause where the programmer should think about which
> comparison operator is the correct one to use. It's not hard, but it
> feels unnecessary.
>
> As a contrasting example, in the language C, programmers need to
> understand == vs. is right from the first day. You can't get anything
> done in C without understanding that distinction. However that is just
> not true for regular (not-Python-implementation) Python code, where ==
> works correctly for the great majority of cases.
>
> Here is my proposal:
>
> Add the following parenthetical to the mandatory-is rule: (this rule
> is optional for code that is not part of an implementation of Python).
>
> So in effect, programmers outside of a Python implementation can
> choose to use == or is for the "if x == None:" case. In this way, PEP8
> conforming code before the change is still conforming. Moving forward,
> I would expect that regular code will trend towards using == in such a
> case, reserving is for the rare cases where it is needed for
> correctness.
>
> PEP8 was originally just for Python implementations, so why is this
> change needed? Because as a practical matter, 

[Python-ideas] Re: NAN handling in statistics functions

[Ricky Teachey]

On Tue, Aug 31, 2021 at 9:17 AM Ricky Teachey  wrote:

> Can someone explain why enum-vs-string is being discussed as if it is an
> either-or choice? Why not just call the enum class using the input so that
> you can supply a string or enum?I understand this would not be a really
> great choice for a flags enum or int enum, but for single-choice strings,
> it seems like a reasonable approach to me.
>
> 
>
> ...in the past, I have used enums like this in my own code mostly as 1. a
> documentation feature so I can easily remember what the valid choices are,
> and 2. an easy error catcher since you get a nice exception when you supply
> an invalid string to the enum class:
>

Whoops, the repl session was incorrect, apologies. Hopefully it was clear
what I meant. Corrected version below.

>> class MyEnum(Enum):
...  a = "a"
...  b = "b"
...
>>> MyEnum("c")
Traceback (most recent call last):
  File "", line 1, in 
  File "c:\program files\python39\lib\enum.py", line 384, in __call__
return cls.__new__(cls, value)
  File "c:\program files\python39\lib\enum.py", line 702, in __new__
raise ve_exc
ValueError: 'c' is not a valid MyEnum


---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/AVHR7STJZQQQCPP3JIBSL27FYYNYINXE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: NAN handling in statistics functions

[Ricky Teachey]

Can someone explain why enum-vs-string is being discussed as if it is an
either-or choice? Why not just call the enum class using the input so that
you can supply a string or enum?

NanChoice(nan_choice_input)

I understand this would not be a really great choice for a flags enum or
int enum, but for single-choice strings, it seems like a reasonable
approach to me.

In the example below from my own code I just call the enums using the input
strings so that whether I decide to pass in a string, or import and use an
actual enum object, it will work fine either way.

from enum import Enum
import pandas as pd


class LoadType(Enum):
dead = "D"
live = "L"
snow = "S"
wind = "W"
seismic = "E"
D = "D"
L = "L"
S = "S"
W = "W"
E = "E"


class RiskCategory(Enum):
"""Risk Category of Buildings and Other Structures for Flood,
Wind, Snow, Earthquake, and Ice Loads.

cf. Table 1.5-1
"""
I = "I"
II = "II"
III = "III"
IV = "IV"


_Table_1_pt_5_dsh_2 = pd.DataFrame({LoadType.snow: [0.80, 1.00, 1.10, 1.20],
 LoadType.seismic: [1.00, 1.00, 1.25, 1.50]},
index=list(RiskCategory))


def importance_factor(load_type_input):
return lambda risk_input:
_Table_1_pt_5_dsh_2[LoadType(load_type_input)][RiskCategory(risk_input)]


Maybe this idea sucks? I don't have any way of knowing since nobody reads
my code other than future me (who happens to be somewhat dim), but in the
past, I have used enums like this in my own code mostly as 1. a
documentation feature so I can easily remember what the valid choices are,
and 2. an easy error catcher since you get a nice exception when you supply
an invalid string to the enum class:

>>> class MyEnum(Enum):
...  a: "a"
...  b: "b"
...
>>> MyEnum("c")
Traceback (most recent call last):
  File "", line 1, in 
  File "c:\program files\python39\lib\enum.py", line 384, in __call__
return cls.__new__(cls, value)
  File "c:\program files\python39\lib\enum.py", line 702, in __new__
raise ve_exc
ValueError: 'c' is not a valid MyEnum


Could this approach be useful for handling nans in the stats module? Maybe
the overhead of calling the enum be considered too high or something?


---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZH4CCDFTGZRCO6XBNMM354HOHLPNDUR5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: NAN handling in statistics functions

[Chris Angelico]

On Tue, Aug 31, 2021 at 9:51 PM Steven D'Aprano  wrote:
> > I want to (in iPython) do:
> >
> > statistics.median?
> >
> > and see everything I need to know to use it
>
>
> Okay, so if the API is (say) this:
>
> def median(data, *, nans='ignore'):
> ...
>
>
> will iPython give you a list of all the other possible strings that are
> accepted? How does it know?
>

Specific example: does any linter or IDE check for this?

open(fn, encoding="utf-8", errors="strick")

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DUQTURNIKSIPDBI5SWGKZR4R4WAPNUFW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: NAN handling in statistics functions

[Steven D'Aprano]

On Mon, Aug 30, 2021 at 10:37:28PM -0700, Christopher Barker wrote:
> 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 to poke at a dunder to get the information ?!?

Seems pretty easy to me. It has to be a dunder, or a sunder at least, 
because regular non-underscore names are reserved for the enumerations 
themselves.

How do you programmatically get the information about which encoding 
error handlers the `open` function takes?

I don't know how to get them programmatically, but today I learned how 
to get them from the documentation:

* Start with help(open)
* Page down two pages.
* import codecs
* help(codecs.Codec)

That gives you the predefined error handlers, assuming the docs are up 
to date. I still don't know how to find out what extra handlers have 
been installed.



> I want to (in iPython) do:
> 
> statistics.median?
> 
> and see everything I need to know to use it


Okay, so if the API is (say) this:

def median(data, *, nans='ignore'):
...


will iPython give you a list of all the other possible strings that are 
accepted? How does it know?



-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OH4AW3LYS3355FORXY5OWVXCJRGFPEAE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: NAN handling in statistics functions

[Ronald Oussoren via Python-ideas]

> On 30 Aug 2021, at 18:19, 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?  The enum clearly 
> documents what the valid options are for the option.
> 
> So does documentation (docstrings, useful error messages). I don't think the 
> documentation built in to an Enum is any easier to access.

The enum definition shows the valid names that can be used, string literals are 
more open ended. Documentation helps, but can get out of sync.

> In fact, looking now, I'm trying to see how an Enum provides any easy to 
> access documentation -- other than looking at the creation code. As a rule, I 
> don't think Enums provide documentation of the valid values, but rather, 
> enforcement.
> 
> e.g.: what are the valid values? what do they mean?
> 
> 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 string flags.
> 
> I suppose they provide a real advantage for static typing, but other than 
> that I just don't see it.

Not just static typing, but static analysis in general. Tools like flake8 will 
complain about typos, completion tools can help typing, ….

> 
> But what they do is create a  burden of extra code to read and write. Compare:
> 
> from statistics import median
> 
> result = median(the_data, nan_policy='omit')
> 
> with:
> 
> from statistics import median, NaNPolicy
> 
> result = median(the_data, nan_policy=NaNPolicy.Omit)
> 
> or maybe:
> 
> import statistics as stats
> 
> result = stats.median(the_data, nan_policy=stats.Omit)

It is not necessarily a hard choice, it is possible to define enums that can be 
compared with strings, such as:

class NanPolicy(str, enum.Enum):
….

> 
> There are any number of ways to import, and names to create, but they all 
> seem to me to be more awkward to use than a simple text flag.
> 
> Ever since I started using Python, I've really appreciated the use of string 
> flags :-)

I tend to use constants instead of string literals because of better static 
analysis, and try to convert uses to enums over time.  String flags work as 
well, but I’ve had too much problems due to typo’s in string literals that 
weren’t caught by incomplete tests.  Being able to at least run a listing tool 
to find basic issues like typo’s is very convenient.  But YMMV.

> 
> I do see how using an Enum makes things a bit easier for the author of a 
> package (more DRY), but I don't think that should be the priority here.
> 
> No one needs to convince me, but I would be interested in seeing the 
> recommended way to import and use Enum flags - maybe it doesn't have to be as 
> awkward as I think it is.

I have no opinion on this particular API discussion, my question was  out of 
interest in this particular remark.

Ronald
> 
> -CHB
> 
> 
> -- 
> Christopher Barker, PhD (Chris)
> 
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython

—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/AW6EIMONXDVJNUB7PK4VL2MW5D5FQUCW/
Code of Conduct: http://python.org/psf/codeofconduct/