Re: Proposal: Syntax for attribute initialisation in __init__ methods

[Sam Ezeh]

I'll see if I can find out how positional only and keyword only
arguments are used in __init__ methods in the wild and I'll see if
there have been any other discussions talking about what this approach
could offer.

On Sun, 17 Apr 2022 at 02:54, dn  wrote:
>
> On 17/04/2022 09.20, Sam Ezeh wrote:
> >> Perhaps I'm missing the point, but what functionality or advantage(s)
> >> does this give, over data-classes?
> >
> > One advantage is maintaining control over the __init__ function without
> > having to write extra code to do so. In the linked discussion from
> > python-ideas, it was mentioned that keyword-only and positional-only
> > arguments can't be used with dataclasses [1].
> >
> >> Maybe Dataclasses are not being used as much as one might hope, but they
> >> are relatively new, and many Python-Masters simply carry-on constructing
> >> classes the way they have for years...
> >
> > I think one concern I have is that even if this is useful, it might
> > still fall to the same fate.
>
>
> Don't be discouraged by that - and that thread was not the first of such
> discussions! The way Python is being applied is continually changing...
>
> I'm not sure about the criticism of dataclasses though. Starting with
> 'explicit over implicit', once a parameter-list is more than two or
> three long, shouldn't we be using 'labels' in order to avoid (potential)
> confusion, ie keyword-parameters?
>
> This removes the order/sequence of arguments from the list of potential
> problems/gotchas one can fall into!
>
> In which case, I'm wondering just how often the criticism applies 'in
> real life'?
>
> So, now the question becomes: what are the cases/examples which
> require/desire improvement over the 'traditional' __init__ of
> attributes, and facilities offered through dataclasses?
> --
> Regards,
> =dn
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Enums and nested classes

[Sam Ezeh]

Hello everyone,

Has anyone here used or attempted to use a nested class inside an enum?

If so, how did you find it? (what did you expect to happen and did
your expectations align with resulting behaviour etc.)

Here are two examples describing the situation I'm talking about

```
class Outer(Enum):
a = 1
b = 2
class Inner(Enum):
foo = 10
bar = 11
```

```
class Outer(Enum):
a = 1
b = 2
class Inner:
c = None
def __init__(self):

```

Kind Regards,
Sam Ezeh
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tuple unpacking inside lambda expressions

[Sam Ezeh]

This also works great!

Kind Regards,
Sam Ezeh

On Tue, 19 Apr 2022 at 12:03, Antoon Pardon  wrote:
>
> Op 16/04/2022 om 23:36 schreef Sam Ezeh:
> > Two questions here.
> >
> > Firstly, does anybody know of existing discussions (e.g. on here or on
> > python-ideas) relating to unpacking inside lambda expressions?
> >
> > I found myself wanting to write the following.
> >
> > ```
> > map(
> >  lambda (module, data): result.process(module, data),
> >   jobs
> > )
> > ```
> > However, it's of course not legal Python syntax.
>
> Why not write:
>
> itertools.starmap(result.process, jobs)
>
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tuple unpacking inside lambda expressions

[Sam Ezeh]

I went back to the code recently and I remembered what the problem was.

I was using multiprocessing.Pool.pmap which takes a callable (the
lambda here) so I wasn't able to use comprehensions or starmap

Is there anything for situations like these?

Kind Regards,
Sam Ezeh

On Sat, 16 Apr 2022 at 22:36, Sam Ezeh  wrote:
>
> Two questions here.
>
> Firstly, does anybody know of existing discussions (e.g. on here or on
> python-ideas) relating to unpacking inside lambda expressions?
>
> I found myself wanting to write the following.
>
> ```
> map(
> lambda (module, data): result.process(module, data),
>  jobs
> )
> ```
> However, it's of course not legal Python syntax.
>
> The following were potential options but I felt they removed some of
> the meaning from the code, making it less understandable for other
> people.
>
> ```
> map(
> lambda job: result.process(job[0], job[1]),
>  jobs
> )
> ```
>
> ```
> map(
> lambda job: result.process(*job),
> jobs
> )
> ```
>
> Secondly, for situations like these, do you have any go-to methods of
> rewriting these while maintaining clarity?
>
> Kind Regards,
> Sam Ezeh
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

