[issue13137] from __future__ import division breaks ad hoc numeric types

[Blair]

New submission from Blair :

I believe that the use of __future__.division may have unintended consequences 
with user types that define division.

The following fails:

from __future__ import division

class NumericType(object):
def __init__(self,x):
self.x = x

def __div__(self,rhs):
return self.x/rhs

print NumericType(3.0) / 2.0

with the error message

  File "C:\proj_py\learning\future_bug\future.py", line 10, in 
print NumericType(3.0) / 2.0
TypeError: unsupported operand type(s) for /: 'NumericType' and 'float'

Remove the line `from __future__ import division` and everything works fine.

I am using Python 2.7.2

--
components: None
messages: 145195
nosy: gumtree
priority: normal
severity: normal
status: open
title: from __future__ import division breaks ad hoc numeric types
type: behavior
versions: Python 2.7

___
Python tracker 
<http://bugs.python.org/issue13137>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5211] Fix complex type to avoid coercion in 2.7.

[Blair]

Blair  added the comment:

Hi Mark,

I thought that this had all been fixed, but it seems not.

Consider the following:

class xcomplex( complex ):
def __new__(cls,*args,**kwargs):
return complex.__new__(cls,*args,**kwargs)
def __add__(self,x):
return xcomplex( complex.__add__(self,x) )
def __radd__(self,x):
print "larg: ", type(x),"returning: ",
return xcomplex( complex.__radd__(self,x) )

class xfloat(float):
def __new__(cls,*args,**kwargs):
return float.__new__(cls,*args,**kwargs)
def __add__(self,x):
return xfloat( float.__add__(self,x) )
def __radd__(self,x):
print "larg: ", type(x),"returning: ",
return xfloat( float.__radd__(self,x) )

z = 1j
xz = xcomplex(1j)
f = 1.0
xf = xfloat(1.0)

print
print "---"
print "expect xcomplex:", type(z + xz)
print "expect xcomplex:", type(f + xz)
print "expect xfloat:", type(f + xf)
print "expect ???:", type(z + xf)

When this runs, the first three conversions are fine, the last is not: there
is no call to xfloat.__radd__. It seems that the builtin complex type simply
thinks it is dealing with a float. Here is the output

---
expect xcomplex: larg:   returning:  
expect xcomplex: larg:   returning:  
expect xfloat: larg:   returning:  
expect ???: 

The last line shows that no call to __radd__ occurred.

Is there anything that can be done now about this now, or is it just too
late?

Regards

Blair

At 01:13 a.m. 31/05/2010, you wrote:

Mark Dickinson  added the comment:

r78280 didn't remove the implicit coercion for rich comparisons;  that's now
been done in r81606.

--

___
Python tracker 
<http://bugs.python.org/issue5211>
___Python tracker <
rep...@bugs.python.org>

--
Added file: http://bugs.python.org/file19820/unnamed

___
Python tracker 
<http://bugs.python.org/issue5211>
___Hi Mark,
I thought that this had all been fixed, but it seems not.
Consider the following:
class xcomplex( complex ):
    def __new__(cls,*args,**kwargs):
        return complex.__new__(cls,*args,**kwargs)
    def __add__(self,x):
        return xcomplex( complex.__add__(self,x) )
    def __radd__(self,x):
        print "larg: ", type(x),"returning: ",
        return xcomplex( complex.__radd__(self,x) )

class xfloat(float):
    def __new__(cls,*args,**kwargs):
        return float.__new__(cls,*args,**kwargs)
    def __add__(self,x):
        return xfloat( float.__add__(self,x) )
    def __radd__(self,x):
        print "larg: ", type(x),"returning: ",
        return xfloat( float.__radd__(self,x) )

z = 1j
xz = xcomplex(1j)
f = 1.0
xf = xfloat(1.0)

