On 1/16/07, Ben Finney [EMAIL PROTECTED] wrote:
BJörn Lindqvist [EMAIL PROTECTED] writes:
import rational
rational.rational(45)
rational.rational(45.0)
rational.rational([45, 45.5])
def rational(obj):
initers = [(int, from_int), (basestring, from_str), (list, from_list)]
BJörn Lindqvist [EMAIL PROTECTED] writes:
On 1/16/07, Ben Finney [EMAIL PROTECTED] wrote:
Use the supplied value as you expect to be able to use it, and
catch the exception (somewhere) if it doesn't work. That will
allow *any* type that exhibits the correct behaviour, without
needlessly
Ben Finney wrote this on Wed, Jan 17, 2007 at 08:27:54PM +1100. My reply is
below.
I recommend, instead, separate factory functions for separate input
types.
Uh, how 'bout separate subclasses for separate input types?
--
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather:
Chuck Rhode [EMAIL PROTECTED] writes:
Ben Finney wrote:
I recommend, instead, separate factory functions for separate
input types.
Uh, how 'bout separate subclasses for separate input types?
The resulting object in each case would be the same type ('Rational'),
with the same behaviour.
On Jan 15, 4:54 pm, Ben Finney [EMAIL PROTECTED]
wrote:
[EMAIL PROTECTED] writes:
Suppose you're writing a class Rational for rational numbers. The
__init__ function of such a class has two quite different roles to
play.
That should be your first clue to question whether you're actually
On Jan 16, 10:25 am, Mark Dickinson [EMAIL PROTECTED] wrote:
that is, I was working from the following two assumptions:
(1) *Every* time a Rational is created, __init__ must eventually be
called, and
(2) The user of the class expects to call Rational() to create
rationals.
(with apologies
On 1/15/07, Ben Finney [EMAIL PROTECTED] wrote:
The alternate constructors are decorated as '@classmethod' since they
won't be called as instance methods, but rather:
foo = Rational.from_string(355/113)
bar = Rational.from_int(17)
baz = Rational.from_rational(foo)
I agree with
On 1/16/07, Steven D'Aprano [EMAIL PROTECTED] wrote:
On Tue, 16 Jan 2007 08:54:09 +1100, Ben Finney wrote:
Think of built-ins like str() and int(). I suggest that people would be
*really* unhappy if we needed to do this:
str.from_int(45)
str.from_float(45.0)
str.from_list([45, 45.5])
etc.
BJörn Lindqvist [EMAIL PROTECTED] writes:
import rational
rational.rational(45)
rational.rational(45.0)
rational.rational([45, 45.5])
def rational(obj):
initers = [(int, from_int), (basestring, from_str), (list, from_list)]
for obj_type, initer in initers:
if
On Jan 14, 7:49 pm, Ziga Seilnacht [EMAIL PROTECTED] wrote:
Mark wrote:[a lot of valid, but long concerns about types that return
an object of their own type from some of their methods]
I think that the best solution is to use an alternative constructor
in your arithmetic methods. That way
On Jan 14, 10:43 pm, Steven D'Aprano
[EMAIL PROTECTED] wrote:
On Sun, 14 Jan 2007 15:32:35 -0800, dickinsm wrote:
(You could include the normalization in __init__, but that's wasteful
Is it really? Have you measured it or are you guessing? Is it more or less
wasteful than any other
[EMAIL PROTECTED] writes:
Suppose you're writing a class Rational for rational numbers. The
__init__ function of such a class has two quite different roles to
play.
That should be your first clue to question whether you're actually
needing separate functions, rather than trying to force one
Steven D'Aprano wrote:
class Rational(object):
def __init__(self, numerator, denominator):
print lots of heavy processing here...
# processing ints, floats, strings, special case arguments,
# blah blah blah...
self.numerator = numerator
On Tue, 16 Jan 2007 08:54:09 +1100, Ben Finney wrote:
[EMAIL PROTECTED] writes:
Suppose you're writing a class Rational for rational numbers. The
__init__ function of such a class has two quite different roles to
play.
That should be your first clue to question whether you're actually
Steven D'Aprano [EMAIL PROTECTED] writes:
On Tue, 16 Jan 2007 08:54:09 +1100, Ben Finney wrote:
def __add__(self, other):
result = perform_addition(self, other)
return result
But that could just as easily be written as:
def __add__(self, other):
Here's an example of a problem that I've recently come up against for
the umpteenth time. It's not difficult to solve, but my previous
solutions have never seemed quite right, so I'm writing to ask whether
others have encountered this problem, and if so what solutions they've
come up with.
Mark wrote:
[a lot of valid, but long concerns about types that return
an object of their own type from some of their methods]
I think that the best solution is to use an alternative constructor
in your arithmetic methods. That way users don't have to learn about
two different factories for the
At Sunday 14/1/2007 20:32, [EMAIL PROTECTED] wrote:
Of course, none of this really has anything to do with rational
numbers. There must be many examples of classes for which internal
calls to __init__, from other methods of the same class, require
minimal argument processing, while external
On Sun, 14 Jan 2007 15:32:35 -0800, dickinsm wrote:
Suppose you're writing a class Rational for rational numbers. The
__init__ function of such a class has two quite different roles to
play. First, it's supposed to allow users of the class to create
Rational instances; in this role,
On Mon, 15 Jan 2007 14:43:55 +1100, Steven D'Aprano wrote:
Of course, none of this really has anything to do with rational
numbers. There must be many examples of classes for which internal
calls to __init__, from other methods of the same class, require
minimal argument processing, while
20 matches
Mail list logo
