[Python-Dev] Re: Switching to Discourse

[Gordon R. Burgess]

I am a long time lurker here*, a professional and educational user of
the language, a list moderator with practical exeperience managing a
engaged community of a few thousand users over the course of a decade -
and yes, I am old.

I saw what happened when the young developers there insisted that we'd
all be much happier with a threaded forum - so nice, if what you want
is to browse a web page, or to find all of the points in a (hopefully)
threaded discussion.

We were all assured that we could continue to participate in the new
forum in whatever way we wanted, and in particular that access by email
would be just as nice as ever.

That community still has a website, and I suppose people post on it,
but as I am not the equivalent of a "core dev" I have no reason to post
there, and more to the point the community has migrated away from the
comerderie that was widely experienced on the discussion lists.

The email communities died, and anyone who didn't have to "work" for
the organization went elsewhere.

So my observation is that the loudest voices for retiring an email list
(or IRC channel) will be exactly the people that don't use those
things, and seem to think no one else does either.  I can readily allow
that those of you who do the work here and sort stuff out will find
utility in a threaded forum - but if you lose the list, it won't come
back.  Perhaps "you" don't care - things change, and user preferences
shift.  I wouldn't want my preferences to constrain how the core devs
do their work.  But if you do not enjoy getting emails, perhaps you
should remember that some of us do.

Gordon

*i joined to raise an issue regarding the re library that seemed
significant to me at the time, and decided that what you all were doing
was interesting enough for me to continue to follow as it unfolded



On Fri, 2022-12-02 at 14:40 +0100, Baptiste Carvello wrote:
> Le 02/12/2022 à 10:09, Gregory P. Smith a écrit :
> > 
> > On Thu, Dec 1, 2022 at 8:37 AM Victor Stinner  > > wrote:
> > 
> > 
> >     Should we *close* the python-dev mailing list?
> > 
> > 
> > I'd be in favor of this. 
> 
> Why? Californian firms won't let their employees use an unmoderated
> forum for fear of liability: OK, so be it. But that's no reason to
> force
> other people to use tools they dislike. "Modern tools" hegemonism is
> little more than pure intolerance.
> 
> Or at least setting up an auto-responder
> > suggesting people post on discuss.python.org
> > 
> > instead.
> 
> Just put a line in the list signature stating that discussions
> requiring
> core-dev attention should happen on discourse, and be done.
> 
> Cheers,
> Baptiste
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/IDKDF7P4WTNVZNJHJZIEQB2M42THOJ3V/
> Code of Conduct: http://python.org/psf/codeofconduct/


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

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

[Eric Snow]

On Mon, Nov 28, 2022 at 6:45 PM Steven D'Aprano  wrote:
> On Tue, Nov 29, 2022 at 01:34:54PM +1300, Greg Ewing wrote:
> > I got the impression that there were some internal language reasons
> > to want stable dicts, e.g. so that the class dict passed to __prepare__
> > preserves the order in which names are assigned in the class body. Are
> > there any such use cases for stable sets?
>
> Some people wanted order preserving kwargs, I think for web frameworks.
> There was even a discussion for a while about using OrderedDict for
> kwargs and leaving dicts unordered.

See https://peps.python.org/pep-0468/ (kwargs) and
https://peps.python.org/pep-0520/ (class definition body).  I
re-implemented OrderedDict in C for this purpose.  Literally right
after I had finished that, Inada-san showed up with his compact dict
implementation.  Many of us were at the first core sprint at the time
and there was a lot of excitement about compact dict.  It was merged
right away (for 3.6) and there was quick agreement that we could
depend on dict insertion ordering internally (for a variety of use
cases, IIRC).  Thus, suddenly both my PEPs were effectively
implemented, so we marked them as approved and moved on.

FWIW, making the insertion ordering an official part of the language
happened relatively soon afterward, though for 3.7, not 3.6. [1]  I'm
pretty sure there's a python-dev thread about that.  The stdtypes docs
were updated [2] soon after, and we finally got around to updating the
language [3] a couple years later.

