Unifying Long Integers and Integers: baseint
Is there a plan for implementing a base class for int and long (like basestring for str and unicode):
issubclass(int, baseint) and issubclass(long, baseint) True
? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru
Dmitry Vasiliev <lists@hlabs.spb.ru> writes:
Not that I'm aware of. Personally, I think it's slightly more likely that we'll have:
int is long True
but this is a long way off, and could cause upset with people who need to do bit bashing or interface with C. Of course,
baseint = (int, long)
makes what you type accurate today :-) Cheers, mwh --
Michael Hudson wrote:
Quote from PEP-237: """ A new type, integer, may be introduced that is an abstract base type of which both the int and long implementation types are subclassed. This is useful so that programs can check integer-ness with a single test: if isinstance(i, integer): ... """ So maybe correct question then: is there a plan for implementing the integer type in Python 2.4?
-- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru
Dmitry Vasiliev wrote:
Well, we're a couple of weeks from what will hopefully be the last alpha. I'd _hope_ anything like this would be in before then (although we can have things that change behaviour up until b1, I'd prefer that a3->b1 is just fixing bugs that require changes, or minor changes, not major changes). OTOH, I'm not sure how deep a change like this would be. In any case, if it's a change that you (or anyone else) feels strongly about, a patch on SF would be a first step towards making this happen. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony Baxter wrote:
So here it is: http://sourceforge.net/tracker/index.php?func=detail&aid=1007068&group_id=5470&atid=305470 -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru
>> Is there a plan for implementing a base class for int and long (like >> basestring for str and unicode): Michael> Not that I'm aware of. We've discussed the numeric type hierarchy in the past. I think it would be worth considering all the numeric types at once and come up with a reasonable hierarchy that includes float, complex and decimal types as well. (It's clear there is no "best" way to do that.) Skip
Skip Montanaro wrote:
Something like following? object numeric integer int long float complex PS I've already have implementation for baseinteger, but can't made a patch since cvs.python.sourceforge.net always told me 'Connection timed out'... :-/ -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru
>> I think it would be worth considering all the numeric types at once >> and come up with a reasonable hierarchy that includes float, complex >> and decimal types as well. (It's clear there is no "best" way to do >> that.) Dmitry> Something like following? Dmitry> object Dmitry> numeric Dmitry> integer Dmitry> int Dmitry> long Dmitry> float Dmitry> complex At some level it seems that float is a specialization of complex (w/ imag field == 0). Also, it's not clear that float or complex don't have something other than a sibling relationship to integers. I don't have the time to dig up the previous discussions. Three days out of town left me we nearly a thousand Python-related mail messages. I have no idea how (if at all) I'll be able to boil any of that down into reasonable edits to PEP 318. Skip
On Tuesday 2004-08-10 14:35, Skip Montanaro wrote:
Start by thinking about the mathematical types, which have nice clear subset relationships between them: number complex real integer Python doesn't have anything between "number" and "complex" and there's no particular reason to think it ever will, so let's simplify: number real integer Now consider the different implementation types and fit them in: number complex real (Decimal) float integer int long I've reintroduced "complex" here as a name for the implementation type, which in some sense should really be called complex_float or something like that. By way of clarification of the principles here, this is what would happen to the hierarchy if Python were to acquire a type for ratios of integers. I'll call that type "fraction" and the underlying mathematical type "rational". Then we'd get: number complex real (Decimal) float rational fraction integer int long (You could argue that floats are rationals really, but that's misleading even though it's true. The *structure* of arithmetic operations on floats isn't the same as that on rationals.) -- g
Skip Montanaro wrote:
I don't have the time to dig up the previous discussions.
why not start with the PEPs? http://www.python.org/peps/pep-0228.html http://www.python.org/peps/pep-0242.html http://www.python.org/peps/pep-0313.html (etc) </F>
Michael Hudson wrote:
You've right, thanks. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru
I think this would be a good idea; maybe the name should be baseinteger? I think it's been suggested before, and can't remember why it wasn't implemented -- perhaps the use cases aren't as compelling as for basestring? --Guido van Rossum (home page: http://www.python.org/~guido/)
Dmitry Vasiliev <lists@hlabs.spb.ru> writes:
Not that I'm aware of. Personally, I think it's slightly more likely that we'll have:
int is long True
but this is a long way off, and could cause upset with people who need to do bit bashing or interface with C. Of course,
baseint = (int, long)
makes what you type accurate today :-) Cheers, mwh --
Michael Hudson wrote:
Quote from PEP-237: """ A new type, integer, may be introduced that is an abstract base type of which both the int and long implementation types are subclassed. This is useful so that programs can check integer-ness with a single test: if isinstance(i, integer): ... """ So maybe correct question then: is there a plan for implementing the integer type in Python 2.4?
-- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru
Dmitry Vasiliev wrote:
Well, we're a couple of weeks from what will hopefully be the last alpha. I'd _hope_ anything like this would be in before then (although we can have things that change behaviour up until b1, I'd prefer that a3->b1 is just fixing bugs that require changes, or minor changes, not major changes). OTOH, I'm not sure how deep a change like this would be. In any case, if it's a change that you (or anyone else) feels strongly about, a patch on SF would be a first step towards making this happen. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony Baxter wrote:
So here it is: http://sourceforge.net/tracker/index.php?func=detail&aid=1007068&group_id=5470&atid=305470 -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru
>> Is there a plan for implementing a base class for int and long (like >> basestring for str and unicode): Michael> Not that I'm aware of. We've discussed the numeric type hierarchy in the past. I think it would be worth considering all the numeric types at once and come up with a reasonable hierarchy that includes float, complex and decimal types as well. (It's clear there is no "best" way to do that.) Skip
Skip Montanaro wrote:
Something like following? object numeric integer int long float complex PS I've already have implementation for baseinteger, but can't made a patch since cvs.python.sourceforge.net always told me 'Connection timed out'... :-/ -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru
>> I think it would be worth considering all the numeric types at once >> and come up with a reasonable hierarchy that includes float, complex >> and decimal types as well. (It's clear there is no "best" way to do >> that.) Dmitry> Something like following? Dmitry> object Dmitry> numeric Dmitry> integer Dmitry> int Dmitry> long Dmitry> float Dmitry> complex At some level it seems that float is a specialization of complex (w/ imag field == 0). Also, it's not clear that float or complex don't have something other than a sibling relationship to integers. I don't have the time to dig up the previous discussions. Three days out of town left me we nearly a thousand Python-related mail messages. I have no idea how (if at all) I'll be able to boil any of that down into reasonable edits to PEP 318. Skip
On Tuesday 2004-08-10 14:35, Skip Montanaro wrote:
Start by thinking about the mathematical types, which have nice clear subset relationships between them: number complex real integer Python doesn't have anything between "number" and "complex" and there's no particular reason to think it ever will, so let's simplify: number real integer Now consider the different implementation types and fit them in: number complex real (Decimal) float integer int long I've reintroduced "complex" here as a name for the implementation type, which in some sense should really be called complex_float or something like that. By way of clarification of the principles here, this is what would happen to the hierarchy if Python were to acquire a type for ratios of integers. I'll call that type "fraction" and the underlying mathematical type "rational". Then we'd get: number complex real (Decimal) float rational fraction integer int long (You could argue that floats are rationals really, but that's misleading even though it's true. The *structure* of arithmetic operations on floats isn't the same as that on rationals.) -- g
Skip Montanaro wrote:
I don't have the time to dig up the previous discussions.
why not start with the PEPs? http://www.python.org/peps/pep-0228.html http://www.python.org/peps/pep-0242.html http://www.python.org/peps/pep-0313.html (etc) </F>
Michael Hudson wrote:
You've right, thanks. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru
I think this would be a good idea; maybe the name should be baseinteger? I think it's been suggested before, and can't remember why it wasn't implemented -- perhaps the use cases aren't as compelling as for basestring? --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (7)
-
Anthony Baxter -
Dmitry Vasiliev -
Fredrik Lundh -
Gareth McCaughan -
Guido van Rossum -
Michael Hudson -
Skip Montanaro