[Loris Bennett]

Random832  writes:

> On Tue, Apr 19, 2022, at 07:11, Loris Bennett wrote:

>> I now realise that timedelta is not really what I need.  I am
>> interested solely in pure periods, i.e. numbers of seconds, that I
>> can convert back and forth from a format such as
>
> A timedelta *is* a pure period. A timedelta of one day is 86400
> seconds.
>
> The thing you *think* timedelta does [making a day act as 23 or 25
> hours across daylight saving boundaries etc], that you *don't* want it
> to do, is something it *does not actually do*. I don't know how this
> can be made more clear to you.

I have now understood this.

> timedelta is what you need. if you think it's not, it's because you're
> using datetime incorrectly.

It is what I need.  It just doesn't do the trivial format conversion I
(apparently incorrectly) expected.  However, I can implement the format
conversion myself.

[snip (35 lines)]
-- 
This signature is currently under construction.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

[Loris Bennett]

Dennis Lee Bieber  writes:

> On Tue, 19 Apr 2022 15:51:09 +0200, "Loris Bennett"
>  declaimed the following:
>
>>If I am merely trying to represent part a very large number of seconds
>>as a number of years, 365 days per year does not seem that controversial
>
>   The Explanatory Supplement to the Astronomical Almanac (table 15.3)
> defines the /day/ as 24hrs->1440mins->86400secs   BUT defines 
> the Julian
> /year/ as 365.25 days.

That is interesting.  However, I am not claiming that the definition of
a year as 365 24-hour days is in any way correct, merely that it is a
possible definition and one that is potentially handy if one wants to
represent large numbers of seconds in a more readable way.

>   It goes on to also give (for my copy -- length of year at 1990):
> Tropical (equinox to equinox) 365.2421897 days *
> Sidereal (fixed star to fixed star)   365.25636 days
> Anomalistic (perihelion to perihelion)365.25964 days
> Eclipse (moon's node to moon's node)  346.26005
> Gaussian (Kepler's law /a/=1) 365.25690
> Julian365.25
>
>   Length of the month (I interpret this as lunar month):
> Synodic (new moon to new moon)29.53059 days
> Tropical (as with year)   27.32158
> Sidereal (as with year)   27.32166
> Anomalistic (perigee to perigee)  27.55455
> Draconic (node to node)   27.21222
>
> * I /think/ this is the year used for leap-day calculations, and why some
> leap centuries are skipped as it is really less than a quarter day per
> year, so eventually one gets to over-correcting by a day.
>
>   Of course, this book also has a footnote giving the speed of light as
> 1.80261750E12 Furlongs/Fortnight 

And of course I should have been asking why timedelta doesn't provide an
easy way to format the period as a number of fortnights :-)

>   However, as soon you incorporate units that are not SI seconds you have
> to differentiate between pure duration (based on SI seconds) and civil time
> (which may jump when leap seconds are added/subtracted, time zones are
> crossed, or daylight savings time goes into [or out of] effect).
>
>   For the most part, Python's datetime module seems to account for civil
> time concepts, not monotonic durations. 

That indeed seems to be the case and the lack of trivial formatting
options for monotonic durations is what surprises me. 