-eric


[1] https://docs.python.org/3/whatsnew/3.7.html#summary-release-highlights
[2] https://bugs.python.org/issue33609
[3] https://bugs.python.org/issue39879
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5QYN66BWHO4GHWD34DIY43NLBMAM4UPZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Brett Cannon]

On Fri, Dec 2, 2022 at 8:17 AM Baptiste Carvello <
devel2...@baptiste-carvello.net> wrote:

> Le 02/12/2022 à 10:09, Gregory P. Smith a écrit :
> >
> > On Thu, Dec 1, 2022 at 8:37 AM Victor Stinner  > > wrote:
> >
> >
> > Should we *close* the python-dev mailing list?
> >
> >
> > I'd be in favor of this.
>
> Why?


Because in the past people have complained about having too many places to
keep track of discussions (and this goes in both directions; some people
don't read email regularly while others live in their inbox). Since we are
promoting/pushing folks to use discuss.python.org it means this mailing
list starts to feel like more of a burden/excess.

-Brett


> Californian firms won't let their employees use an unmoderated
> forum for fear of liability: OK, so be it. But that's no reason to force
> other people to use tools they dislike.


We are just saying that we may, as a team, not want to be the people
providing a mailing list for folks to use to discuss Python development. Or
at the very least not make it feel like a requirement for core devs to
monitor this mailing list like it has been in the past. If people choose to
keep using email then they can choose to do so on their own, just like IRC
or any other place people chat.

-Brett


> "Modern tools" hegemonism is
> little more than pure intolerance.
>
> Or at least setting up an auto-responder
> > suggesting people post on discuss.python.org 
> > instead.
>
> Just put a line in the list signature stating that discussions requiring
> core-dev attention should happen on discourse, and be done.
>
> Cheers,
> Baptiste
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/IDKDF7P4WTNVZNJHJZIEQB2M42THOJ3V/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VJMEAXDGZBENDSCIIFZM65SHK7VEU3QJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Baptiste Carvello]

Le 02/12/2022 à 10:09, Gregory P. Smith a écrit :
> 
> On Thu, Dec 1, 2022 at 8:37 AM Victor Stinner  > wrote:
> 
> 
> Should we *close* the python-dev mailing list?
> 
> 
> I'd be in favor of this. 

Why? Californian firms won't let their employees use an unmoderated
forum for fear of liability: OK, so be it. But that's no reason to force
other people to use tools they dislike. "Modern tools" hegemonism is
little more than pure intolerance.

Or at least setting up an auto-responder
> suggesting people post on discuss.python.org 
> instead.

Just put a line in the list signature stating that discussions requiring
core-dev attention should happen on discourse, and be done.

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

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

[Terry Reedy]

On 11/30/2022 8:48 PM, Rob Cliffe via Python-Dev wrote:

Thank you for this very clear analysis, Oscar.
It seems to me that this strengthens the OP's case.  I am curious as to 
whether others agree.


I do.


On 30/11/2022 13:35, Oscar Benjamin wrote:
On Tue, 29 Nov 2022 at 23:46, Steven D'Aprano  
wrote:

On Tue, Nov 29, 2022 at 08:51:09PM -, Yoni Lavi wrote:


