New submission from Noam Raphael noamr...@gmail.com:
Hello,
This bug is the cause of a bug reported about DreamPie:
https://bugs.launchpad.net/bugs/530969
DreamPie (http://dreampie.sourceforge.net) changes sys.displayhook so that
values will be sent to the parent process instead of being
New submission from Noam Raphael noamr...@gmail.com:
Hello,
This is from the current svn:
./python
Python 3.2a0 (py3k:76104, Nov 4 2009, 08:49:44)
[GCC 4.4.1] on linux2
Type help, copyright, credits or license for more information.
try:
... eval(u'שלום')
... except SyntaxError as e
Noam Raphael noamr...@gmail.com added the comment:
Do you mean msg58966?
I'm sorry, I still don't understand what's the problem with returning
f_15(x) if eval(f_15(x)) == x and otherwise returning f_17(x). You said
(msg69232) that you don't care if float(repr(x)) == x isn't
cross-platform
Noam Raphael noamr...@gmail.com added the comment:
I'm sorry, but it seems to me that the conclusion of the discussion in
2008 is that the algorithm should simply use the system's
binary-to-decimal routine, and if the result is like 123.456, round it
to 15 digits after the 0, check if the result
New submission from Noam Raphael [EMAIL PROTECTED]:
Hello,
The documentation of the tokenize module says: The line passed is the
*logical* line; continuation lines are included.
Some background: The tokenize module splits a python source into tokens,
and says for each token where it begins
Noam Raphael added the comment:
I just wanted to say that I'm not going to bother too much with this
right now - Personally I will just use epydoc when I want to create an
HTML documentation. Of course, you can still do whatever you like with
the patch.
Good luck,
Noam
--
nosy: +noam
Noam Raphael added the comment:
I think that we can give up float(repr(x)) == x across different
platforms, since we don't guarantee something more basic: We don't
guarantee that the same program doing only floating point operations
will produce the same results across different 754 platforms
Noam Raphael added the comment:
2007/12/18, Raymond Hettinger [EMAIL PROTECTED]:
The 17 digit representation is useful in that it suggests where the
problem lies. In contrast, showing two numbers with reprs of different
lengths will strongly suggest that the shorter one is exactly
Noam Raphael added the comment:
About the educational problem. If someone is puzzled by 1.1*3 !=
3.3, you could always use '%50f' % 1.1 instead of repr(1.1). I don't
think that trying to teach people that floating points don't always do
what they expect them to do is a good reason to print
Noam Raphael added the comment:
Ok, I think I have a solution!
We don't really need always the shortest decimal representation. We just
want that for most floats which have a nice decimal representation, that
representation will be used.
Why not do something like that:
def newrepr(f):
r
Noam Raphael added the comment:
2007/12/13, Guido van Rossum [EMAIL PROTECTED]:
Ok, so if I understand correctly, the ideal thing would be to
implement decimal to binary conversion by ourselves. This would make
str - float conversion do the same thing on all platforms, and would
make
Noam Raphael added the comment:
Ok, so if I understand correctly, the ideal thing would be to
implement decimal to binary conversion by ourselves. This would make
str - float conversion do the same thing on all platforms, and would
make repr(1.1)=='1.1'. This would also allow us to define
Noam Raphael added the comment:
The Tcl code can be fonund here:
http://tcl.cvs.sourceforge.net/tcl/tcl/generic/tclStrToD.c?view=markup
What Tim says gives another reason for using that code - it means that
currently, the compilation of the same source code on two platforms can
result in a code
Noam Raphael added the comment:
I think that for str(), the current method is better - using the new
repr() method will make str(1.1*3) == '3.3003', instead of
'3.3'. (The repr is right - you can check, and 1.1*3 != 3.3. But for
str() purposes it's fine.)
But I actually think
Noam Raphael added the comment:
If I think about it some more, why not get rid of all the float
platform-dependencies and define how +inf, -inf and nan behave?
I think that it means:
* inf and -inf are legitimate floats just like any other float.
Perhaps there should be a builtin Inf
Noam Raphael added the comment:
That's right, but the standard also defines that 0.0/0 - nan, and
1.0/0 - inf, but instead we raise an exception. It's just that in
Python, every object is expected to be equal to itself. Otherwise, how
can I check if a number is nan
Noam Raphael added the comment:
If I understand correctly, there are two main concerns: speed and
portability. I think that they are both not that terrible.
How about this:
* For IEEE-754 hardware, we implement decimal/binary conversions, and
define the exact behaviour of floats.
* For non-IEEE
Noam Raphael added the comment:
If I were in that situation I would prefer to store the binary
representation. But if someone really needs to store decimal floats,
we can add a method fast_repr which always calculates 17 decimal
digits.
Decimal to binary conversion, in any case, shouldn't
Noam Raphael added the comment:
I don't know, for me it works fine, even after downloading a fresh SVN
copy. On what platform does it happen?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1580
Noam Raphael added the comment:
I also use linux on x86. I think that byte order would cause different
results (the repr of a random float shouldn't be 1.0.)
Does the test case run ok? Because if it does, it's really strange.
--
versions: -Python 2.6
Noam Raphael added the comment:
Oh, this is sad. Now I know why Tcl have implemented also a decimal to
binary routine.
Perhaps we can simply use both their routines? If I am not mistaken,
their only real dependency is on a library which allows arbitrary long
integers, called tommath, from which
Mike Meyer wrote:
[EMAIL PROTECTED] writes:
try:
return a == b
except TypeError:
return a is b
This isn't easy. It's an ugly hack you have to use everytime you
want to iterate through a heterogenous set doing equality tests.
I wouldn't define this as an ugly hack. These are
Mike Meyer wrote:
Noam Raphael [EMAIL PROTECTED] writes:
Also note that using the current behaviour, you can't easily
treat objects that do define a meaningful value comparison, by
identity.
Yes you can. Just use the is operator.
Sorry, I wasn't clear enough. In treating I meant how
Hello,
I want to distribute a package. It's compatible with Python 2.3.
Is there a way to use distutils 2.4 feature package_data, while
maintaining the distribution compatible with python 2.3 ?
Thanks,
Noam Raphael
--
http://mail.python.org/mailman/listinfo/python-list
Fredrik Lundh wrote:
you can enable new metadata fields in older versions by assigning to
the DistributionMetadata structure:
try:
from distutils.dist import DistributionMetadata
DistributionMetadata.package_data = None
except:
pass
setup(
Thanks for your suggestion, but it has several problems which the added
class solves:
* This is a very long code just to write you must implement this
method. Having a standard way to say that is better.
* You can instantiate the base class, which doesn't make sense.
* You must use testing to
Mike Meyer wrote:
That's what DbC languages are for. You write the contracts first, then
the code to fullfill them. And get exceptions when the implementation
doesn't do what the contract claims it does.
mike
Can you give me a name of one of them? This is a very interesting thing
- I
Thank you very much for this answer! I learned from you about unit
tests, and you convinced me that testing oriented programming is a
great way to program.
You made me understand that indeed, proper unit testing solves my
practical problem - how to make sure that all the methods which should
You can always have a thread which continually reads stdin and stores it
in a string, or better, in a cStringIO.StringIO object. Then in the main
thread, you can check whether something new has arrived. This, of course
will work on all platforms.
I hope this helped a bit,
Noam
--
Jp Calderone wrote:
This lets you avoid duplicate test code as well as easily test
new concrete implementations. It's an ideal approach for frameworks
which mandate application-level implementations of a particular
interface and want to ease the application developer's task.
Jp
It's a great
Thank you all, especially Alex for your enlightening discussion, and
Scott for your implementation. I'm sorry that I can't be involved in a
daily manner - but I did read all of the posts in this thread. They
helped me understand the situation better, and convinced me that indeed
this feature
My long post gives all the philosophy, but I'll give here the short answers.
Mike Meyer wrote:
+0
Python doesn't use classes for typing. As Alex Martelli puts it,
Python uses protocols. So the client expecting a concrete subclass of
your abstract class may get an instantiation of a class that
Scott David Daniels wrote:
class Abstract(object):
'''A class to stick anywhere in an inheritance chain'''
__metaclass__ = MustImplement
def notimplemented(method):
'''A decorator for those who prefer the parameters declared.'''
return NotImplemented
I just wanted to say that I
(BaseClass):
def save_data(self, filename):
open(filename).write(self.data)
==
then if I try to instantiate BaseClass I would get an exception, but
instantiating RealClass will be ok.
Well, what do you say?
Noam Raphael
--
http://mail.python.org/mailman/listinfo
34 matches
Mail list logo