print
print "---"
print "expect xcomplex:", type(z + xz) 
print "expect xcomplex:", type(f + xz) 
print "expect xfloat:", type(f + xf)
print "expect ???:", type(z + xf)
When this runs, the first three conversions are fine, the last is not: 
there is no call to xfloat.__radd__. It seems that the builtin complex type 
simply thinks it is dealing with a float. Here is the output

---
expect xcomplex: larg:  <type 'complex'> returning:  <class 
'__main__.xcomplex'>
expect xcomplex: larg:  <type 'float'> returning:  <class 
'__main__.xcomplex'>
expect xfloat: larg:  <type 'float'> returning:  <class 
'__main__.xfloat'>
expect ???: <type 'complex'>
The last line shows that no call to __radd__ occurred. 
Is there anything that can be done now about this now, or is it just too 
late?
RegardsBlair
At 01:13 a.m. 31/05/2010, you wrote:
Mark Dickinson <mailto:dicki...@gmail.com";>dicki...@gmail.com> added the 
comment:
r78280 didn't remove the implicit coercion for rich comparisons;  
that's now been done in r81606.
--
___
Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>
<http://bugs.python.org/issue5211";>http://bugs.python.org/issue5211>
___Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5211] Fix complex type to avoid coercion in 2.7.

[Blair]

Blair  added the comment:

I see your point Mark, however it does not seem to be the right way to do
this.

Are you aware that Python has formally specified this behaviour somewhere? I
could not find an explicit reference in the documentation.

The problem that has been fixed is covered in the documentation:

(3.4.8. Emulating numeric types: Note
If the right operand’s type is a subclass of the left operand’s type and
that subclass provides the
reflected method for the operation, this method will be called before the
left operand’s non-reflected method.
This behavior allows subclasses to override their ancestors’ operations.)

This rule is needed so that mixed-type arithmetic operations do not revert
to the ancestor's type. However, one would expect that different numeric
types (int float complex)  would all behave in a similar way. For example,

xi = xint(3)
3 + xi  # is an xint(6)
3.0 + xi # is float(6)

This is the same problem as the one that has been fixed from a practical
point of view. Such behaviour is not going to be useful (IMO).

It seems to me that xint.__radd__ would need to be called if the left
operand is a subclass of any of the number types (in this case,
isinstance(left_op,numbers.Complex) == True).

Am I missing something?

Mark Dickinson  added the comment:

I think that's expected behaviour.  Note that int vs float behaves in the
same way as float vs complex:

... def __radd__(self, other):
... print "__radd__"
... return 42
...
>>> 3 + xint(5)
__radd__
42
>>> 3.0 + xint(5)  # xint.__radd__ not called.
8.0

As with your example, the float.__add__ method is happy to deal with an int
or an instance of any subclass of int.

--

___
Python tracker 
<http://bugs.python.org/issue5211>
___

--
Added file: http://bugs.python.org/file19828/unnamed

___
Python tracker 
<http://bugs.python.org/issue5211>
___I see your point Mark, however it does not seem to be the right way to do this. 
Are you aware that Python has formally specified this behaviour 
somewhere? I could not find an explicit reference in the documentation.
The problem that has been fixed is covered in the 
documentation:(3.4.8. Emulating numeric types: NoteIf the right 
operand’s type is a subclass of the left operand’s type and that subclass 
provides thereflected method for the operation, this method will be called 
before the left operand’s non-reflected method.
This behavior allows subclasses to override their ancestors’ 
operations.)This rule is needed so that mixed-type arithmetic 
operations do not revert to the ancestor's type. However, one would expect 
that different numeric types (int float complex)  would all behave in a 
similar way. For example,
xi = xint(3)3 + xi  # is an xint(6)3.0 + xi # is 
float(6)This is the same problem as the one that has been fixed from a 
practical point of view. Such behaviour is not going to be useful (IMO). 

It seems to me that xint.__radd__ would need to be called if the left operand 
is a subclass of any of the number types (in this case, 
isinstance(left_op,numbers.Complex) == True). Am I missing something? 

