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 beh
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: http://LacusVeris.co
"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
>
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), (lis
"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 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]
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 agr
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 a
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
"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
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
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
[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
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 so
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. Th
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, w
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, __
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 cal
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
19 matches
Mail list logo
