[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

On Sun, Jul 26, 2020 at 08:22:47PM -0700, Guido van Rossum wrote: > Regarding `__hash__`, it is a very bad idea to call `super().__hash__()`! Today I learned. Thank you. -- Steven ___ Python-ideas mailing list -- python-ideas@python.org To

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

I am really surprised at the resistance against defining `__eq__` on the target objects. Every time this problem has cropped up in code I was working on (including code part of very large corporate code bases) the obvious solution was to define `__eq__`. The only reason I can think of why you are

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

@Steven D'Aprano All good ideas ☺ I'm in agreement that we should be building solutions which are generalizable. Are there more concerns people would like to bring up when considering the problem of object equality? On Sun, Jul 26, 2020 at 9:25 PM Steven D'Aprano wrote: > On Sun, Jul 26, 2020

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

On Sun, Jul 26, 2020 at 11:12:39PM +0200, Alex Hall wrote: > There's another reason people might find this useful - if the objects have > differing attributes, the assertion can show exactly which ones, instead of > just saying that the objects are not equal. That's a good point. I sat down to

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

@Steven D'Aprano >- Developers might not want to leak the `__eq__` function to other > >developers; I wouldn't want to invade the implementation of my class > just > >for testing. > That seems odd to me. You are *literally* comparing two instances for > equality, just calling it

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

On Sun, Jul 26, 2020 at 07:47:39PM +0200, Marco Sulla wrote: > On Sun, 26 Jul 2020 at 19:33, Henry Lin wrote: > > > > >- Any class implementing the `__eq__` operator is no longer hashable > > > > > You can use: > > def __hash__(self): > return id(self) Don't do that. It's a horrible

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

On Sun, Jul 26, 2020 at 12:31:17PM -0500, Henry Lin wrote: > Hi Steven, > > You're right, declaring `__eq__` for the class we want to compare would > solve this issue. However, we have the tradeoff that > >- All classes need to implement the `__eq__` method to compare two >instances;

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

+1 to Alex Hall. In general I think there are a lot of questions regarding whether using the __eq__ operator is sufficient. It seems from people's feedback that it will essentially get the job done, but like Alex says, if we want to understand which field is leading to a test breaking, we

[Python-ideas] PEP8 update: using typing.TypeVar before function defenition

Hello! According to PEP8, there should be 2 blank lines before the function definition. But, I think in case of defining new typing.TypeVar, that will be used only in one function definition, it would be better to put it right before the function definition, i.e. with no blank lines. So I

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

On Sun, Jul 26, 2020 at 11:01 PM Ethan Furman wrote: > On 7/26/20 10:31 AM, Henry Lin wrote: > > > You're right, declaring `__eq__` for the class we want to compare would > > solve this issue. However, we have the tradeoff that > > > > * All classes need to implement the `__eq__` method to

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

On 7/26/20 10:31 AM, Henry Lin wrote: You're right, declaring `__eq__` for the class we want to compare would solve this issue. However, we have the tradeoff that * All classes need to implement the `__eq__` method to compare two instances; I usually implement __eq__ sooner or later

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

On 7/26/20 4:09 PM, Marco Sulla wrote: > You're quite right, but if you don't implement __eq__, the hash of an > object is simply a random integer (I suppose generated from the > address of the object). > > Alternatively, if you want a quick hash, you can use hash(str(obj)) > (if you implemented

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

You're quite right, but if you don't implement __eq__, the hash of an object is simply a random integer (I suppose generated from the address of the object). Alternatively, if you want a quick hash, you can use hash(str(obj)) (if you implemented __str__ or __repr__).

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

On 7/26/20 1:47 PM, Marco Sulla wrote: > On Sun, 26 Jul 2020 at 19:33, Henry Lin > wrote: > > * Any class implementing the `__eq__` operator is no longer hashable > > > You can use: > > def __hash__(self): >     return id(self) I thought that there was an

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

On Sun, 26 Jul 2020 at 19:33, Henry Lin wrote: > >- Any class implementing the `__eq__` operator is no longer hashable > > You can use: def __hash__(self): return id(self) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

Hi Steven, You're right, declaring `__eq__` for the class we want to compare would solve this issue. However, we have the tradeoff that - All classes need to implement the `__eq__` method to compare two instances; - Any class implementing the `__eq__` operator is no longer hashable -

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

On 25/07/2020 20:11, Christopher Barker wrote: On Sat, Jul 25, 2020 at 4:39 AM Eric V. Smith > wrote: On 7/25/2020 7:28 AM, Chris Angelico wrote: > Do you REALLY think that everyone will automatically understand it > just because it's spelled "for...

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

On Sat, Jul 25, 2020 at 10:15:16PM -0500, Henry Lin wrote: > Hey all, > > What are thoughts about implementing an object-compare function in the > unittest package? (Compare two objects recursively, attribute by > attribute.) Why not just ask the objects to compare themselves?

[Python-ideas] How to prevent shared memory from being corrupted ?

Problem: Currently, let’s say I create a shared_memory segment using mulitprocessing.shared_memory.SharedMemory in Process 1 and open the same in Process 2. Then, I try to write some data to the shared memory segment

[Python-ideas] Re: Faster object representation for UIs

26.07.20 01:41, Greg Ewing пише: On 26/07/20 1:34 am, Elizabeth Shashkova wrote: 1. We need this lazy `__repr__` calculation inside our debugger, where we work with different user's objects. Usually it isn't some specific type, for which you know that it'll be big and its `__repr__`

[Python-ideas] Re: Faster object representation for UIs

Well, about pprint, the solution is not easy... but about debugging, pytest for example does not show the full repr of an object, if the object is too large. You have to run pytest with the flag -v or -vv. Maybe that code could be moved in a separate little library. Another simple solution could