>   The Ada standard separates "duration" (as a measure of elapsed time, in
> fixed point seconds) from "time" (a private type in Ada.Calendar -- which
> does NOT define hours/minutes... It has Year 1901..2399, Month 1..12, Day
> 1..31, Day_duration 0.0..86400.0). There are functions to create a Time
> from components, split a Time into components, compare two times, add a
> Duration to a Time, subtract a Duration from a Time, and subtract a Time
> from a Time (getting a Duration). Oh, and a function to get Time from
> system clock. Per the standard, the Time Zone used is implementation
> defined (so one needs to read the implementation manual to find out what a
> Time really notates). Of note:
> """
> 26.a/1
> To be honest: {8652/0106} {AI95-00160-01} By "proper date" above we mean
> that the given year has a month with the given day. For example, February
> 29th is a proper date only for a leap year. We do not mean to include the
> Seconds in this notion; in particular, we do not mean to require
> implementations to check for the “missing hour” that occurs when Daylight
> Savings Time starts in the spring. 
> """
> """
> 43
>type Duration is delta implementation-defined range
> implementation-defined;
> """
>
>   GNAT provides an extension package GNAT.Calendar that adds
> hour/minute/day-of-week and some other utilities... BUT
> """
>  procedure Split_At_Locale
>  (Date   : Ada.Calendar.Time;
>   Year   : out Ada.Calendar.Year_Number;
>   Month  : out Ada.Calendar.Month_Number;
>   Day: out Ada.Calendar.Day_Number;
>   Hour   : out Hour_Number;
>   Minute : out Minute_Number;
>   Second : out Second_Number;
>   Sub_Second : out Second_Duration);
>  --  Split a standard Ada.Calendar.Time value in date data (Year, Month,
> Day)
>--  and Time data (Hour, Minute, Second, Sub_Second). This version of
> Split
>--  utilizes the time zone and DST bias of the locale (equivalent to
> Clock).
>--  Due to this simplified behavior, the implementation does not require
>--  expensive system calls on targets such as Windows.
>--  WARNING: Split_At_Locale is no longer aware of historic events and
> may
>--  produce inaccurate results over DST changes which occurred in the
> past.
> """
-- 
This signature is currently under construction.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: lambda issues

[Schachner, Joseph]

Re:  "...which takes a callable (the lambda here)"

Python lamdas have some severe restrictions.  In any place that takes a 
callable, if a lambda can't serve, just use def to write a function and use the 
function name.

 Joseph S.


Teledyne Confidential; Commercially Sensitive Business Data

-Original Message-
From: Python-list 
 On Behalf Of 
python-list-requ...@python.org
Sent: Wednesday, April 20, 2022 12:00 PM
To: python-list@python.org
Subject: Python-list Digest, Vol 223, Issue 20

---External Email---

Send Python-list mailing list submissions to
python-list@python.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mail.python.org/mailman/listinfo/python-list
or, via email, send a message with subject or body 'help' to
python-list-requ...@python.org

You can reach the person managing the list at
python-list-ow...@python.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Python-list digest..."
-- 
https://mail.python.org/mailman/listinfo/python-list

Why no list as dict key?

[Abdur-Rahmaan Janhangeer]

Greetings list,

Using Python3.9, i cannot assign a list [1, 2] as key
to a dictionary. Why is that so? Thanks in advanced!

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tuple unpacking inside lambda expressions

[Albert-Jan Roskam]

   On Apr 20, 2022 13:01, Sam Ezeh  wrote:

 I went back to the code recently and I remembered what the problem was.

 I was using multiprocessing.Pool.pmap which takes a callable (the
 lambda here) so I wasn't able to use comprehensions or starmap

 Is there anything for situations like these?

   =
   Could it simply be:
   multiprocessing.Pool.pmap(lambda job: result.process(*job), jobs)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why no list as dict key?

[Larry Martell]

On Wed, Apr 20, 2022 at 2:23 PM Abdur-Rahmaan Janhangeer
 wrote:
>
> Greetings list,
>
> Using Python3.9, i cannot assign a list [1, 2] as key
> to a dictionary. Why is that so? Thanks in advanced!

Dict keys cannot be mutable. Use a tuple instead.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why no list as dict key?

[Chris Angelico]

On Thu, 21 Apr 2022 at 04:23, Abdur-Rahmaan Janhangeer
 wrote:
