On Sun, 17 Jul 2016 06:03 pm, Random832 wrote:
> On Sun, Jul 17, 2016, at 03:51, Chris Angelico wrote:
>> > True, although the programmer has control over the feature. If you
>> > *want* the luxury of exact fractions, you pay the price. If you don't,
>> > you make the numbers inexact.
>>
>> Not i
On Sun, Jul 17, 2016 at 6:08 PM, Random832 wrote:
> On Sun, Jul 17, 2016, at 03:51, Chris Angelico wrote:
>> Currently yes, you can choose to use fractions.Fraction and pay the
>> price. How, if you have a single type with different representations,
>> can you make that choice?
>
> Sorry, I forgot
On Sun, Jul 17, 2016, at 03:51, Chris Angelico wrote:
> Currently yes, you can choose to use fractions.Fraction and pay the
> price. How, if you have a single type with different representations,
> can you make that choice?
Sorry, I forgot to answer your question. Though, your implicit claim
that
On Sun, Jul 17, 2016, at 03:51, Chris Angelico wrote:
> > True, although the programmer has control over the feature. If you
> > *want* the luxury of exact fractions, you pay the price. If you don't,
> > you make the numbers inexact.
>
> Not if you have a single "Number" type:
Saying that exact a
On Sun, Jul 17, 2016 at 5:41 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> The trouble is, repeated addition of fractions is *able* to deliver an
>> exact result. It just might result in an incredibly slow program.
>
> True, although the programmer has control over the feature. If you
> *want*
Chris Angelico :
> The trouble is, repeated addition of fractions is *able* to deliver an
> exact result. It just might result in an incredibly slow program.
True, although the programmer has control over the feature. If you
*want* the luxury of exact fractions, you pay the price. If you don't,
y
On Sun, Jul 17, 2016 at 7:27 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> In that case, an 'Exact' non-integer will have appalling performance -
>> fractions.Fraction doesn't really work all that nicely when the
>> numbers start getting huge.
>
> In Scheme, any math operation is allowed to dr
Chris Angelico :
> In that case, an 'Exact' non-integer will have appalling performance -
> fractions.Fraction doesn't really work all that nicely when the
> numbers start getting huge.
In Scheme, any math operation is allowed to drop exactness:
If one of these procedures is unable to deliver
On Sun, Jul 17, 2016 at 4:04 AM, Random832 wrote:
> On Sat, Jul 16, 2016, at 03:27, Chris Angelico wrote:
>> Will an "Exact" non-integer be stored as Decimal or
>> Fraction? How do you know? They have vastly different semantics, and
>> you should be able to choose.
>
> Er, the point is for them to
Random832 :
> On Sat, Jul 16, 2016, at 03:27, Chris Angelico wrote:
>> Will an "Exact" non-integer be stored as Decimal or
>> Fraction? How do you know? They have vastly different semantics, and
>> you should be able to choose.
>
> Er, the point is for them to _not_ have different semantics. A dec
On Sat, Jul 16, 2016, at 03:27, Chris Angelico wrote:
> Will an "Exact" non-integer be stored as Decimal or
> Fraction? How do you know? They have vastly different semantics, and
> you should be able to choose.
Er, the point is for them to _not_ have different semantics. A decimal
storage format w
Oh, and a further thought...
On Sat, 16 Jul 2016 04:53 pm, Random832 wrote:
> Eliminate both of them. Move to a single abstract numeric type* a la
> Scheme, with an "inexact" attribute (inexact numbers may or may not be
> represented by a float, or by the same bigint/decimal/rational types as
>
On Sat, 16 Jul 2016 04:53 pm, Random832 wrote:
> On Sat, Jul 16, 2016, at 02:29, Chris Angelico wrote:
>> The difference between ints and floats can lead to bugs, too. Which
>> one should we eliminate?
>
> Eliminate both of them. Move to a single abstract numeric type* a la
> Scheme, with an "ine
Chris Angelico :
> With a single abstract numeric type, what exactly does "inexact" mean,
> where does it come from, and how does that affect the expected
> behaviour and performance of numbers?
Not much is said in the standard:
Thus inexactness is a contagious property of a number. If two
On Sat, Jul 16, 2016 at 4:53 PM, Random832 wrote:
> On Sat, Jul 16, 2016, at 02:29, Chris Angelico wrote:
>> The difference between ints and floats can lead to bugs, too. Which
>> one should we eliminate?
>
> Eliminate both of them. Move to a single abstract numeric type* a la
> Scheme, with an "i
On Sat, Jul 16, 2016, at 02:29, Chris Angelico wrote:
> The difference between ints and floats can lead to bugs, too. Which
> one should we eliminate?
Eliminate both of them. Move to a single abstract numeric type* a la
Scheme, with an "inexact" attribute (inexact numbers may or may not be
represe
On Sat, Jul 16, 2016 at 4:19 PM, Lawrence D’Oliveiro
wrote:
> On Saturday, July 16, 2016 at 4:20:13 PM UTC+12, Ethan Furman wrote:
>>
>> On 07/15/2016 09:04 PM, Rustom Mody wrote:
>>
>>> Just that suggesting that python's bool notion is straightforward is an
>>> unnecessary lie – especially to new
On Saturday, July 16, 2016 at 4:20:13 PM UTC+12, Ethan Furman wrote:
>
> On 07/15/2016 09:04 PM, Rustom Mody wrote:
>
>> Just that suggesting that python's bool notion is straightforward is an
>> unnecessary lie – especially to newbies.
>
> Python's boolean concept is as simple as it gets -- what
On Saturday, July 16, 2016 at 9:50:13 AM UTC+5:30, Ethan Furman wrote:
> On 07/15/2016 09:04 PM, Rustom Mody wrote:
>
> > Just that suggesting that python's bool notion is straightforward is an
> > unnecessary lie – especially to newbies.
>
> Python's boolean concept is as simple as it gets -- wh
On 07/15/2016 09:04 PM, Rustom Mody wrote:
Just that suggesting that python's bool notion is straightforward is an
unnecessary lie – especially to newbies.
Python's boolean concept is as simple as it gets -- what is not straightforward
about it?
--
~Ethan~
--
https://mail.python.org/mailman/
On Thursday, July 14, 2016 at 5:24:50 AM UTC+5:30, Peter Otten wrote:
> Lawrence D’Oliveiro wrote:
> > And there are still those who think that Python’s lax acceptance of
> > non-boolean values as booleans is a good idea...
>
> I don't think this particular problem serves as an argument for strict
On Wed, Jul 13, 2016 at 5:54 PM, Peter Otten <[email protected]> wrote:
> Lawrence D’Oliveiro wrote:
>
>> On Friday, July 8, 2016 at 7:38:56 PM UTC+12, Peter Otten wrote:
>>
>>> There is a test
>>>
>>> if not object:
>>> raise ImportError('no Python documentation found for %r' % thing)
>>>
>>> i
Lawrence D’Oliveiro wrote:
> On Friday, July 8, 2016 at 7:38:56 PM UTC+12, Peter Otten wrote:
>
>> There is a test
>>
>> if not object:
>> raise ImportError('no Python documentation found for %r' % thing)
>>
>> in the pydoc module. So all you need is to ensure that your Registry
>> evaluate
On Friday, July 8, 2016 at 7:38:56 PM UTC+12, Peter Otten wrote:
> There is a test
>
> if not object:
> raise ImportError('no Python documentation found for %r' % thing)
>
> in the pydoc module. So all you need is to ensure that your Registry
> evaluates to True in a boolean context, e. g.
On 07/08/2016 09:57 AM, Rob Gaddi wrote:
Michael Selik wrote:
On Jul 7, 2016, at 7:46 PM, Rob Gaddi wrote:
I've got a package that contains a global ensmartened dict that allows
all the various parts of my program to share state.
The simplest solution would be to use a module as your singl
Michael Selik wrote:
>
>
>> On Jul 7, 2016, at 7:46 PM, Rob Gaddi
>> wrote:
>>
>> I've got a package that contains a global ensmartened dict that allows
>> all the various parts of my program to share state.
>
> The simplest solution would be to use a module as your singleton. For
> example, "
Steven D'Aprano wrote:
> On Fri, 8 Jul 2016 05:38 pm, Peter Otten wrote:
>
> [...]
>>> Is this a thing that can be fixed with a commensurate amount of effort?
>>
>> There is a test
>>
>> if not object:
>> raise ImportError('no Python documentation found for %r' % thing)
>>
>> in the pydoc m
On Fri, 8 Jul 2016 05:38 pm, Peter Otten wrote:
[...]
>> Is this a thing that can be fixed with a commensurate amount of effort?
>
> There is a test
>
> if not object:
> raise ImportError('no Python documentation found for %r' % thing)
>
> in the pydoc module. So all you need is to ensure t
On Friday, July 8, 2016 at 1:15:04 PM UTC+5:30, Peter Otten wrote [slightly
edited]
> Peter Otten wrote:
>
> > You might also file a bug report asking to replace
> > if not object: ...
> >
> > with
> >
> >if object is None: ...
>
> I take that back; the problem is fixed in Python 3.5.
Hoo boy!
Peter Otten wrote:
> You might also file a bug report asking to replace
I take that back; the problem is fixed in Python 3.5.
--
https://mail.python.org/mailman/listinfo/python-list
Rob Gaddi wrote:
> I've got a package that contains a global ensmartened dict that allows
> all the various parts of my program to share state. Things like device
> handles, information about the application environment, etc. that are
> inherantly global (i.e. we're not having that debate).
>
>
> On Jul 7, 2016, at 7:46 PM, Rob Gaddi
> wrote:
>
> I've got a package that contains a global ensmartened dict that allows
> all the various parts of my program to share state.
The simplest solution would be to use a module as your singleton. For example,
"registry.py" would work. Pydoc wil
On Fri, 8 Jul 2016 09:46 am, Rob Gaddi wrote:
[...]
> So Registry is now a globally accessible mutable object; no reason to
> complicate things with singletons or borgs or whathave you. From
> within the interactive console, help(foobar.Registry) gives me the
> _Registry documentation as expected.
33 matches
Mail list logo
