On Tue, Aug 31, 2021 at 06:18:15PM -0400, Todd wrote:
> 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.
In fairness to Nick,
Maybe I'm missing something, but I don't think that there is anyway to
remove a warning from the warnings filter list so that it will be shown
again.
Example:
>>> import warnings
>>> warnings.warn("something happened")
:1: UserWarning: something happened
>>> warnings.warn("somet
On Wed, Sep 1, 2021 at 5:19 PM Steven D'Aprano wrote:
> Outside of contrived counter-examples, we're not likely to come across
> anything trying to mimac None in the real world. But that's not really
> why we use `is`, or at least, it's not the only reason. There are a
> bunch of reasons, none of
On 01.09.2021 10:27, Chris Angelico wrote:
> On Wed, Sep 1, 2021 at 5:19 PM Steven D'Aprano wrote:
>> Outside of contrived counter-examples, we're not likely to come across
>> anything trying to mimac None in the real world. But that's not really
>> why we use `is`, or at least, it's not the only
On Wed, Sep 01, 2021 at 05:27:40PM +1000, Steven D'Aprano wrote:
> Maybe I'm missing something, but I don't think that there is anyway to
> remove a warning from the warnings filter list so that it will be shown
> again.
>
> Example:
>
> >>> import warnings
> >>> warnings.warn("somethin
On Wed, Sep 1, 2021 at 6:55 PM Marc-Andre Lemburg wrote:
> BTW: In SQL you have to use "field IS NULL", "field = NULL" returns
> NULL, so you're not any smarter than before :-)
That's because NULL is kinda like None, kinda like NaN, kinda like "we
don't have any data here", and kinda like "we do
On Tue, Aug 31, 2021 at 09:49:36AM -0400, 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.
I don't suppose you can show how that works?
On 01/09/2021 09:27, Steven D'Aprano wrote:
Maybe I'm missing something, but I don't think that there is anyway to
remove a warning from the warnings filter list so that it will be shown
again.
Example:
>>> import warnings
>>> warnings.warn("something happened")
:1: UserWarning:
Can you redefine the name, “None” in ancient Python?
-CHB
--
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
___
Python-
On Wed, Sep 1, 2021, 11:55 AM Christopher Barker
wrote:
> Can you redefine the name, “None” in ancient Python?
>
I didn't show it in my earlier post, but in Python 1.0.1, you an indeed
rebind the name None (much as you could True/False until 2.4 or
something... I probably have the version wrong
Given code like this:
```
d = {1: {2: {3: 4}}}
print(d[1][2][3])
d[1][2][3] = None
print(d)
```
It should be possible to rewrite it using a starred expression, like this:
```
d = {1: {2: {3: 4}}}
keys= 1,2,3
print(d[*keys])
d[*keys] = None
print(d)
```
Hopefully it's clear from that example wha
Wow Matthias, you are like the pied piper of weird == implementations!
I'm glad you were able to put those in the discussion. To check into Python
and its standard modules itself ... I can imagine putting together a grep
type thing to just dig all the __eq__ out of there and look at them. Like
how
On 2021-09-01 17:41, Kevin Mills wrote:
Given code like this:
```
d = {1: {2: {3: 4}}}
print(d[1][2][3])
d[1][2][3] = None
print(d)
```
It should be possible to rewrite it using a starred expression, like this:
```
d = {1: {2: {3: 4}}}
keys= 1,2,3
print(d[*keys])
d[*keys] = None
print(d)
```
On Wed, Sep 1, 2021, 03:18 Steven D'Aprano wrote:
> On Tue, Aug 31, 2021 at 06:18:15PM -0400, Todd wrote:
>
> > 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
>
> In fairness to Nick, he is not talking about the real world. Nick is
> talking about the hot-house environment of *education*, where fragile
> newbies are generally protected from real world issues.
Let me unpack this just a teeny bit. We don't need to think of the students
as fragile. Think
No, definitely not. d[1,2,3] and d[1][2][3] are not the same thing. The latter
is what I am talking about.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mail
On Wed, Sep 1, 2021 at 1:32 PM Nick Parlante wrote:
> In fairness to Nick, he is not talking about the real world. Nick is
>> talking about the hot-house environment of *education*, where fragile
>> newbies are generally protected from real world issues.
>
>
> Let me unpack this just a teeny bit.
On Wed, Sep 1, 2021 at 12:45 PM Kevin Mills
wrote:
> d = {1: {2: {3: 4}}}
> keys= 1,2,3
> print(d[*keys]) # Meaning: d[1][2][3]
> d[*keys] = None
> print(d)
This is a bad idea for a couple reasons.
One reason MRAB points to. The `*keys` syntax is more-or-less equivalent
to "substitute a tupl
Hi Ricky,
A couple people have said this but I'll ask again because I am curious:
> would it be possible to delay introduction of None entirely until it's time
> to introduce is?
>
This maybe comes down to course tactics. I happen to like doing algorithms
with data arranged in 2d from the start -
Sorry, replying to myself here, to complete the story here.
Or put another way, None is a pretty core Python topic, so there's no sense
in dancing around it too much. Really "is" is the problem. I'd rather get
into the details of "is" later in the course.
So I think two approaches are plausible h
> In fairness to Nick, he is not talking about the real world. Nick is
> talking about the hot-house environment of *education*, where fragile
> newbies are generally protected from real world issues.
Sure, but PEP8 is about the real world. Which is why I suggested that Nick
might want to create
Nick. I think you should realize that I—and a number of the other people
who dislike your elliding the difference between equality and identity—also
teach beginning programmers.
> 1. You could use "is", and say "It's most proper to use "is" when
> comparing to certain values, including None whic
On Wed, Sep 1, 2021 at 12:22 PM Nick Parlante wrote:
> Or put another way, None is a pretty core Python topic, so there's no
> sense in dancing around it too much. Really "is" is the problem.
>
Indeed, that's quite true.
However, while students will see None very early on in their Python
experi
On 2021-09-01 10:28, Nick Parlante wrote:
Now for Python, == vs. is nothing like that bad. Both == and is are
sensible, necessary parts of the language, I would just prefer to talk
about == earlier and is later. Of the two, == is the no-brainer one when
the students just have ints and strings, an
On Wed, Sep 01, 2021 at 03:40:37PM +0200, Peter Otten wrote:
> Instead of removing it you might add a filter to get a similar effect:
[...]
> >>> warnings.filterwarnings("always", "woof!")
Unfortunately that's too aggressive. In my use-case, `bark` will be
called many, many times in a loop, an
On Wed, Sep 1, 2021 at 6:58 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Wed, Sep 01, 2021 at 05:27:40PM +1000, Steven D'Aprano wrote:
> > Maybe I'm missing something, but I don't think that there is anyway to
> > remove a warning from the warnings filter list so that it will be shown
> > again.
>
On Wed, Sep 01, 2021 at 12:07:52PM -0400, David Mertz, Ph.D. wrote:
> On Wed, Sep 1, 2021, 11:55 AM Christopher Barker
> wrote:
>
> > Can you redefine the name, “None” in ancient Python?
> >
>
> I didn't show it in my earlier post, but in Python 1.0.1, you an indeed
> rebind the name None (much
On Wed, Sep 01, 2021 at 02:33:20PM -0700, Brendan Barnwell wrote:
> There is nothing wrong, in my view, with a teaching approach that
> tells people to do a thing one way and then later tells them to move on
> to
> a different way.
This! +1
https://en.wikipedia.org/wiki/Lie-to-chi
On Tue, Aug 31, 2021 at 05:17:35PM -0700, Matthias Bussonnier wrote:
> 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 ==.
I agree with Oscar that the various objects you l
29 matches
Mail list logo
