"John Roth" <[EMAIL PROTECTED]> writes:
> "Mike Meyer" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Nick Coghlan <[EMAIL PROTECTED]> writes:
>>
>>> Mike Meyer wrote:
Yup. Thank you. This now reads:
Regarding str() and repr() behaviour, repr() will be either
''rat
"Mike Meyer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Nick Coghlan <[EMAIL PROTECTED]> writes:
Mike Meyer wrote:
Yup. Thank you. This now reads:
Regarding str() and repr() behaviour, repr() will be either
''rational(num)'' if the denominator is one, or ''rational(num,
denom)'' i
Title: RE: A Revised Rational Proposal
[Mike Meyer]
#- I don't think so, as I don't see it coming up often enough to warrant
#- implementing. However, Rational("x" / "y") will be an acceptable
#- string format as fallout from accepting floating point string
Skip Montanaro <[EMAIL PROTECTED]> writes:
> Mike> ... or making them old-style classes, which is discouraged.
>
> Since when is use of old-style classes discouraged?
I was under the imperssion that old-style classes were going away, and
hence discouraged for new library modules.
However, a
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Mike Meyer wrote:
>> Yup. Thank you. This now reads:
>> Regarding str() and repr() behaviour, repr() will be either
>> ''rational(num)'' if the denominator is one, or ''rational(num,
>> denom)'' if the denominator is not one. str() will be either ''num''
Skip Montanaro wrote:
Mike> ... or making them old-style classes, which is discouraged.
Since when is use of old-style classes discouraged?
Well, since new-style classes came along, surely? I should have thought
the obvious way to move forward was to only use old-style classes when
their inco
Mike> ... or making them old-style classes, which is discouraged.
Since when is use of old-style classes discouraged?
Skip
--
http://mail.python.org/mailman/listinfo/python-list
Dan Bishop wrote:
Steven Bethard wrote:
Dan Bishop wrote:
Mike Meyer wrote:
PEP: XXX
I'll be the first to volunteer an implementation.
Very cool. Thanks for the quick work!
For stdlib acceptance, I'd suggest a few cosmetic changes:
No problem.
"""Implementation of rational arithmetic."""
[Yards o
Title: RE: A Revised Rational Proposal
[Dan Bishop]
#- * Binary operators with one Rational operand and one float or Decimal
#- operand will not raise a TypeError, but return a float or Decimal.
I think this is a mistake. Rational should never interact with float.
#- * Expressions of
Title: RE: A Revised Rational Proposal
[Dan Bishop]
#- I disagree with raising a TypeError here. If, in mixed-type
#- expressions, we treat ints as a special case of rationals, it's
#- inconsistent for rationals to raise TypeErrors in situations
#- where int
#- doesn't.
I thin
Title: RE: A Revised Rational Proposal
[Mike Meyer]
#- When combined with a floating type - either complex or float - or a
#- decimal type, the result will be a TypeError. The reason for this is
#- that floating point numbers - including complex - and decimals are
#- already imprecise. To
Mike Meyer wrote:
Yup. Thank you. This now reads:
Regarding str() and repr() behaviour, repr() will be either
''rational(num)'' if the denominator is one, or ''rational(num,
denom)'' if the denominator is not one. str() will be either ''num''
if the denominator is one, or ''(num / denom)'' if the d
Mike Meyer wrote:
"John Roth" <[EMAIL PROTECTED]> writes:
I'd suggest making them public rather than either protected or
private. There's a precident with the complex module, where
the real and imaginary parts are exposed as .real and .imag.
This isn't addressed in the PEP, and is an oversight on
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Mike Meyer wrote:
>> Regarding str() and repr() behaviour, Ka-Ping Yee proposes that repr() have
>> the same behaviour as str() and Tim Peters proposes that str() behave like
>> the
>> to-scientific-string operation from the Spec.
>
> This looks like a C
"John Roth" <[EMAIL PROTECTED]> writes:
> I'd suggest making them public rather than either protected or
> private. There's a precident with the complex module, where
> the real and imaginary parts are exposed as .real and .imag.
This isn't addressed in the PEP, and is an oversight on my part. I'
"Dan Bishop" <[EMAIL PROTECTED]> writes:
> Mike Meyer wrote:
>> This version includes the input from various and sundry people.
> Thanks
>> to everyone who contributed.
>>
>>>
>> PEP: XXX
>> Title: A rational number module for Python
> ...
>> Implementation
>> ==
>>
>> There is cur
Dan Bishop wrote:
Mike Meyer wrote:
This version includes the input from various and sundry people.
Thanks
to everyone who contributed.
PEP: XXX
Title: A rational number module for Python
...
Implicit Construction
-
When combined with a floating type - either complex or float
Mike Meyer wrote:
Regarding str() and repr() behaviour, Ka-Ping Yee proposes that repr() have
the same behaviour as str() and Tim Peters proposes that str() behave like the
to-scientific-string operation from the Spec.
This looks like a C & P leftover from the Decimal PEP :)
Otherwise, looks good.
Steven Bethard wrote:
> Dan Bishop wrote:
> > Mike Meyer wrote:
> >>
> >>PEP: XXX
> >
> > I'll be the first to volunteer an implementation.
>
> Very cool. Thanks for the quick work!
>
> For stdlib acceptance, I'd suggest a few cosmetic changes:
No problem.
"""Implementation of rational arithmet
"Steven Bethard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Dan Bishop wrote:
Mike Meyer wrote:
PEP: XXX
I'll be the first to volunteer an implementation.
Very cool. Thanks for the quick work!
For stdlib acceptance, I'd suggest a few cosmetic changes:
Use PEP 257[1] docstring con
Dan Bishop wrote:
Mike Meyer wrote:
PEP: XXX
I'll be the first to volunteer an implementation.
Very cool. Thanks for the quick work!
For stdlib acceptance, I'd suggest a few cosmetic changes:
Use PEP 257[1] docstring conventions, e.g. triple-quoted strings.
Use PEP 8[2] naming conventions, e.g. na
Dan Bishop wrote:
> Mike Meyer wrote:
> > This version includes the input from various and sundry people.
> Thanks
> > to everyone who contributed.
> >
> > >
> > PEP: XXX
> > Title: A rational number module for Python
> ...
> > Implementation
> > ==
> >
> > There is currently a rati
Mike Meyer wrote:
> This version includes the input from various and sundry people.
Thanks
> to everyone who contributed.
>
>
> PEP: XXX
> Title: A rational number module for Python
...
> Implementation
> ==
>
> There is currently a rational module distributed with Python, and a
>
"Dan Bishop" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Mike Meyer wrote:
This version includes the input from various and sundry people.
Thanks
to everyone who contributed.
PEP: XXX
Title: A rational number module for Python
...
Implicit Construction
-
Whe
Mike Meyer wrote:
> This version includes the input from various and sundry people.
Thanks
> to everyone who contributed.
>
>
> PEP: XXX
> Title: A rational number module for Python
...
> Implicit Construction
> -
>
> When combined with a floating type - either complex or fl
25 matches
Mail list logo
