[issue42348] Language Reference: Set items

2020-11-13 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

Raymond's last point is that set objects should be immutably hashable.  I would 
say 'must be' in the sense that mutably hashable objects break sets in various 
ways, starting with uniqueness.  If we were to make a change, I think the 
replacement should be 'immutably hashable'

'unique objects' would also need qualification.  As is, one might reasonably 
expect. for instance, {1+0j, 1.0, 1} to have 3 elements rather than 1.  It is 
really 'objects unique up to equality', where equality may or may not be by 
identity.

However, I am inclined to agree with Raymond that we should stick to the 
current easily read sentence.

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42348] Language Reference: Set items

2020-11-13 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

I recommend leaving the text as is, and possibly creating a new FAQ entry 
discussing the relationship between immutability and hashability (something 
that I consider to be an intermediate or advanced topic).

Other thought:

* The set discussion should remain parallel that for mappings (a few 
paragraphs) after.  That text also discusses immutability

* We've never had a user incident regarding this text, so there is no actual 
evidence that this current wording is confusing anyone.

* It is common for users to equate hashability with immutability, so I think 
the current wording is reasonable.  My experience with users indicate that 
"hashable" is more cryptic than "immutable" because the former implies a 
knowledge of how hash tables work.

* It's easy for us thinking we're helping by making precise distinctions but 
have the actual effect of making the docs more opaque.  That is why first-aid 
books say "bruise" instead of "subdermal hematoma" :-)

* The word "immutable" is a reasonable first approximation that doesn't require 
knowledge of hash table mechanics.  For the most part, it is how everyday users 
think about dict keys and set elements. 

* That approximation is useful because a fuller discussion would say that if 
__hash__ is defined, it should do so on fields that don't mutate.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42348] Language Reference: Set items

2020-11-13 Thread Yash Shete


Yash Shete  added the comment:

Should it be "These represents hashable objects"

--
nosy: +Pixmew

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42348] Language Reference: Set items

2020-11-13 Thread Batuhan Taskaya


New submission from Batuhan Taskaya :

The data types section of the language reference 
(https://docs.python.org/3.10/reference/datamodel.html#the-standard-type-hierarchy)
 has this description directly under the Set type (which has 2 childs, set and 
frozenset). 

> These represent unordered, finite sets of unique, immutable objects.

I feel like this wording is a bit confusing, considering the items doesn't have 
to be immutable at all. Can we replace this with hashable?

--
messages: 380901
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Language Reference: Set items

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42348] Language Reference: Set items

2020-11-13 Thread Batuhan Taskaya


Change by Batuhan Taskaya :


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python, rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com