Mark Dickinson <mailto:dicki...@gmail.com";>dicki...@gmail.com> added the 
comment:
I think that's expected behaviour.  Note that int vs float behaves in the 
same way as float vs complex:
>>> class xint(int):
...     def __radd__(self, other):
...         print "__radd__"
...         return 42
... 
>>> 3 + xint(5)
__radd__
42
>>> 3.0 + xint(5)  # xint.__radd__ not called.
8.0
As with your example, the float.__add__ method is happy to deal with an int or 
an instance of any subclass of int.
--
___
Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>
<http://bugs.python.org/issue5211";>http://bugs.python.org/issue5211>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5211] Fix complex type to avoid coercion in 2.7.

[Blair]

Blair  added the comment:

I'd like to add a few more observations to the mix.

I have run the following in both 2.6.6 and in 2.7

class xfloat(float):
def __new__(cls,x):
return float.__new__(cls,x)

def __radd__(self,lhs):
print "__radd__ got: %s" % type(lhs)
if isinstance(lhs,(int,float)):
return xfloat( float(self) + lhs )
else:
return NotImplemented

xf = xfloat(9.0)

cases = dict(int=1,float=1.0,complex=1.0+1j)
for k,v in cases.items():
y = v + xf
print "%s + xfloat" % k
print type(y)
print y

In 2.7 this gives:

__radd__ got: 
int + xfloat

10.0
__radd__ got: 
float + xfloat

10.0
complex + xfloat

(10+1j)

In 2.6.6 I get:

__radd__ got: 
int + xfloat

10.0
__radd__ got: 
float + xfloat

10.0
__radd__ got: 
complex + xfloat

(10+1j)

They are the same except for the last case.

My feeling is that the behaviour of 2.6.6 (for subclassing float) is
correct.

The behaviour of 2.6.6 is needed to enable you to implement the commutative
property of addition (ie, you expect to get the same outcome from x+y or
y+x), which I would say is a pretty fundamental requirement.

I have also tried the following

class xint(int):
def __new__(cls,x):
return int.__new__(cls,x)

def __radd__(self,lhs):
print "__radd__ got: %s" % type(lhs)
if isinstance(lhs,(int,)):
return xint( float(self) + lhs )
else:
return NotImplemented

print
print "---"
xf = xint(9)

cases = dict(int=1,float=1.0,complex=1.0+1j)
for k,v in cases.items():
y = v + xf
print "%s + xint" % k
print type(y)
print y

In 2.6.6 I get

__radd__ got: 
int + xint

10
float + xint

10.0
__radd__ got: 
complex + xint

(10+1j)

and in 2.7

---
__radd__ got: 
int + xint

10
float + xint

10.0
complex + xint

(10+1j)

In my opinion, 2.6.6 was faulty in the float + xint case, for the same
reasons as above, and 2.7 is faulty in both float + xint and complex + xint.

--
Added file: http://bugs.python.org/file19832/unnamed

___
Python tracker 
<http://bugs.python.org/issue5211>
___I'd like to add a few more observations to the mix.I have run the 
following in both 2.6.6 and in 2.7class xfloat(float):    def 
__new__(cls,x):        return float.__new__(cls,x)    def 
__radd__(self,lhs):
        print "__radd__ got: %s" % type(lhs)        
