Comparisons and sorting of a numeric class....
Hi, I'm building a custom numeric class that works with values that have uncertainty and am wanting to make it as compatible with floating point objects as possible -- so as to be usable in legacy code with minimal rewites; but but I am having trouble understanding how to handle magnitude comparison return values for __lt__ __gt__ etc. The problem with magnitude comparisons in my class is that the comparison may fail to be True for various reasons, and in various ways, but it's important for programming to retain the general reason a comparison wasn't strictly 'True'. For example, to 1 significant figure, I can write two values a=mynum(0.1) and b=mynum(0.01) ; as written both of them have an uncertainty of 1 least significant figure, so it is possible both values are really a 0. But, there is a bias/mean/average which suggests that more often than not -- 0.1 will be bigger than 0.01. So, what is the proper response of a>b ?, the answer is that a>b depends on the context of how the values were obtained and what is being done with them, although strictly speaking 'a' is not greater than 'b' in this case, although 'a' has a much better chance of being greater than 'b' on average which may be important for the user to know. Where I'm getting stuck is how to encode the return values of the comparison operators to be compatible with python floating point object return values (and python's sort algorithms for lists of floats) but still give extra functionality that is needed for uncertainty ... and as I'm writing in python 2.xx but with an eye toward python 3 in the future, I've become concerned that __cmp__ has been discontinued so that I need to write this using only __gt__() and friends. I don't know how to do it. What I would like is for operators like '>' to return a boolean True or False equivalent, which also encodes the reason for failure in one of five ways: True: Sufficient information and confidence exists that the comparison is thoroughly True. PartTrue:The comparison is uncertain for any single sample, but True is at least minimally more probable. Unbiased: The comparison is uncertain for any single sample. PartFalse: The comparison is uncertain for any single sample, but False is at least minimally more probable. False: Sufficient information and confidence exists that the comparison is thoroughly False. By default, only True would evaluate in conditional statement as a logical True. All other values would be equivalent to False, but hopefully, a programmer could find out which 'False' was returned by some kind of object inspection or operator, like: if (a>b) is PartTrue: print "I don't really know if 'a' really is greater than 'b'. but it might be" if (a>b) > Unbiased: print "a sorts after b because it's at least more probable that a>b than not." if (a>b): print "this message will not print if the value 'b' might occasionally be less than or equal to 'a'." For sorting, it would be ideal if the sorting algorithms min(), max(), etc. could automatically recognize that: False < PartFalse < Unknown < PartTrue < True. But, even if that can't be done -- if there were a way, or method I could add to my classes, which would intercept sort functions and replace an absolute certain compare function with a merely Unbiased detecting one; sort functions would all operate properly. However, I'm not sure how to create these return values nor do I know how to get the sort() functions to use them. I've tried subclassing float() to see if I could actually make a subclass that inherited all that float has, and be able to add extra methods for my own use -- but Python doesn't seem to allow subclassing float. I either am not doing it right, or it can't be done. So, I'm not sure I can subclass boolean either because that too is a built in class ... but I'm not sure how else to make an object that acts as boolean False, but can be differentiated from false by the 'is' operator. It's frustrating -- what good is subclassing, if one cant subclass all the base classes the language has? What other approaches can I take? 'False' is a singleton, so I was pretty sure this wouldn't work -- but I tried it... PartTrue = False if (1>2) is PartTrue: print "This is an obvious failure... False is not the object PartTrue." And I am seriously stumped -- https://mail.python.org/mailman/listinfo/python-list
Re: Comparisons and sorting of a numeric class....
On 01/06/2015 05:27 AM, Andrew Robinson wrote: Hi, I'm building a custom numeric class that works with values that have uncertainty and am wanting to make it as compatible with floating point objects as possible -- so as to be usable in legacy code with minimal rewites; but but I am having trouble understanding how to handle magnitude comparison return values for __lt__ __gt__ etc. The problem with magnitude comparisons in my class is that the comparison may fail to be True for various reasons, and in various ways, but it's important for programming to retain the general reason a comparison wasn't strictly 'True'. For example, to 1 significant figure, I can write two values a=mynum(0.1) and b=mynum(0.01) ; as written both of them have an uncertainty of 1 least significant figure, so it is possible both values are really a 0. But, there is a bias/mean/average which suggests that more often than not -- 0.1 will be bigger than 0.01. So, what is the proper response of a>b ?, the answer is that a>b depends on the context of how the values were obtained and what is being done with them, although strictly speaking 'a' is not greater than 'b' in this case, although 'a' has a much better chance of being greater than 'b' on average which may be important for the user to know. Where I'm getting stuck is how to encode the return values of the comparison operators to be compatible with python floating point object return values (and python's sort algorithms for lists of floats) but still give extra functionality that is needed for uncertainty ... and as I'm writing in python 2.xx but with an eye toward python 3 in the future, I've become concerned that __cmp__ has been discontinued so that I need to write this using only __gt__() and friends. I don't know how to do it. What I would like is for operators like '>' to return a boolean True or False equivalent, which also encodes the reason for failure in one of five ways: True: Sufficient information and confidence exists that the comparison is thoroughly True. PartTrue:The comparison is uncertain for any single sample, but True is at least minimally more probable. Unbiased: The comparison is uncertain for any single sample. PartFalse: The comparison is uncertain for any single sample, but False is at least minimally more probable. False: Sufficient information and confidence exists that the comparison is thoroughly False. Just a few comments, not a thorough examination. And I don't have time to actually try it today. 1) to subclass built-in types, you frequently have to implement your own constructor. You probably tried it by only implementing the initializer. The constructor has the name __new__ and you probably should read: http://rhettinger.wordpress.com/2011/05/26/super-considered-super/ 2) to be sortable, your comparison mechanism needs to be stable. (I think that's the word). Anyway, if a < b and b < c, then a must be < c. It's not clear that you can accomplish that with the approach you're describing. But if you modify your definition for values near zero, it may be possible. 3) Your user will have to be aware that she's not using regular float values. Sooner or later some functions will have to be used differently. But you should still be able to mostly preserve the illusion. 4) When you convert to Python version 3.x, you'll have to re-study all these issues. It may be to your advantage to do both versions at once, or to just support version 3.x By default, only True would evaluate in conditional statement as a logical True. All other values would be equivalent to False, but hopefully, a programmer could find out which 'False' was returned by some kind of object inspection or operator, like: if (a>b) is PartTrue: print "I don't really know if 'a' really is greater than 'b'. but it might be" if (a>b) > Unbiased: print "a sorts after b because it's at least more probable that a>b than not." if (a>b): print "this message will not print if the value 'b' might occasionally be less than or equal to 'a'." Those should all be possible. For sorting, it would be ideal if the sorting algorithms min(), max(), etc. could automatically recognize that: False < PartFalse < Unknown < PartTrue < True. But, even if that can't be done -- if there were a way, or method I could add to my classes, which would intercept sort functions and replace an absolute certain compare function with a merely Unbiased detecting one; sort functions would all operate properly. However, I'm not sure how to create these return values nor do I know how to get the sort() functions to use them. I've tried subclassing float() to see if I could actually make a subclass that inherited all that float has, and be able to add extra methods for my own use -- but Python doesn't seem to allow subclassing float. I either am not doing it right, or it can't be done. So, I'm not sure I can subclass boolean either because th
Re: Comparisons and sorting of a numeric class....
So, I'm not sure I can subclass boolean either because that too is a built in class ... but I'm not sure how else to make an object that acts as boolean False, but can be differentiated from false by the 'is' operator. It's frustrating -- what good is subclassing, if one cant subclass all the base classes the language has? As I said above, make sure you have a constructor. If you still get an error, post a message that shows exactly what you did, and what exception you saw. OK. I tried to subclass bool, using __new__ just to see if it would even accept the definition... eg: python 2.7.5 >>> class UBool( bool ): ... def __new__( self, default ): return bool.__new__( self, default ) ... Traceback (most recent call last): File "", line 1, in TypeError: Error when calling the metaclass bases type 'bool' is not an acceptable base type I also tried using return int.__new__( self, bool(default) ) but that too failed the exact same way. I came across this in my searches, perhaps it has something to do with why I can't do this? https://mail.python.org/pipermail/python-dev/2002-March/020822.html I thought about this last night, and realized that you shouldn't be allowed to subclass bool at all! A subclass would only be useful when it has instances, but the mere existance of an instance of a subclass of bool would break the invariant that True and False are the only instances of bool! (An instance of a subclass of C is also an instance of C.) I think it's important not to provide a backdoor to create additional bool instances, so I think bool should not be subclassable. ... --Guido van Rossum So, I think Guido may have done something so that there are only two instances of bool, ever. eg: False and True, which aren't truly singletons -- but follow the singleton restrictive idea of making a single instance of an object do the work for everyone; eg: of False being the only instance of bool returning False, and True being the only instance of bool returning True. Why this is so important to Guido, I don't know ... but it's making it VERY difficult to add named aliases of False which will still be detected as False and type-checkable as a bool. If my objects don't type check right -- they will likely break some people's legacy code... and I really don't even care to create a new instance of the bool object in memory which is what Guido seems worried about, rather I'm really only after the ability to detect the subclass wrapper name as distinct from bool False or bool True with the 'is' operator. If there were a way to get the typecheck to match, I wouldn't mind making a totally separate class which returned the False instance; eg: something like an example I modified from searching on the web: class UBool(): def __nonzero__(self): return self.default def __init__( self, default=False ): self.default = bool(default) def default( self, default=False ): self.defualt = bool(default) but, saying: >>> error=UBool(False) >>> if error is False: print "type and value match" ... >>> Failed to have type and value match, and suggests that 'is' tests the type before expanding the value. It's rather non intuitive, and will break code -- for clearly error expands to 'False' when evaluated without comparison functions like ==. >>> if not error: print "yes it is false" ... yes it is false >>> print error.__nonzero__() False >>> if error==False: print "It compares to False properly" ... >>> So, both 'is' and == seems to compare the type before attempting to expand the value. As a simple cross check, I tried to make a one valued tuple. >>> a=(False,None) >>> print a (False, None) >>> a=(False,) >>> if a is False: print "yes!!!" ... >>> >>> if not a: print "a is False" ... >>> if a == False: print "a is False" but that obviously failed, too; and if == fails to say False==False ... well, it's just to sensitive for wrapper classes to be involved unless they are a subclass of bool... Any ideas ? -- https://mail.python.org/mailman/listinfo/python-list
Re: Comparisons and sorting of a numeric class....
On Wed, Jan 7, 2015 at 12:30 AM, Andrew Robinson wrote: > Why this is so important to Guido, I don't know ... but it's making it VERY > difficult to add named aliases of False which will still be detected as > False and type-checkable as a bool. If my objects don't type check right -- > they will likely break some people's legacy code... and I really don't even > care to create a new instance of the bool object in memory which is what > Guido seems worried about, rather I'm really only after the ability to > detect the subclass wrapper name as distinct from bool False or bool True > with the 'is' operator. If there were a way to get the typecheck to match, > I wouldn't mind making a totally separate class which returned the False > instance; eg: something like an example I modified from searching on the > web: Okay, so why not just go with your own class, and deal with the question of the type check? Simple solution: Instead of fiddling with __gt__/__lt__, create your own method, and use your own comparison function to sort these things. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Comparisons and sorting of a numeric class....
On 01/06/2015 08:30 AM, Andrew Robinson wrote: So, I'm not sure I can subclass boolean either because that too is a built in class ... but I'm not sure how else to make an object that acts as boolean False, but can be differentiated from false by the 'is' operator. It's frustrating -- what good is subclassing, if one cant subclass all the base classes the language has? I said earlier that I don't think it's possible to do what you're doing without your users code being somewhat aware of your changes. But as long as the user doesn't check for the subclass-ness of your bool-like function, you should manage. In Python, duck-typing is encouraged, unlike java or C++, where the only substitutable classes are subclasses. As I said above, make sure you have a constructor. If you still get an error, post a message that shows exactly what you did, and what exception you saw. OK. I tried to subclass bool, using __new__ just to see if it would even accept the definition... eg: python 2.7.5 >>> class UBool( bool ): ... def __new__( self, default ): return bool.__new__( self, default ) ... Traceback (most recent call last): File "", line 1, in TypeError: Error when calling the metaclass bases type 'bool' is not an acceptable base type I also tried using return int.__new__( self, bool(default) ) but that too failed the exact same way. I came across this in my searches, perhaps it has something to do with why I can't do this? https://mail.python.org/pipermail/python-dev/2002-March/020822.html I thought about this last night, and realized that you shouldn't be allowed to subclass bool at all! A subclass would only be useful when it has instances, but the mere existance of an instance of a subclass of bool would break the invariant that True and False are the only instances of bool! (An instance of a subclass of C is also an instance of C.) I think it's important not to provide a backdoor to create additional bool instances, so I think bool should not be subclassable. ... --Guido van Rossum So, I think Guido may have done something so that there are only two instances of bool, ever. eg: False and True, which aren't truly singletons -- but follow the singleton restrictive idea of making a single instance of an object do the work for everyone; eg: of False being the only instance of bool returning False, and True being the only instance of bool returning True. Why this is so important to Guido, I don't know ... but it's making it VERY difficult to add named aliases of False which will still be detected as False and type-checkable as a bool. If my objects don't type check right -- they will likely break some people's legacy code... and I really don't even care to create a new instance of the bool object in memory which is what Guido seems worried about, rather I'm really only after the ability to detect the subclass wrapper name as distinct from bool False or bool True with the 'is' operator. If there were a There's already a contradiction in what you want. You say you don't want to create a new bool object (distinct from True and False), but you have to create an instance of your class. If it WERE a subclass of bool, it'd be a bool, and break singleton. If you ignore your subclass "requirement," 'is' should do the right thing. Whatever your class instance is, it won't be the same object as True or as False. way to get the typecheck to match, That's a piece of legacy code which you won't be able to support, as far as I can see. I wouldn't mind making a totally separate class which returned the False instance; eg: something like an example I modified from searching on the web: class UBool(): def __nonzero__(self): return self.default def __init__( self, default=False ): self.default = bool(default) def default( self, default=False ): self.defualt = bool(default) but, saying: >>> error=UBool(False) >>> if error is False: print "type and value match" ... >>> Failed to have type and value match, and suggests that 'is' tests the type before expanding the value. Not at all. It doesn't check the type or the value. It checks whether it's the SAME object. It's rather non intuitive, and will break code -- for clearly error expands to 'False' when evaluated without comparison functions like ==. >>> if not error: print "yes it is false" ... yes it is false No, the object False is not referenced in the above expression. You're checking the "falseness" of the expression. Same as if you say if not 0 if not mylist >>> print error.__nonzero__() False >>> if error==False: print "It compares to False properly" ... You control this one by your __eq__ method. >>> So, both 'is' and == seems to compare the type before attempting to expand the value. As a simple cross check, I tried to make a one valued tuple. >>> a=(False,None) >>> print a (False, None) >>> a=(False,) >>> if a is False: print "yes!!!" ... >>> >>>
SQLObject 2.1.0
Hello! I'm pleased to announce version 2.1.0, the first stable release of branch 2.1 of SQLObject. What's new in SQLObject === Minor features -- * In queries generated with SQLObject's tables columns are sorted in the order they are declared in the table. * In queries generated with sqlbuilder's Insert/Update, if values are passed using dictionaries, columns are sorted alphabetically. * Tables in SELECT...FROM clause are sorted alphabetically. * MySQLConnection, PostgresConnection and SQLiteConnection have got a new method listDatabases() that lists databases in the connection and returns a list of names. * MySQLConnection, PostgresConnection and SQLiteConnection have got a new method listTables() that returns a list of table names in the database. Contributor for this release is Ian Cordasco. For a more complete list, please see the news: http://sqlobject.org/News.html What is SQLObject = SQLObject is an object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with. SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB). Python 2.6 or 2.7 is required. Where is SQLObject == Site: http://sqlobject.org Development: http://sqlobject.org/devel/ Mailing list: https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss Archives: http://news.gmane.org/gmane.comp.python.sqlobject Download: https://pypi.python.org/pypi/SQLObject/2.1.0 News and changes: http://sqlobject.org/News.html Oleg. -- Oleg Broytmanhttp://phdru.name/[email protected] Programmers don't die, they just GOSUB without RETURN. -- https://mail.python.org/mailman/listinfo/python-list
ANN: psutil 2.2.0 released
Hello all, I'm glad to announce the release of psutil 2.2.0. In this new release I decided to drop support for Python 2.4 and 2.5 for good. Whoever is still on Python 2.4 and 2.5 can use old 2.1.3 version: https://pypi.python.org/pypi?name=psutil&version=2.1.3&:action=files Main features and bugfixes == - FreeBSD has now support for process CPU affinity - new pstree.py and pidof.py example scripts - C extension version mismatch in case the user messed up with psutil installation or with sys.path is now detected at import time - [Linux] a lot of file descriptors were left open - [Windows] use proper encoding for psutil.Process.username() and psutil.users(). - [Solaris] fixed a high-priority bug which crashed psutil on import. The list of all enhancements and bugfixes is here: https://github.com/giampaolo/psutil/blob/master/HISTORY.rst#220---2015-01-06 Links = * Home page: https://github.com/giampaolo/psutil * Downloads: https://pypi.python.org/pypi?:action=display&name=psutil#downloads * Documentation: http://pythonhosted.org/psutil/ Please try out this new release and let me know if you experience any problem by filing issues on the bug tracker. All the best, -- Giampaolo - http://grodola.blogspot.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Comparisons and sorting of a numeric class....
Andrew Robinson wrote:
> Hi,
> I'm building a custom numeric class that works with values that have
> uncertainty and am wanting to make it as compatible with floating point
> objects as possible -- so as to be usable in legacy code with minimal
> rewites; but but I am having trouble understanding how to handle
> magnitude comparison return values for __lt__ __gt__ etc.
>
> The problem with magnitude comparisons in my class is that the
> comparison may fail to be True for various reasons, and in various ways,
> but it's important for programming to retain the general reason a
> comparison wasn't strictly 'True'.
It sounds like you want some sort of multi-valued or fuzzy logic here.
Skipping ahead, you wrote:
> What I would like is for operators like '>' to return a boolean True or
> False equivalent, which also encodes the reason for failure in one of
> five ways:
>
> True: Sufficient information and confidence exists that the
> comparison is thoroughly True.
> PartTrue:The comparison is uncertain for any single sample, but True
> is at least minimally more probable.
> Unbiased: The comparison is uncertain for any single sample.
> PartFalse: The comparison is uncertain for any single sample, but
> False is at least minimally more probable.
> False: Sufficient information and confidence exists that the
> comparison is thoroughly False.
>
> By default, only True would evaluate in conditional statement as a
> logical True. All other values would be equivalent to False,
[...]
Before you spend too much time on this, I recommend that you research some
of the existing theory on multi-value logic. There are a number of standard
types that you may be able to use for your needs, or possibly even find an
existing library for. Or there is fuzzy logic, where truth values vary
continuously between 0.0 and 1.0, with 0.0 being "absolutely false" and 1.0
being "absolutely true".
Start here: http://en.wikipedia.org/wiki/Many-valued_logic
Assuming nothing standard suits, you can't actually subclass bool, as you
have discovered. But that doesn't mean that you can't still use bools! You
just need some other values to use as well.
For simplicity, let's just create three singleton values. We're going to
have to bootstrap the instances into existence, so this will be a bit
messy:
# untested
class MultiLogic(object):
PartTrue = Unbiased = PartFalse = None
def __new__(cls):
raise TypeError('cannot create more instances')
def __repr__(self):
if self is type(self).PartTrue:
return "PartTrue"
if self is type(self).PartFalse:
return "PartFalse"
if self is type(self).Unbiased:
return "Unbiased"
# Python 2
def __nonzero__(self):
return False
# Python 3
def __bool__(self):
return False
# Bootstrap the instances into existence.
PartTrue = MultiLogic.PartTrue = object.__new__(MultiLogic)
PartFalse = MultiLogic.PartFalse = object.__new__(MultiLogic)
Unbiased = MultiLogic.Unbiased = object.__new__(MultiLogic)
There's other ways to handle this, of course, but what we have now is
three "singleton" (tripleton?) values, PartTrue, PartFalse and Unbiased.
You can access them either by the global name, or via the MultiLogic.*
class attribute.
Now, let's use these in your numeric class:
# I don't think we should inherit from float.
class MyNumber(object):
# See the source code for decimal.Decimal or fractions.Fraction
# for ways to program a numeric type.
def __eq__(self, other):
if not isinstance(other, MyNumber):
# Signal that we don't know how to do this comparison.
return NotImplemented
if some_condition:
# Certainly equal.
return True
elif another_condition:
# Probably equal.
return PartTrue
elif a_third_condition:
# Probably not equal.
return PartFalse
elif yet_another_condition:
# Definitely not equal.
return False
else:
# Unknown.
return Unbiased
# Now do the same for __ne__ __lt__ __gt__ __le__ __ge__
# (not equal, less than, greater than, less than or equal,
# greater than or equal)
You probably will want a helper method to avoid too much duplicate code in
your comparison operators.
By the way, you seem to be working on a form of fuzzy number or interval
arithmetic:
http://en.wikipedia.org/wiki/Fuzzy_number
http://en.wikipedia.org/wiki/Interval_arithmetic
> For example, to 1 significant figure, I can write two values
> a=mynum(0.1) and b=mynum(0.01) ; as written both of them have an
> uncertainty of 1 least significant figure, so it is possible both values
> are really a 0. But, there is a bias/mean/average which suggests that
> more often than not -- 0.1 will be bigger than 0.01. So, what is the
> proper response of a>b ?, the answer is that a>b depends o
Re: Comparisons and sorting of a numeric class....
On 01/06/2015 06:02 AM, Dave Angel wrote: On 01/06/2015 08:30 AM, Andrew Robinson wrote: So, I'm not sure I can subclass boolean either because that too is a built in class ... but I'm not sure how else to make an object that acts as boolean False, but can be differentiated from false by the 'is' operator. It's frustrating -- what good is subclassing, if one cant subclass all the base classes the language has? I said earlier that I don't think it's possible to do what you're doing without your users code being somewhat aware of your changes. Aye. You did. And I didn't disagree. :) The goal is merely to trip up those who don't know what I'm doing as little as possible and only break their code where the very notion of uncertainty is incompatible with what they are doing, or where they did something very stupid anyway... eg: to break it where there is a good reason for it to be broken. I may not achieve my goal, but I at least hope to come close... But as long as the user doesn't check for the subclass-ness of your bool-like function, you should manage. In Python, duck-typing is encouraged, unlike java or C++, where the only substitutable classes are subclasses. but if you can't subclass a built in type -- you can't duck type it -- for I seem to recall that Python forbids duck typing any built in class nut not subclasses. So your two solutions are mutually damaged by Guido's decision; And there seem to be a lot of classes that python simply won't allow anyone to subclass. ( I still need to retry subclassing float, that might still be possible. ) Removing both options in one blow is like hamstringing the object oriented re-useability principle completely. You must always re-invent the wheel from near scratch in Python --Guido van Rossum So, I think Guido may have done something so that there are only two instances of bool, ever. eg: False and True, which aren't truly singletons -- but follow the singleton restrictive idea of making a single instance of an object do the work for everyone; eg: of False being the only instance of bool returning False, and True being the only instance of bool returning True. Why this is so important to Guido, I don't know ... but it's making it VERY difficult to add named aliases of False which will still be detected as False and type-checkable as a bool. If my objects don't type check right -- they will likely break some people's legacy code... and I really don't even care to create a new instance of the bool object in memory which is what Guido seems worried about, rather I'm really only after the ability to detect the subclass wrapper name as distinct from bool False or bool True with the 'is' operator. If there were a There's already a contradiction in what you want. You say you don't want to create a new bool object (distinct from True and False), but you have to create an instance of your class. If it WERE a subclass of bool, it'd be a bool, and break singleton. Yes there seems to be a contradiction but I'm not sure there is ... and it stems in part from too little sleep and familiarity with other languages... Guido mentioned subclassing in 'C' as part of his justification for not allowing subclassing bool in python. That's what caused me to digress a bit... consider: In 'C++' I can define a subclass without ever instantiating it; and I can define static member functions of the subclass that operate even when there exists not a single instance of the class; and I can typecast an instance of the base class as being an instance of the subclass. So -- (against what Guido seems to have considered) I can define a function anywhere which returns my new subclass object as it's return value without ever instantiating the subclass -- because my new function can simply return a typecasting of a base class instance; The user of my function would never need to know that the subclass itself was never instantiated... for they would only be allowed to call static member functions on the subclass anyway, but all the usual methods found in the superclass(es) would still be available to them. All the benefits of subclassing still exist, without ever needing to violate the singleton character of the base class instance. So part of Guido's apparent reason for enforcing singleton ( dual singleton / dualton? ) nature of 'False' and 'True' isn't really justified by what 'C++' would allow because C++ could still be made to enforce singleton instances while allowing subclassing *both* at the same time. There seems to be some philosophical reason for what Guido wants that he hasn't fully articulated...? If I understood him better-- I wouldn't be making wild ass guesses and testing everything I can think of to work around what he chose... If you ignore your subclass "requirement," 'is' should do the right thing. Whatever your class instance is, it won't be the same object as True or as False. It wa
Re: Comparisons and sorting of a numeric class....
On 01/06/2015 05:35 AM, Chris Angelico wrote: On Wed, Jan 7, 2015 at 12:30 AM, Andrew Robinson wrote: Why this is so important to Guido, I don't know ... but it's making it VERY difficult to add named aliases of False which will still be detected as False and type-checkable as a bool. If my objects don't type check right -- they will likely break some people's legacy code... and I really don't even care to create a new instance of the bool object in memory which is what Guido seems worried about, rather I'm really only after the ability to detect the subclass wrapper name as distinct from bool False or bool True with the 'is' operator. If there were a way to get the typecheck to match, I wouldn't mind making a totally separate class which returned the False instance; eg: something like an example I modified from searching on the web: Okay, so why not just go with your own class, and deal with the question of the type check? Simple solution: Instead of fiddling with __gt__/__lt__, create your own method, and use your own comparison function to sort these things. ChrisA Because defining a bunch of special methods defeats the very purpose of making my class compatible with float variables. eg: No legacy code would work... I know (belatedly) that am going to have to define my own class. That's pretty much a given, but I want to do it in a way which requires my users to make very few changes to their traditional floating point algorithms and code. The type check issue is mostly about compatability in the first place ; eg: users typecheck either unintentionally -- (novices syndrome) -- or because they need all the capabilities of a given type, and the only simple way to find out if they are all there are there is to typecheck. eg: That's the whole point of subclassing bool ... to let the user know they have at their disposal (in a portable, simple way) all the features of the base type. Well, if I make a new object -- type checking is pointless. No user thinking they were coding for floating point in the past would know that my new return type is totally compatible with bool. They would have to have written individual tests for the existence of every method in bool, and why would they be crazy enough to do that? It's a lot of work for nothing... -- https://mail.python.org/mailman/listinfo/python-list
Re: Comparisons and sorting of a numeric class....
On Wed, Jan 7, 2015 at 1:20 PM, Andrew Robinson wrote: > Because defining a bunch of special methods defeats the very purpose of > making my class compatible with float variables. > eg: No legacy code would work... > > I know (belatedly) that am going to have to define my own class. > That's pretty much a given, but I want to do it in a way which requires my > users to make very few changes to their traditional floating point > algorithms and code. If you use a dedicated function instead of methods, that function can be written to take any combination of float and pseudo-float. > The type check issue is mostly about compatability in the first place ; eg: > users typecheck either unintentionally -- (novices syndrome) -- or because > they need all the capabilities of a given type, and the only simple way to > find out if they are all there are there is to typecheck. eg: That's the > whole point of subclassing bool ... to let the user know they have at their > disposal (in a portable, simple way) all the features of the base type. Thing is, you're not fulfilling bool's contract, so it's better to not subclass, and just make your new type always falsy. If your users are type-checking bools, you might just have to let it break, and tell them not to do that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Comparisons and sorting of a numeric class....
On 1/6/2015 9:01 PM, Andrew Robinson wrote: [snip] There are very few (about 4) builtin classes that cannot be subclassed. bool is one of those few, float is not. Go ahead and subclass it. >>> class F(float): pass >>> F >>> F(2.3) + F(3.3) 5.6 -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Comparisons and sorting of a numeric class....
On 01/06/2015 06:34 PM, Terry Reedy wrote: On 1/6/2015 9:01 PM, Andrew Robinson wrote: [snip] There are very few (about 4) builtin classes that cannot be subclassed. bool is one of those few, float is not. Go ahead and subclass it. >>> class F(float): pass >>> F >>> F(2.3) + F(3.3) 5.6 Thanks terry! That's a relief. Ive just managed to find a few classes that won't subtype by trial and error in the last two months and was getting pessimistic. ( eg: doing web pages I wanted to customize the error output traceback stack from a python script based on where the exception occurred. GH! I worked around the no sub-typing issue, but it took a lot of guessing to trick python into accepting a fake class to the print traceback functions the webserver used... ) -- https://mail.python.org/mailman/listinfo/python-list
Re: Comparisons and sorting of a numeric class....
On 01/06/2015 06:31 PM, Chris Angelico wrote: The type check issue is mostly about compatability in the first place ; eg: users typecheck either unintentionally -- (novices syndrome) -- or because they need all the capabilities of a given type, and the only simple way to find out if they are all there are there is to typecheck. eg: That's the whole point of subclassing bool ... to let the user know they have at their disposal (in a portable, simple way) all the features of the base type. Thing is, you're not fulfilling bool's contract, so it's better to not subclass, and just make your new type always falsy. If your users are type-checking bools, you might just have to let it break, and tell them not to do that. ChrisA Explain; How does mere subclassing of bool break the contract that bool has? eg: What method or data would the superclass have that my subclass would not? Are you speaking about the quasi singleton nature of bool ? If so, I spent a little time browsing my design patterns book by Gamma, Helm, Johnson, and Vlissides; and I'm looking at the singleton pattern on p.127. The author writes, "Use the singleton pattern when: -- There must be exactly one instance of a class, and it must be accessible to clients from a well-known access point. -- When the _sole instance_ should be extensible by subclassing, and clients should be able to use an extended instance *without modifying their code*. " So, it's clear that in typical programming scenarios -- objects which are even more restrictive than bool by having only a single allowed instance rather than TWO -- are *Still* intentionally allowed to be subclassed for compatibility reasons. And later in design patterns, the authors continue on: "2. Subclassing the singleton class. The _main issue is not so much defining the subclass_ but installing its unique instance so that clients will be able to use it." So, the general programming community is aware of the issue Rossum brings up about a singleton's subclass having an instance; it's just apparent that there are ways to work around the issue and preserve a singleton's character while still allowing a subclass. So: I'm really curious -- If subclassing is generally permitted for singletons as an industrial practice, why is it wrong to allow it in python? I mean, If this is because Python doesn't support sub-classes for singletons, then it seems that Python is lacking something that should be added. This isn't limited to bool, for as a library writer I might want to create a singleton class for my own purposes that has nothing to do with any of python's built in types. And so, it would be appropriate to have a mechanism for subclassing user created singletons as well I already KNOW that 'C++' does have a workaround mechanism, as I've mentioned in a different e-mail, so that there's no reason to instantiate an instance of the subclass of a singleton if you don't want to. That objection is really spurrious... so I really don't understand why Rossum cut off subclassability itself ... wasn't there any other way he could have prevented instantiation of subclasses without preventing the definition of a subclass itself? I mean, even in python I can execute some methods of a class without actually INSTANTIATING that class. eg: import decimal decimal.getcontext() So, I don't understand your objection. How does merely defining a subclass of bool violate the contract that bool puts out? -- https://mail.python.org/mailman/listinfo/python-list
Re: Comparisons and sorting of a numeric class....
On 01/06/2015 09:01 PM, Andrew Robinson wrote: On 01/06/2015 06:02 AM, Dave Angel wrote: On 01/06/2015 08:30 AM, Andrew Robinson wrote: So, I'm not sure I can subclass boolean either because that too is a built in class ... but I'm not sure how else to make an object that acts as boolean False, but can be differentiated from false by the 'is' operator. It's frustrating -- what good is subclassing, if one cant subclass all the base classes the language has? I said earlier that I don't think it's possible to do what you're doing without your users code being somewhat aware of your changes. Aye. You did. And I didn't disagree. :) The goal is merely to trip up those who don't know what I'm doing as little as possible and only break their code where the very notion of uncertainty is incompatible with what they are doing, or where they did something very stupid anyway... eg: to break it where there is a good reason for it to be broken. I may not achieve my goal, but I at least hope to come close... But as long as the user doesn't check for the subclass-ness of your bool-like function, you should manage. In Python, duck-typing is encouraged, unlike java or C++, where the only substitutable classes are subclasses. but if you can't subclass a built in type -- you can't duck type it -- for I seem to recall that Python forbids duck typing any built in class nut not subclasses. So your two solutions are mutually damaged by Guido's decision; And there seem to be a lot of classes that python simply won't allow anyone to subclass. ( I still need to retry subclassing float, that might still be possible. ) Removing both options in one blow is like hamstringing the object oriented re-useability principle completely. You must always re-invent the wheel from near scratch in Python --Guido van Rossum So, I think Guido may have done something so that there are only two instances of bool, ever. eg: False and True, which aren't truly singletons -- but follow the singleton restrictive idea of making a single instance of an object do the work for everyone; eg: of False being the only instance of bool returning False, and True being the only instance of bool returning True. Why this is so important to Guido, I don't know ... but it's making it VERY difficult to add named aliases of False which will still be detected as False and type-checkable as a bool. If my objects don't type check right -- they will likely break some people's legacy code... and I really don't even care to create a new instance of the bool object in memory which is what Guido seems worried about, rather I'm really only after the ability to detect the subclass wrapper name as distinct from bool False or bool True with the 'is' operator. If there were a There's already a contradiction in what you want. You say you don't want to create a new bool object (distinct from True and False), but you have to create an instance of your class. If it WERE a subclass of bool, it'd be a bool, and break singleton. Yes there seems to be a contradiction but I'm not sure there is ... and it stems in part from too little sleep and familiarity with other languages... Guido mentioned subclassing in 'C' as part of his justification for not allowing subclassing bool in python. That's what caused me to digress a bit... consider: In 'C++' I can define a subclass without ever instantiating it; and I can define static member functions of the subclass that operate even when there exists not a single instance of the class; and I can typecast an instance of the base class as being an instance of the subclass. So -- (against what Guido seems to have considered) I can define a function anywhere which returns my new subclass object as it's return value without ever instantiating the subclass -- because my new function can simply return a typecasting of a base class instance; The user of my function would never need to know that the subclass itself was never instantiated... for they would only be allowed to call static member functions on the subclass anyway, but all the usual methods found in the superclass(es) would still be available to them. All the benefits of subclassing still exist, without ever needing to violate the singleton character of the base class instance. PYTHON IS NOT C++. There is no typecasting, because Python "variables" don't have types, only the object has a type, and you can't force it to be something different. Unlike C++, Python has strict typing. And unlike Python that typing is on the data, NOT on the "variable." A Python variable is just a reference to the real data, and has no type of its own. If you try to create a new instance of bool, it'd either be True or it'd be False (exactly two objects, singletons), and in no way would it belong to your hypothetical subclass. As long as the user is not foolish enough to check the type, you can create a class that's equivalent to bool, and PRETEND it's a subclass.
Re: Comparisons and sorting of a numeric class....
On Wed, Jan 7, 2015 at 2:39 PM, Dave Angel wrote:
> Here we need help from someone who knows more about this particular detail.
> I don't know which special methods bool() or not will call, but I'd think it
> would be something with a better name than __nonzero__
In Python 2, it is indeed __nonzero__, but in Python 3, it's __bool__:
Python 2.7.3 (default, Mar 13 2014, 11:03:55)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class X:
... def __nonzero__(self): print("called")
...
>>> bool(X())
called
Traceback (most recent call last):
File "", line 1, in
TypeError: __nonzero__ should return an int
Python 3.5.0a0 (default:1c51f1650c42+, Dec 29 2014, 02:29:06)
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class X:
... def __bool__(self): print("called")
...
>>> bool(X())
called
Traceback (most recent call last):
File "", line 1, in
TypeError: __bool__ should return bool, returned NoneType
Also, as you can see, Py2's method allows any integer to be returned,
while Py3's expects a bool. The boolification of an object MUST result
in either True or False, nothing else.
>> Question: If two different class's instances are being compared by
>> '==', and both define an __eq__ method, which method gets called? ( I
>> don't know if that applied here... but I'm not familiar with order of
>> operations )
>
>
> The left object's methods are generally examined first. So if you said
> mylist * 5
>
> you'd be using a __mul__ method of list class.
Order of operations has nothing to do with this; that's to do with
operator precedence/associativity, which is what stipulates that all
of these parentheses are unnecessary:
a + (b * c)
(a + b) + c
a ** (b ** c)
a or (b and c)
(a + b) in c
a if (b + c) else d
The operator precedence tables neither know nor care what the objects
in question are. But once the interpreter gets to the next step, and
starts actually figuring out the value of the expression, then it
usually goes for the left object's methods first; if that object
returns NotImplemented, it'll try the right object (sometimes with a
reflected method):
>>> class X:
... def __eq__(self, other): print("Am I equal to:",other)
... def __add__(self, other): print("me +",other)
... def __radd__(self, other): print(other,"+ me")
...
>>> X() == 1
Am I equal to: 1
>>> 2 == X()
Am I equal to: 2
>>> X() + 3
me + 3
>>> 4 + X()
4 + me
>> But I don't think that stops me from treating the sort order of all
>> items which are quasi-equal, as a second search (hierarchical search).
>> eg: Sort first by definite magnitude, then among those deemed 'equal',
>> sort them by average expectation value... That's going to be good
>> enough for me and my users, for the sort order of truly quasi equal
>> things is arbitrary anyway... as long as it's not 'defintely wrong'
>> they'll have no reason to complain.
>
>
> You could write a sort that works that way, but I don't think you can assume
> that the built-in sort will. sort assumes that the comparison works in a
> certain way, and if it doesn't, the symptoms could range from random
> ordering (including items drastically out of order) to a possibly never
> terminating sort.
If you can separate the value into two parts, magnitude and
expectation, you could have a key function that makes them sortable:
def mag_exp(val):
if not isinstance(val, MagicFloat): return (val, None)
return int(val), val-int(val) # example
srtlst = sorted(lst, key=mag_exp)
That'll sort all elements by the first value in the tuple, and if
they're identical on that, by the second value. That's the easiest way
to do a multi-part sort.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Comparisons and sorting of a numeric class....
On 01/06/2015 10:37 PM, Andrew Robinson wrote: On 01/06/2015 06:31 PM, Chris Angelico wrote: I already KNOW that 'C++' does have a workaround mechanism, as I've mentioned in a different e-mail, so that there's no reason to instantiate an instance of the subclass of a singleton if you don't want to. That objection is really spurrious... so I really don't understand why Rossum cut off subclassability itself ... wasn't there any other way he could have prevented instantiation of subclasses without preventing the definition of a subclass itself? I mean, even in python I can execute some methods of a class without actually INSTANTIATING that class. eg: import decimal decimal.getcontext() Interesting that you pick as your example an ordinary function, not in a class at all. In this example, decimal is a module; you're calling a module level function. Perfectly normal. But you're right, you can call staticmethods of a class without instantiating it, and you can also call classmethods. But in both cases, the caller knows exactly what class he's referring to. Doesn't help your argument any. If you're not going to instantiate the class, then the fact that such a class is, or is not, a subclass of another is invisible, in any context I can think of (other than debuggers and such that do inspection by reflection). -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
