[issue13479] pickle too picky on re-defined classes

2011-12-11 Thread kxroberto

kxroberto kxrobe...@users.sourceforge.net added the comment:

Well, == whould allow the wanted feature by exception through meta classes 
for concerned classes:

 class X:
... a=1
... 
 Y=X
 class X:
... a=1
... 
 Y==X
False
 class XCompare(type):
... def __eq__(self, other):
... print tolerant class __eq__
... return self.__name__ == other.__name__
... 
 class X:
... __metaclass__ = XCompare
... a=1
... 
 Y=X
 class X:
... a=1
... 
 Y==X
tolerant class __eq__
True
 


Better than nothing. Its a improvement generally, independently.
But thinking about my acutal use cases and all: It still doesn't satisfy. I 
don't want to introduce this extra magic on all those classes just for that 
feature - because when needed, the majority of classes are concerned (see 
below). One can have only one meta class ... its too tricky and off-road to 
guess for most programmers ... 

when in doubt, raise an error: That is IMHO too rigid here, and generally 
when a feature is then hindered too much. Aren't warnings the right tool for 
such case? If really rarely there is problem, should it surface easily already 
during dev  test time?
Compared to the everday life danger of Pythons dynamic attribute access, 
version incompatibilities, etc. its about a rather harmless issue here.

Now I'd vote for a warnings.warn upon == (or old is) failing , and then an 
error only when the .__name__ is not matching too. A warning at dev  test time 
should be enough, when just == (or is) fails. 


I mainly like the tolerance during development: e.g. fast reload style edit-run 
cycles (reload sometimes improved with special reload fix code), because I 
noticed that 95% of code changes/bug fixes do not require a full expensive 
app-restart. This pays off particularly with bigger GUI app development/fixing 
and similar, where lot of status is accumulated expensively during run time.
But I wished that feature already for a deployed app too.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13479
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue13479] pickle too picky on re-defined classes

2011-12-11 Thread Guido van Rossum

Guido van Rossum gu...@python.org added the comment:

What you're seeing here is just one of may things that go subtly wrong when you 
reload a class.  I don't think we should fix this one aspect while leaving so 
many other bugs due to the same root cause.

It would be better to focus your energy on a way to improve reloading, e.g. 
make it so that the identity of global functions and classes doesn't change 
when their module is reloaded.  (You'll find it a tough problem, but note that 
it's been solved for at least one specific instance: modules *do* retain their 
identity, so maybe you can use that as a model.)

--
resolution:  - wont fix
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13479
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue13479] pickle too picky on re-defined classes

2011-11-25 Thread kxroberto

Changes by kxroberto kxrobe...@users.sourceforge.net:


--
title: pickle to picky on re-defined classes - pickle too picky on re-defined 
classes

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13479
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue13479] pickle too picky on re-defined classes

2011-11-25 Thread Guido van Rossum

Guido van Rossum gu...@python.org added the comment:

Hm, this change allows many other *undesirable* objects pass the test as well. 
I'd prefer to stick to the rule, when in doubt, raise an error.
Maybe using == instead of 'is' as the test would be acceptable?

--
nosy: +gvanrossum

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13479
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com