if isinstance(lhs,(int,float)):            return xfloat( 
float(self) + lhs )        else:            return 
NotImplementedxf = xfloat(9.0)
cases = dict(int=1,float=1.0,complex=1.0+1j)for k,v in 
cases.items():    y = v + xf    print "%s + xfloat" % 
k    print type(y)    print yIn 2.7 this 
gives:__radd__ got: <type 'int'>
int + xfloat<class '__main__.xfloat'>10.0__radd__ 
got: <type 'float'>float + xfloat<class 
'__main__.xfloat'>10.0complex + xfloat<type 
'complex'>
(10+1j)In 2.6.6 I get:__radd__ got: <type 
'int'>int + xfloat<class 
'__main__.xfloat'>10.0__radd__ got: <type 
'float'>float + xfloat<class 
'__main__.xfloat'>
10.0__radd__ got: <type 'complex'>complex + 
xfloat<type 'complex'>(10+1j)They are the same 
except for the last case.My feeling is that the behaviour of 2.6.6 (for 
subclassing float) is correct.
The behaviour of 2.6.6 is needed to enable you to implement the commutative 
property of addition (ie, you expect to get the same outcome from x+y or y+x), 
which I would say is a pretty fundamental requirement.
I have also tried the followingclass xint(int):    def 
__new__(cls,x):        return int.__new__(cls,x)        
    def __radd__(self,lhs):        print "__radd__ 
got: %s" % type(lhs)
        if isinstance(lhs,(int,)):            return 
xint( float(self) + lhs )        else:            
return NotImplementedprintprint 
"---"xf = xint(9)cases = 
dict(int=1,float=1.0,complex=1.0+1j)
for k,v in cases.items():    y = v + xf    print "%s + 
xint" % k    print type(y)    print y    In 2.6.6 
I get__radd__ got: <type 'int'>int + 
xint<class '__main__.xint'>
10float + xint<type 'float'>10.0__radd__ got: 
<type 'complex'>complex + xint<type 
'complex'>(10+1j)and in 
2.7---__radd__ got: <type 'int'>
int + xint<class '__main__.xint'>10float + 
xint<type 'float'>10.0complex + xint<type 
'complex'>(10+1j)In my opinion, 2.6.6 was faulty in the 
float + xint case, for the same reasons as above, and 2.7 is faulty in both 
float + xint and complex + xint.

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

[issue5211] Fix complex type to avoid coercion in 2.7.

[Blair]

Blair  added the comment:

Just to keep this discussion as clear as possible Mark, it was your first
option that I suggest is needed.

When that is done (as it was for a subclass of float in 2.6.6) it is
possible for the author of the subclass to implement commutative binary
operations (like + and * that must behave the same regardless of argument
order). Otherwise (as far as I can see) this cannot be done.

On Mon, Nov 29, 2010 at 5:04 AM, Mark Dickinson wrote:

>
> Changes by Mark Dickinson :
>
>
> Removed file: http://bugs.python.org/file19820/unnamed
>
> ___
> Python tracker 
> <http://bugs.python.org/issue5211>
> ___
>

--
Added file: http://bugs.python.org/file19859/unnamed

___
Python tracker 
<http://bugs.python.org/issue5211>
___Just to keep this discussion as clear as possible Mark, it was your first 
option that I suggest is needed. When that is done (as it was for a 
subclass of float in 2.6.6) it is possible for the author of the subclass to 
implement commutative binary operations (like + and * that must behave the same 
regardless of argument order). Otherwise (as far as I can see) this cannot be 
done.
On Mon, Nov 29, 2010 at 5:04 AM, Mark 
Dickinson <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> 
wrote:

Changes by Mark Dickinson <mailto:dicki...@gmail.com";>dicki...@gmail.com>:


Removed file: http://bugs.python.org/file19820/unnamed"; 
target="_blank">http://bugs.python.org/file19820/unnamed

___
Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>
<http://bugs.python.org/issue5211"; 
target="_blank">http://bugs.python.org/issue5211>
___

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

[issue5211] Fix complex type to avoid coercion in 2.7.

[Blair]

Blair  added the comment:

