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
New submission from Blair bidih...@gmail.com:
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
Blair bidih...@gmail.com 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
Blair bidih...@gmail.com 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
Blair bidih...@gmail.com 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
Blair bidih...@gmail.com 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
Blair bidih...@gmail.com 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
New submission from Zachary Blair zachary.bl...@gmail.com:
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
Blair bidih...@gmail.com 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
Blair bidih...@gmail.com 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
Blair bidih...@gmail.com 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
Blair bidih...@gmail.com 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
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
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
14 matches
Mail list logo