>
> Greetings list,

Greetings tuple,

> Using Python3.9, i cannot assign a list [1, 2] as key
> to a dictionary. Why is that so? Thanks in advanced!
>

Because a list can be changed, which would change what it's equal to:

>>> spam = [1, 2]
>>> ham = [1, 2, 3]
>>> spam == ham
False
>>> spam.append(3)
>>> spam == ham
True

If you use spam as a dict key, then mutate it in any way, it would
break dict invariants of all kinds (eg you could also have used ham as
a key, and then you'd have duplicate keys).

Instead, use a tuple, which can't be mutated, is always equal to the
same things, and is hashable, which means it can be used as a key:

>>> spam = (1, 2)
>>> ham = (1, 2, 3)
>>> {spam: "spam", ham: "ham"}
{(1, 2): 'spam', (1, 2, 3): 'ham'}

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why no list as dict key?

[Sam Ezeh]

Repeating the above points, here is an example of what would happen if
you tried. Dictionaries require their keys to be immutable as
under-the-hood they use hash tables and they'd fail when the
underlying values are allowed to change.

```
[sam@samtop]: ~>$ python
Python 3.10.2 (main, Jan 15 2022, 19:56:27) [GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import functools
>>> import operator
>>> class HashableList(list):
... def __hash__(self):
... return functools.reduce(operator.xor, [key * value for
key, value in enumerate(self)], 5)
...
>>> x = HashableList([1,2,3])
>>> y = HashableList([1,2,3])
>>> dictionary = {x: 5}
>>> dictionary
{[1, 2, 3]: 5}
>>> dictionary[x]
5
>>> dictionary[y]
5
>>> x.append(4)
>>> dictionary
{[1, 2, 3, 4]: 5}
>>> dictionary[x]
Traceback (most recent call last):
  File "", line 1, in 
KeyError: [1, 2, 3, 4]
>>> dictionary[y]
Traceback (most recent call last):
  File "", line 1, in 
KeyError: [1, 2, 3]
>>>
```

On Wed, 20 Apr 2022 at 19:23, Abdur-Rahmaan Janhangeer
 wrote:
>
> Greetings list,
>
> Using Python3.9, i cannot assign a list [1, 2] as key
> to a dictionary. Why is that so? Thanks in advanced!
>
> Kind Regards,
>
> Abdur-Rahmaan Janhangeer
> about  | blog
> 
> github 
> Mauritius
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why no list as dict key?

[Chris Angelico]

On Thu, 21 Apr 2022 at 05:30, Sam Ezeh  wrote:
>
> Repeating the above points, here is an example of what would happen if
> you tried. Dictionaries require their keys to be immutable as
> under-the-hood they use hash tables and they'd fail when the
> underlying values are allowed to change.
>
> ```
> >>> class HashableList(list):
> ... def __hash__(self):
> ... return functools.reduce(operator.xor, [key * value for
> key, value in enumerate(self)], 5)

Quickie: I'd be inclined to define hash on top of a tuple's hash,
rather than try to design my own and hope that it's suitable. "return
hash(tuple(self))" is a good demonstration of the parallel.

Otherwise, good demonstration of the problem.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why no list as dict key?

[Avi Gross via Python-list]

This does raise an issue, Chris, if you use the method of making a tuple 
companion for a list at a specific time just for use as a dictionary key, then 
later change the list, you can end up with various situations.
Obviously the changed list can not only not access the stored item, but if 
converted again to a tuple, may address a different item. I can see many 
scenarios with abandoned dictionary items that are never deleted and can only 
be reached by examining all items in the dictionary.
So mutability is only one concern. If you actually mutate your data, ...
I am thinking as an example about a program I wrote ages ago that deals with 
equations in symbolic form and maintains a collection of forms of the equation 
it is trying to take a derivative or integral of by applying an assortment of 
typographic rules. I mean commutative lawand others. You do not want to  keep 
adding the same item into the data structure (such as a queue) repeatedly. So 
something like a dictionary (or set) can be a good way to store unique items. 
But the items are some complex lists so the above discussion qualifies. Of 
course the tuple conversion for a nested structure would need to have made a 
deep copy. 
The question in the above is how to make sure that taking a next attempt off 
the queue deals with the dictionary of tried items. In this case, unless you 
use it to find a solution, keeping it in the dictionary to avoid repeating, 
makes sense. 
And another thought is that mapping a list to a tuple has another possible 
drawback.
What if I have both a list and tuple with the same structure which I want as 
keys?
I can imagine then converting the list in some imaginative ways. For example, 
embed the list in another list whose first item is "from-tuple" or something. 
Life is complicated. Then you die.


-Original Message-
From: Chris Angelico 
To: python-list@python.org
Sent: Wed, Apr 20, 2022 3:49 pm
Subject: Re: Why no list as dict key?

On Thu, 21 Apr 2022 at 05:30, Sam Ezeh  wrote:
>
> Repeating the above points, here is an example of what would happen if
> you tried. Dictionaries require their keys to be immutable as
> under-the-hood they use hash tables and they'd fail when the
> underlying values are allowed to change.
>
> ```
> >>> class HashableList(list):
> ...    def __hash__(self):
> ...            return functools.reduce(operator.xor, [key * value for
> key, value in enumerate(self)], 5)

Quickie: I'd be inclined to define hash on top of a tuple's hash,
rather than try to design my own and hope that it's suitable. "return
hash(tuple(self))" is a good demonstration of the parallel.

Otherwise, good demonstration of the problem.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why no list as dict key?

[Chris Angelico]

On Thu, 21 Apr 2022 at 06:20, Avi Gross via Python-list
 wrote:
>
> This does raise an issue, Chris, if you use the method of making a tuple 
> companion for a list at a specific time just for use as a dictionary key, 
> then later change the list, you can end up with various situations.
>

Yes. And those situations are *exactly* why you can't use a list as a key.

> Obviously the changed list can not only not access the stored item, but if 
> converted again to a tuple, may address a different item. I can see many 
> scenarios with abandoned dictionary items that are never deleted and can only 
> be reached by examining all items in the dictionary.
> So mutability is only one concern. If you actually mutate your data, ...

And if you don't mutate your data, use a tuple.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why no list as dict key?

[Greg Ewing]

On 21/04/22 6:22 am, Abdur-Rahmaan Janhangeer wrote:

Using Python3.9, i cannot assign a list [1, 2] as key
to a dictionary. Why is that so?


If the contents of the list were to change after using it as
a key, its hash value would no longer match its position in
the dict, so subsequent lookups could fail to find it.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Why no list as dict key?

[Greg Ewing]

On 21/04/22 8:18 am, Avi Gross wrote:

I am thinking as an example about a program I wrote ages ago that deals with 
equations in symbolic form and maintains a collection of forms of the equation 
it is trying to take a derivative or integral of by applying an assortment of 
typographic rules.


It sounds like you would be better off making all your equation data
structures immutable. Instead of mutating the equation when making
a transformation, return a new equation. Then you can use sets and
dicts to cache them etc. without any problems.

--
Greg

--
https://mail.python.org/mailman/listinfo/python-list

Re: Why no list as dict key?

[Abdur-Rahmaan Janhangeer]

Thanks everybody,

In the the event spam is appended a value, then looking for [1,2] does not
return
anything but looking for [1,2,3] yes. But i gather the way dictionaries are
implemented
makes it difficult to do so ...

Maybe hashes should point to an object rather than being the hash of an
object themselves.
Maybe the speed drop is not worth it.

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius


On Wed, Apr 20, 2022 at 10:35 PM Chris Angelico  wrote:

> On Thu, 21 Apr 2022 at 04:23, Abdur-Rahmaan Janhangeer
>  wrote:
> >
> > Greetings list,
>
> Greetings tuple,
>
> > Using Python3.9, i cannot assign a list [1, 2] as key
> > to a dictionary. Why is that so? Thanks in advanced!
> >
>
> Because a list can be changed, which would change what it's equal to:
>
> >>> spam = [1, 2]
> >>> ham = [1, 2, 3]
> >>> spam == ham
> False
> >>> spam.append(3)
> >>> spam == ham
> True
>
> If you use spam as a dict key, then mutate it in any way, it would
> break dict invariants of all kinds (eg you could also have used ham as
> a key, and then you'd have duplicate keys).
>
> Instead, use a tuple, which can't be mutated, is always equal to the
> same things, and is hashable, which means it can be used as a key:
>
> >>> spam = (1, 2)
> >>> ham = (1, 2, 3)
> >>> {spam: "spam", ham: "ham"}
> {(1, 2): 'spam', (1, 2, 3): 'ham'}
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why no list as dict key?

[2QdxY4RzWzUUiLuE]

On 2022-04-21 at 06:22:53 +0400,
Abdur-Rahmaan Janhangeer  wrote:

> Maybe hashes should point to an object rather than being the hash of an
> object themselves.
> Maybe the speed drop is not worth it.

Then you have a different problem.

x = [1, 2, 3]
y = [n for n in 1, 2, 3]

Those two lists (x and y) are separate but equal objects.  Being
separate, pointers to them would not be equal.  Being equal, they have
to have the same hash.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why no list as dict key?

[Abdur-Rahmaan Janhangeer]

Assumes checking for object equality before inserting.
If they are they same, do we need different hashes?

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius


On Thu, Apr 21, 2022 at 7:15 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:

> On 2022-04-21 at 06:22:53 +0400,
> Abdur-Rahmaan Janhangeer  wrote:
>
> > Maybe hashes should point to an object rather than being the hash of an
> > object themselves.
> > Maybe the speed drop is not worth it.
>
> Then you have a different problem.
>
> x = [1, 2, 3]
> y = [n for n in 1, 2, 3]
>
> Those two lists (x and y) are separate but equal objects.  Being
> separate, pointers to them would not be equal.  Being equal, they have
> to have the same hash.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why no list as dict key?

[Dan Stromberg]

On Wed, Apr 20, 2022 at 7:23 PM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:

> Maybe hashes should point to an object rather than being the hash of an
> object themselves.
> Maybe the speed drop is not worth it.
>

If you need mutable keys, you /might/ create a dict-like-object using what
functional languages call an association list.  But these have O(n)
lookups, not O(1) like a dict (AKA hash table).  And even then, if you have
keys a and b, a != b, and you modify b to look just like a, you could get a
bit of a mess from the two equal keys mapping to two different values.

It is possible to have a dict that allows duplicates though.  Usually
that's not what you want, but sometimes it is, EG:
https://stromberg.dnsalias.org/~strombrg/dupdict_mod/

Trees have much the same issue as a dict (hash table) in this case.  These
are O(logn) or so.

The problem is hash tables and trees don't want keys changing "out from
under them".  It causes things they're assuming are invariant, to vary.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why no list as dict key?

[Chris Angelico]

On Thu, 21 Apr 2022 at 13:23, Abdur-Rahmaan Janhangeer
 wrote:
>
> Assumes checking for object equality before inserting.
> If they are they same, do we need different hashes?
>

The point of the hash is to find things that are equal. That's why
1234, 1234.0, and 0j+1234.0 all have the same hash.

If equality changes, the hash does too. It's certainly possible to
have the hash come from object identity, but then so must equality. If
you want that, it's easy to do - just create your own object for the
state, rather than using a list. But then you have to use the original
object to look things up, instead of matching by the data.

Hashes are simply a short-hand for equality. That's all.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why no list as dict key?

[Abdur-Rahmaan Janhangeer]

As clear as daylight, thanks!

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list