I am not really the person (I don't know how Python is implemented) to
explain how the correct behaviour should be achieved (sorry). I do
appreciate that this may seem like exceptional behaviour. Numbers are a bit
different.

However, for what its worth, I think that the 'correct behaviour' was
implemented for subclasses of float and was working in Python 2.6, but not
now in 2.7. I don't know how the earlier implementation was done, but it
does work (I have used it to develop a nice little math library). Would
there be any documentation about the implementation?

I would say that the semantics do not need to apply to arbitrary Python
objects. The problem arises for numeric type subclasses when they are mixed
with non-subclassed numeric types.

In that case:

For 'x opn y' any binary operator (like +,*, etc), if (and only if)  'x' is
a built-in numeric type (int, long, float, complex) and 'y' is a subclass of
a built-in numeric type, then y.__ropn__(x) (if it exists) should be called
before x.__opn__(y).

If that were done, then subclasses of number types can implement commutative
operator properties. Otherwise, I don't think it works properly.

I see this as 'special' behaviour required of the int, long, float and
complex classes, rather than special behaviour for all Python objects.

If both 'x' and 'y' are subclasses of built in number types the required
behaviour seems too complicated to specify. I would be inclined to do
nothing special. That is, if both 'x' and 'y' are derived from built in
numeric classes (possibly different types) then x.__opn__(y) would be
called.

And should this apply to non-number types? I think not. Numbers deserve
special treatment.

I hope this helps.

On Mon, Nov 29, 2010 at 9:48 AM, Mark Dickinson wrote:

>
> Changes by Mark Dickinson :
>
>
> Removed file: http://bugs.python.org/file19859/unnamed
>
> ___
> Python tracker 
> <http://bugs.python.org/issue5211>
> ___
>

--
Added file: http://bugs.python.org/file19861/unnamed

___
Python tracker 
<http://bugs.python.org/issue5211>
___I am not really the person (I don't know how Python is implemented) to 
explain how the correct behaviour should be achieved (sorry). I do appreciate 
that this may seem like exceptional behaviour. Numbers are a bit different.
However, for what its worth, I think that the 'correct behaviour' 
was implemented for subclasses of float and was working in Python 2.6, but not 
now in 2.7. I don't know how the earlier implementation was done, but it 
does work (I have used it to develop a nice little math library). Would there 
be any documentation about the implementation?
I would say that the semantics do not need to apply to arbitrary Python 
objects. The problem arises for numeric type subclasses when they are mixed 
with non-subclassed numeric types.  In that case:For 'x 
opn y' any binary operator (like +,*, etc), if (and only if)  'x' 
is a built-in numeric type (int, long, float, complex) and 'y' is a 
subclass of a built-in numeric type, then y.__ropn__(x) (if it exists) should 
be called before x.__opn__(y).
If that were done, then subclasses of number types can implement 
commutative operator properties. Otherwise, I don't think it works 
properly.I see this as 'special' behaviour required of the int, 
long, float and complex classes, rather than special behaviour for all Python 
objects.
If both 'x' and 'y' are subclasses of built in number types 
the required behaviour seems too complicated to specify. I would be inclined to 
do nothing special. That is, if both 'x' and 'y' are derived 
from built in  numeric classes (possibly different types) then x.__opn__(y) 
would be called.
And should this apply to non-number types? I think not. Numbers deserve 
special treatment.I hope this helps.On 
Mon, Nov 29, 2010 at 9:48 AM, Mark Dickinson <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> 
wrote:

Changes by Mark Dickinson <mailto:dicki...@gmail.com";>dicki...@gmail.com>:


Removed file: http://bugs.python.org/file19859/unnamed"; 
target="_blank">http://bugs.python.org/file19859/unnamed

___
Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>
<http://bugs.python.org/issue5211"; 
target="_blank">http://bugs.python.org/issue5211>
___

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

[issue3734] subclassing complex

[Blair]

New submission from Blair <[EMAIL PROTECTED]>:

The following is quoted from the Python docs (ref/numeric_types):

"Note: If the right operand's type is a subclass of the left operand's
type and that subclass provides the reflected method for the operation,
this method will be called before the left operand's non-reflected
method. This behavior allows subclasses to override their ancestors'
operations."

My issue is that the built-in complex type does not respect this rule
(see code below). Note that float can be subclassed using the method
shown below and the rules are applied correctly. It seems that it is
only a problem with complex.

class xcomplex( complex ):

def __new__(cls,*args,**kwargs):
return complex.__new__(cls,*args,**kwargs)

def __coerce__(self,other):
t = complex.__coerce__(self,other)
try:
return (self,xcomplex(t[1]))
except TypeError:
return t

def __add__(self,x):
return xcomplex( complex.__add__(self,x) )

def __radd__(self,x):
return xcomplex( complex.__radd__(self,x) ) 

print type(z + xz)  # gives complex when xcomplex is required

--
components: None
messages: 72169
nosy: gumtree
severity: normal
status: open
title: subclassing complex
type: behavior
versions: Python 2.5

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3734>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5211] Fix complex type to avoid coercion in 2.7.

[Blair]

Blair  added the comment:

I also agree that this bug was never more than a small wart. However, I'm now 
curious. 

If Python 3 does not support coercion, I think that it will not be possible to 
write something like my xfloat class, derived from float (i.e., some binary 
operations between an xfloat and a float would return a float instead of an 
xfloat). 

If I am correct in think that it would seem to be a step backward.

Will Python 3 deal with mixed types in some other way, or has this problem been 
abandoned altogether? If it is the latter, I think it is a pity.

--

___
Python tracker 
<http://bugs.python.org/issue5211>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5211] Fix complex type to avoid coercion in 2.7.

[Blair]

Blair  added the comment:

OK. I have gone back to the beginning to refresh my memory and I see a possible 
point of misunderstanding. I am not sure that we are really talking about the 
problem that prompted my initial report (msg72169, issue 3734). 

Immediately following my message, Daniel Diniz confirmed the bug and expanded 
on my code with an xfloat class of his own that uses __coerce__. 

In fact, if I had submitted an xfloat class it would have been the following 

class xfloat( float ):

def __new__(cls,*args,**kwargs):
return float.__new__(cls,*args,**kwargs)

def __add__(self,x):
return xfloat( float.__add__(self,x) )

def __radd__(self,x):
return xfloat( float.__radd__(self,x) )

My xfloat works fine in 2.6.4 and it was my wish, at the time, to write a class 
for xcomplex that behaved in a similar way. According to the Python manual, 
that should have been possible, but it wasn't.

So, I guess coercion is not really the problem. 

However, there does seem to be something wrong with the complex type.

I have looked at the manual for Python 3 and see that the same rules apply for 
classes that emulate numeric types, namely:

"If the right operand’s type is a subclass of the left operand’s type and that 
subclass provides the reflected method for the operation, this method will be 
called before the left operand’s non-reflected method. This behavior allows 
subclasses to override their ancestors’ operations."

The question I have then is will the following work in Python 3 (it doesn't in 
2.6.4)?

class xcomplex( complex ):

def __new__(cls,*args,**kwargs):
return complex.__new__(cls,*args,**kwargs)

##def __coerce__(self,other):
##t = complex.__coerce__(self,other)
##try:
##return (self,xcomplex(t[1]))
##except TypeError:
##return t

def __add__(self,x):
return xcomplex( complex.__add__(self,x) )

def __radd__(self,x):
return xcomplex( complex.__radd__(self,x) )

xz = xcomplex(1+2j)
xy = float(10.0)
z = complex(10+1j)

print "would like xcomplex type each time"
print type(xz + z)  
print type(xz + xy) 
print type(xz + 10) 
print type(xy + xz) 
print type(10 + xz) 
print type(z + xz)

--

___
Python tracker 
<http://bugs.python.org/issue5211>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3734] subclassing complex

[Blair]

Blair  added the comment:

While Mark Dickinson's patch fixes the documentation, it does not offer 
a solution to the original problem, which was rooted in a need to 
provide special behaviour based on the numeric types. I made the 
original posting because I hoped that this problem could be resolved.

___
Python tracker 
<http://bugs.python.org/issue3734>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5211] Fix complex type to avoid coercion in 2.7.

[Blair]

Blair  added the comment:

I am happy to collaborate in finding a solution, but I do not have 
enough knowledge or skill to work with the code alone.

Simply documenting it does not remove the frustration that a few people 
will enounter. The key point being that you can subclass the other 
numeric types, but not complex. Worse, you may think that you have 
succeeded in subclassing complex too, because it is only when the 
__ropn__ binary operators are used that the type reverts to the base 
class type.

Would you want to subclass a numeric type? I agree, it is a bit obsure, 
but I did a search on this before making the post and there have been 
others who found the problem too. 

In my case, I think that the motivation may seem a bit obscure. I had 
developed some numerical-like types (from scratch -- no subclassing) 
and I wanted to be able to write functions taking as possible arguments 
these types and Python numerical types indifferently. I realised that I 
could not achieve exactly what I wanted, however, by subclassing float, 
int, etc I could add a few methods that would allow my generic 
functions to work with either my types or the subclassed Python types. 
At the same time, the subclassed numerical types could still be used as 
numerical quantities (float, int,...). It seemed like a pretty elegant 
solution.

If that explanation does not make sense, then I suppose other simpler 
motivations could be, eg, to subclass float so that only positive 
values are acceptable; to subclass complex so that only values lying 
within the unit circle are acceptable, etc. That is, one might like to 
define a type that can only take on physically meaningful values (mass 
cannot be negative, a complex reflection coeffcieint cannot have a 
magnitude greater than unity, ..)

So, my feeling is that this is worth fixing because the work done on 
float, int etc, is clearly useful and it appears (to me) that the 
complex case is an oversight.

___
Python tracker 
<http://bugs.python.org/issue5211>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1630] sys.maxint is documented but should not be

[Blair Zajac]

New submission from Blair Zajac:

There is still documentation for sys.maxint even though it no
longer exists in Python 3.0:

$ /tmp/p3.0/bin/python
Python 3.0a2 (r30a2:59382, Dec 13 2007, 11:07:38)
[GCC 3.4.3 20050227 (Red Hat 3.4.3-22.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> [x for x in sys.__doc__.split('\n') if x.find('maxint') != -1]
['maxint -- the largest supported integer (the smallest is -maxint-1)']
>>> sys.maxint
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute 'maxint'

--
components: Library (Lib)
messages: 58645
nosy: blair
severity: normal
status: open
title: sys.maxint is documented but should not be
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1630>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21672] Python for Windows 2.7.7: Path Configuration File No Longer Works With UNC Paths

[Jacob Blair]

New submission from Jacob Blair:

I just upgraded from 2.7.6 to 2.7.7, on Windows, and have encountered different 
behavior in my path configuration (.pth) files. One of my files had lines 
similar to these:

\\host\sharefolder

These paths (UNC-style), are not being loaded into sys.path. It is successfully 
loading path lines from this and other files, so long as they have a drive 
letter.

--
messages: 219833
nosy: Jacob.Blair
priority: normal
severity: normal
status: open
title: Python for Windows 2.7.7: Path Configuration File No Longer Works With 
UNC Paths
versions: Python 2.7

___
Python tracker 
<http://bugs.python.org/issue21672>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9456] Apparent memory leak in PC/bdist_wininst/install.c

[Zachary Blair]

New submission from Zachary Blair :

>From inspecting the code in install.c's DeleteRegistryValue() and 
>DeleteRegistryKey() functions, it appears as though there can be a small 
>memory leak in the event that either function is passed an invalid argument.

This patch corrects this issue by making sure to free any allocated memory 
before returning, even when an invalid argument is passed in.

--
components: Windows
files: install_c.diff
keywords: patch
messages: 112541
nosy: Zachary.Blair
priority: normal
severity: normal
status: open
title: Apparent memory leak in PC/bdist_wininst/install.c
versions: Python 3.1
Added file: http://bugs.python.org/file18331/install_c.diff

___
Python tracker 
<http://bugs.python.org/issue9456>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com