It does make your argument invalid though, since it's based on this
assumption that I was asking for a requirement on iteration order
(e.g. like dict's iteration order = insertion order guarantee), which
is not the case.

Yoni, I think this answer is disingenious.

I don't think it is disingenuous. There are just a lot of people
talking past each other and not quite understanding what each person
means because there is confusion about even the intended meaning of
terms like "deterministic". I will expand here with enough detail that
we should hopefully be able to avoid misunderstanding each other.

There are probably other places where you could find mentions of this
in the docs but I just took a quick look in the Python 3.5 docs
(before hash randomisation) to find this mention of dictionary
iteration order:
https://docs.python.org/3.5/library/stdtypes.html#dictionary-view-objects

What it says is
"""
Keys and values are iterated over in an arbitrary order which is
non-random, varies across Python implementations, and depends on the
dictionary’s history of insertions and deletions.
"""
The key point is the use of the term "non-random" which here is
intended to mean that although no particular ordering is guaranteed
you can expect to rerun the same program and get the same result
deterministically. A different version or implementation of Python
might give a different order but rerunning the same program twice
without changing anything should give the same result even if that
result depends in some way on the iteration order of some
dictionaries. I can't immediately find a similar statement about sets
but in practice the same behaviour applied to sets as well. Note
carefully that it is this *narrow* form of determinism that Yoni is
interested in.

Of course there are some caveats to this and the obvious one is that
this statement does not apply if there are some objects that use
identity based hashing so this is not deterministic:

class A:
 def __init__(self, data):
 self.data = data
 def __repr__(self):
 return 'A(%s)' % self.data

a1 = A(1)
a2 = A(2)

for a in {a1, a2}:
 print(a)

Running this gives:

$ python3.5 t.py
A(2)
A(1)
$ python3.5 t.py
A(1)
A(2)

On the other hand if all of the hashes themselves are deterministic
then the program as a whole will be as well so this is deterministic:

class A:
 def __init__(self, data):
 self.data = data
 def __repr__(self):
 return 'A(%s)' % self.data
 def __hash__(self):
 return hash(self.data)
 def __eq__(self):
 return self.data == other.data

a1 = A(1)
a2 = A(2)

for a in {a1, a2}:
 print(a)

$ python3.5 t.py
A(1)
A(2)
$ python3.5 t.py
A(1)
A(2)

So we have two classes of hashable objects:

1. Those with deterministic hash
2. Those with non-deterministic hash

A program that avoids depending on the iteration order of sets or
dicts containing objects with non-deterministic hash could be
deterministic. It is not the case that the program would depend on the
iteration order for its *correctness* but just that the behaviour of
the program is *reproducible* which is useful in various ways e.g.:

- You could say to someone else "run this code with CPython 3.5 and
you should be able to reproduce exactly what I see when I run the
program". It is common practice e.g. in scientific programming to
record things like random seeds so that someone else can precisely
reproduce the results shown in a paper or some other work and this in
general requires that it is at least possible to make everything
deterministic.

- When debugging it is useful to be able to reproduce an error
condition precisely. Debugging non-deterministic failures can be
extremely difficult. In the same way that you might want to reproduce
correctly functioning code it is also very useful to be able to
reproduce bugs.

I can list more examples but really it shouldn't be necessary to
justify from first principles why determinism in programming is
usually a good thing. There can be reasons sometimes why determinism
is undesired or cannot or should not be guaranteed. It should not be
controversial though to say that all things being equal determinism is
usually a desirable feature and should be preferred by default. I
don't think that the 3.5 docs I quoted above used the words
"non-random" casually: it was an intended feature and people were
aware that breaking that behaviour would be problematic in many
situations.

Of course in Python 3.6 this determinism was broken with the
introduction of hash randomisation for strings. It was considered that
for security 

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

[Rob Cliffe via Python-Dev]

Thank you for this very clear analysis, Oscar.
It seems to me that this strengthens the OP's case.  I am curious as to 
whether others agree.

Best wishes
Rob Cliffe

On 30/11/2022 13:35, Oscar Benjamin wrote:

On Tue, 29 Nov 2022 at 23:46, Steven D'Aprano  wrote:

On Tue, Nov 29, 2022 at 08:51:09PM -, Yoni Lavi wrote:


It does make your argument invalid though, since it's based on this
assumption that I was asking for a requirement on iteration order
(e.g. like dict's iteration order = insertion order guarantee), which
is not the case.

Yoni, I think this answer is disingenious.

I don't think it is disingenuous. There are just a lot of people
talking past each other and not quite understanding what each person
means because there is confusion about even the intended meaning of
terms like "deterministic". I will expand here with enough detail that
we should hopefully be able to avoid misunderstanding each other.

There are probably other places where you could find mentions of this
in the docs but I just took a quick look in the Python 3.5 docs
(before hash randomisation) to find this mention of dictionary
iteration order:
https://docs.python.org/3.5/library/stdtypes.html#dictionary-view-objects

What it says is
"""
Keys and values are iterated over in an arbitrary order which is
non-random, varies across Python implementations, and depends on the
dictionary’s history of insertions and deletions.
"""
The key point is the use of the term "non-random" which here is
intended to mean that although no particular ordering is guaranteed
you can expect to rerun the same program and get the same result
deterministically. A different version or implementation of Python
might give a different order but rerunning the same program twice
without changing anything should give the same result even if that
result depends in some way on the iteration order of some
dictionaries. I can't immediately find a similar statement about sets
but in practice the same behaviour applied to sets as well. Note
carefully that it is this *narrow* form of determinism that Yoni is
interested in.

Of course there are some caveats to this and the obvious one is that
this statement does not apply if there are some objects that use
identity based hashing so this is not deterministic:

class A:
 def __init__(self, data):
 self.data = data
 def __repr__(self):
 return 'A(%s)' % self.data

a1 = A(1)
a2 = A(2)

for a in {a1, a2}:
 print(a)

Running this gives:

$ python3.5 t.py
A(2)
A(1)
$ python3.5 t.py
A(1)
A(2)

On the other hand if all of the hashes themselves are deterministic
then the program as a whole will be as well so this is deterministic:

class A:
 def __init__(self, data):
 self.data = data
 def __repr__(self):
 return 'A(%s)' % self.data
 def __hash__(self):
 return hash(self.data)
 def __eq__(self):
 return self.data == other.data

a1 = A(1)
a2 = A(2)

for a in {a1, a2}:
 print(a)

$ python3.5 t.py
A(1)
A(2)
$ python3.5 t.py
A(1)
A(2)

So we have two classes of hashable objects:

1. Those with deterministic hash
2. Those with non-deterministic hash

A program that avoids depending on the iteration order of sets or
dicts containing objects with non-deterministic hash could be
deterministic. It is not the case that the program would depend on the
iteration order for its *correctness* but just that the behaviour of
the program is *reproducible* which is useful in various ways e.g.:

- You could say to someone else "run this code with CPython 3.5 and
you should be able to reproduce exactly what I see when I run the
program". It is common practice e.g. in scientific programming to
record things like random seeds so that someone else can precisely
reproduce the results shown in a paper or some other work and this in
general requires that it is at least possible to make everything
deterministic.

- When debugging it is useful to be able to reproduce an error
condition precisely. Debugging non-deterministic failures can be
extremely difficult. In the same way that you might want to reproduce
correctly functioning code it is also very useful to be able to
reproduce bugs.

I can list more examples but really it shouldn't be necessary to
justify from first principles why determinism in programming is
usually a good thing. There can be reasons sometimes why determinism
is undesired or cannot or should not be guaranteed. It should not be
controversial though to say that all things being equal determinism is
usually a desirable feature and should be preferred by default. I
don't think that the 3.5 docs I quoted above used the words
"non-random" casually: it was an intended feature and people were
aware that breaking that behaviour would be problematic in many
situations.

Of course in Python 3.6 this determinism was broken with the
introduction of hash randomisation for strings. It was considered that
for security purposes it would be better to have some 

[Python-Dev] Re: Switching to Discourse

[Gregory P. Smith]

On Thu, Dec 1, 2022 at 8:37 AM Victor Stinner  wrote:

>
> Should we *close* the python-dev mailing list?
>

I'd be in favor of this. Or at least setting up an auto-responder
suggesting people post on discuss.python.org instead.

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