Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #20811 > unrolled thread

PyWart: Language missing maximum constant of numeric types!

Back to article view | Back to comp.lang.python

Contents

  PyWart: Language missing maximum constant of numeric types! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-24 05:37 -0800
    Re: PyWart: Language missing maximum constant of numeric types! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-02-24 13:55 +0000
      Re: PyWart: Language missing maximum constant of numeric types! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-24 06:14 -0800
    Re: PyWart: Language missing maximum constant of numeric types! Neil Cerutti <neilc@norwich.edu> - 2012-02-24 14:25 +0000
      Re: PyWart: Language missing maximum constant of numeric types! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-24 07:25 -0800
      Re: PyWart: Language missing maximum constant of numeric types! Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-02-24 12:32 -0500
      Re: PyWart: Language missing maximum constant of numeric types! Ian Kelly <ian.g.kelly@gmail.com> - 2012-02-24 18:26 -0700
    Re: PyWart: Language missing maximum constant of numeric types! Miki Tebeka <miki.tebeka@gmail.com> - 2012-02-24 06:39 -0800
      Re: PyWart: Language missing maximum constant of numeric types! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-24 07:18 -0800
    Re: PyWart: Language missing maximum constant of numeric types! Mel Wilson <mwilson@the-wire.com> - 2012-02-24 10:21 -0500
      Re: PyWart: Language missing maximum constant of numeric types! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-24 15:31 +0000
      Re: PyWart: Language missing maximum constant of numeric types! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-24 07:34 -0800
        Re: PyWart: Language missing maximum constant of numeric types! Michael Torrie <torriem@gmail.com> - 2012-02-24 09:23 -0700
          Re: PyWart: Language missing maximum constant of numeric types! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-24 22:45 +0000
        Re: PyWart: Language missing maximum constant of numeric types! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-02-24 16:59 +0000
        Re: PyWart: Language missing maximum constant of numeric types! Michael Torrie <torriem@gmail.com> - 2012-02-24 16:16 -0700
        Re: PyWart: Language missing maximum constant of numeric types! Chris Angelico <rosuav@gmail.com> - 2012-02-25 11:09 +1100
        Re: PyWart: Language missing maximum constant of numeric types! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-02-25 00:35 +0000
          Re: PyWart: Language missing maximum constant of numeric types! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-25 12:25 -0800
        Re: PyWart: Language missing maximum constant of numeric types! MRAB <python@mrabarnett.plus.com> - 2012-02-25 00:37 +0000
        Re: PyWart: Language missing maximum constant of numeric types! Serhiy Storchaka <storchaka@gmail.com> - 2012-02-25 17:32 +0200
    Re: PyWart: Language missing maximum constant of numeric types! Fayaz Yusuf Khan <fayaz.yusuf.khan@gmail.com> - 2012-02-25 06:52 +0530
      Re: PyWart: Language missing maximum constant of numeric types! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-25 01:50 +0000
        Re: PyWart: Language missing maximum constant of numeric types! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-25 12:29 -0800
          Re: PyWart: Language missing maximum constant of numeric types! alex23 <wuwei23@gmail.com> - 2012-02-26 18:32 -0800
            Re: PyWart: Language missing maximum constant of numeric types! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-27 03:51 +0000
              Re: PyWart: Language missing maximum constant of numeric types! Chris Angelico <rosuav@gmail.com> - 2012-02-27 14:59 +1100
              Re: PyWart: Language missing maximum constant of numeric types! alex23 <wuwei23@gmail.com> - 2012-02-26 22:49 -0800
    Re: PyWart: Language missing maximum constant of numeric types! Wolfgang Meiners <WolfgangMeiners01@web.de> - 2012-02-25 09:18 +0100
      Re: PyWart: Language missing maximum constant of numeric types! MRAB <python@mrabarnett.plus.com> - 2012-02-25 17:54 +0000
        Re: PyWart: Language missing maximum constant of numeric types! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-25 12:35 -0800
          Re: PyWart: Language missing maximum constant of numeric types! Wolfgang Meiners <WolfgangMeiners01@web.de> - 2012-02-26 14:16 +0100
            Re: PyWart: Language missing maximum constant of numeric types! Wolfgang Meiners <WolfgangMeiners01@web.de> - 2012-02-26 14:38 +0100
              Re: PyWart: Language missing maximum constant of numeric types! Arnaud Delobelle <arnodel@gmail.com> - 2012-02-26 13:44 +0000
            Re: PyWart: Language missing maximum constant of numeric types! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-26 13:50 +0000
            Re: PyWart: Language missing maximum constant of numeric types! Neil Cerutti <neilc@norwich.edu> - 2012-02-27 12:25 +0000
          Re: PyWart: Language missing maximum constant of numeric types! Jean-Michel Pichavant <jeanmichel@sequans.com> - 2012-02-27 12:55 +0100
        Re: PyWart: Language missing maximum constant of numeric types! Wolfgang Meiners <WolfgangMeiners01@web.de> - 2012-02-26 12:56 +0100
          Re: PyWart: Language missing maximum constant of numeric types! Chris Angelico <rosuav@gmail.com> - 2012-02-26 23:52 +1100
            Re: PyWart: Language missing maximum constant of numeric types! Wolfgang Meiners <WolfgangMeiners01@web.de> - 2012-02-26 14:32 +0100
          Re: PyWart: Language missing maximum constant of numeric types! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-26 13:19 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#20857

25.02.12 02:37, MRAB написав(ла):
> We already have arbitrarily long ints, so there could be a special
> infinite int singleton (actually, 2 of them, one positive, the other
> negative).

float('inf') and float('-inf').

[toc] | [prev] | [next] | [standalone]

#20846

[Multipart message — attachments visible in raw view] — view raw

On Saturday 25 Feb 2012 12:37:58 AM MRAB wrote:
> We already have arbitrarily long ints, so there could be a special
> infinite int singleton (actually, 2 of them, one positive, the other
> negative).
Seconded. Although would a wish request to bugs.python.org saying "Allow 
storage of the integer infinity" make any sense to the developers? :P
-- 
Fayaz Yusuf Khan
Cloud developer and architect
Dexetra SS, Bangalore, India
fayaz.yusuf.khan_AT_gmail_DOT_com
fayaz_AT_dexetra_DOT_com
+91-9746-830-823

[toc] | [prev] | [next] | [standalone]

#20850

On Sat, 25 Feb 2012 06:52:09 +0530, Fayaz Yusuf Khan wrote:

> On Saturday 25 Feb 2012 12:37:58 AM MRAB wrote:
>> We already have arbitrarily long ints, so there could be a special
>> infinite int singleton (actually, 2 of them, one positive, the other
>> negative).
> Seconded. Although would a wish request to bugs.python.org saying "Allow
> storage of the integer infinity" make any sense to the developers? :P

If you explained it as a pair of special int values, INF and -INF, rather 
than the storage of an infinite-sized integer, it would make perfect 
sense.

But it would also be rejected, and rightly so, as unnecessary complexity 
for the int type. There are already Decimal and float infinities, just 
use one of them. Or make your own, it's not difficult. Publish it on 
ActiveState, and if people flock to use it, then you will have a good 
argument that this is useful and should be part of the Python built-ins.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#20864

On Feb 24, 7:50 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:

> But it would also be rejected, and rightly so, as unnecessary complexity
> for the int type. There are already Decimal and float infinities, just
> use one of them.

Sure there are float INFINITIES that work fine for ints and floats,
but where is the consistency? INFINITY need not be a int or a float or
a str, or whatever. All it need be is a an object who always returns
itself as being larger in any comparison.

> Or make your own, it's not difficult.

INFINITY should be at the very least a constant of the math module.

[toc] | [prev] | [next] | [standalone]

#20918

On Feb 26, 6:29 am, Rick Johnson <rantingrickjohn...@gmail.com> wrote:
> Sure there are float INFINITIES that work fine for ints and floats,
> but where is the consistency?

Sure, there are all of the COMPLEXITIES of floating point arithmetic
but I want to ignore all of that and demand ridiculous consistencies.
Why should I have to do float(some_int) < float('inf') when it's a far
better use of my time to spend days if not weeks bemoaning yet another
language wart? Why should I be expected to know what float('inf')
actually represents before making stupid demands like:

> INFINITY need not be a int or a float or
> a str, or whatever.

Please provide a non-contrived use case of an "infinite string".

> INFINITY should be at the very least a constant of the math module.

Why? This isn't a mathematical concept of 'infinite' when you're
talking about comparing against "str, or whatever". We need a more
appropriate location; please initiate a PEP to add the namespace
shit.rick.wants into the stdlib.

[toc] | [prev] | [next] | [standalone]

#20921

On Sun, 26 Feb 2012 18:32:27 -0800, alex23 wrote:

> On Feb 26, 6:29 am, Rick Johnson <rantingrickjohn...@gmail.com> wrote:
>> Sure there are float INFINITIES that work fine for ints and floats, but
>> where is the consistency?
> 
> Sure, there are all of the COMPLEXITIES of floating point arithmetic but
> I want to ignore all of that and demand ridiculous consistencies. Why
> should I have to do float(some_int) < float('inf') 

Ints and floats can be compared directly, no need to convert the int to a 
float first:

>>> INF = float('inf')
>>> 23 < INF
True


Likewise Fractions and Decimals, at least in Python 3.2 (possibly not in 
older versions):

>>> from fractions import Fraction
>>> from decimal import Decimal
>>> Fraction(33, 5) < INF
True
>>> Decimal("42.1568") < INF
True



> when it's a far
> better use of my time to spend days if not weeks bemoaning yet another
> language wart? Why should I be expected to know what float('inf')
> actually represents before making stupid demands like:
> 
>> INFINITY need not be a int or a float or a str, or whatever.
> 
> Please provide a non-contrived use case of an "infinite string".

Any lazy stream of characters that potentially goes on forever could be 
considered an infinite string. But that's not what Rick is talking about.

He's talking about having a pair of special values, say, BIGGEST and 
SMALLEST, which compare larger and smaller to any other value, regardless 
of type and including strings, not literally a string with an infinite 
number of characters.

I can see some value for this as a convenience, but not enough to make it 
a built-in language feature. Every developer should have at least one 
utility module with all the trivial code snippets they frequently use. 
This belongs in there.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#20922

On Mon, Feb 27, 2012 at 2:51 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> I can see some value for this as a convenience, but not enough to make it
> a built-in language feature. Every developer should have at least one
> utility module with all the trivial code snippets they frequently use.

+1. I used to call mine "oddsends" - it nicely fitted into eight
characters (yeah, was important then - I was on DOS), and I had quite
a few odds and ends in there.

ChrisA

[toc] | [prev] | [next] | [standalone]

#20924

On Feb 27, 1:51 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> Ints and floats can be compared directly, no need to convert the int to a
> float first

Ah, cheers. You can see how often I use the two interchangeably :)

> > Please provide a non-contrived use case of an "infinite string".
>
> Any lazy stream of characters that potentially goes on forever could be
> considered an infinite string. But that's not what Rick is talking about.
>
> He's talking about having a pair of special values, say, BIGGEST and
> SMALLEST, which compare larger and smaller to any other value, regardless
> of type and including strings, not literally a string with an infinite
> number of characters.

Yeah, my point was more to highlight Rick's laziness in co-opting a
defined term - INFINITE - and trying to use it to mean something else
that he couldn't express clearly. His original post stressed numeric
comparison, the feature creep to include all other types happened
later. Not the sort of thing we've come to expect from the resident
linguist extraordinaire :)

> I can see some value for this as a convenience, but not enough to make it
> a built-in language feature.

For me, it feels like a step backwards to comparing different types:

	>>> 1 < INFINITE
	True
	>>> 'string' < INFINITE
	True
	>>> 1 < 'string'
	Traceback (most recent call last):
	  File "<stdin>", line 1, in <module>
	TypeError: unorderable types: int() < str()

> Every developer should have at least one
> utility module with all the trivial code snippets they frequently use.
> This belongs in there.

Agreed. Especially when it's so trivial:

	class Bound(object):
		def __init__(self, value=None, always_greater=False):
			self.value = value
			self.always_greater = always_greater

		def __cmp__(self, other):
			return True if self.always_greater else self.value.__cmp__(other)

	>>> upper = Bound(100)
	>>> 101 > upper
	True
	>>> 101 < upper
	False
	>>> infinite = Bound(always_greater=True)
	>>> 101 > infinite
	False
	>>> 101 < infinite
	True
	>>> upper < 101 < infinite
	True

[toc] | [prev] | [next] | [standalone]

#20853

Am 24.02.12 14:37, schrieb Rick Johnson:
> I get sick and tired of doing this!!!
> 
> if maxlength == UNLIMITED:
>     allow_passage()
> elif len(string) > maxlength:
>     deny_passage()
> 
> What Python needs is some constant that can be compared to ANY numeric
> type and that constant will ALWAYS be larger!
> 
> 
> 
If there is no limit for len(string), why not simply use

# get_limit() returns None if there is no limit
maxlength = get_limit()
if maxlength and (len(string) <= maxlength):
    allow_passage()
else:
    deny_passage()

Wolfgang

[toc] | [prev] | [next] | [standalone]

#20858

On 25/02/2012 08:18, Wolfgang Meiners wrote:
> Am 24.02.12 14:37, schrieb Rick Johnson:
>>  I get sick and tired of doing this!!!
>>
>>  if maxlength == UNLIMITED:
>>      allow_passage()
>>  elif len(string)>  maxlength:
>>      deny_passage()
>>
>>  What Python needs is some constant that can be compared to ANY numeric
>>  type and that constant will ALWAYS be larger!
>>
>>
>>
> If there is no limit for len(string), why not simply use
>
> # get_limit() returns None if there is no limit
> maxlength = get_limit()
> if maxlength and (len(string)<= maxlength):
>      allow_passage()
> else:
>      deny_passage()
>
That should be:

if maxlength is not None and len(string) <= maxlength:

[toc] | [prev] | [next] | [standalone]

#20863

On Feb 25, 11:54 am, MRAB <pyt...@mrabarnett.plus.com> wrote:
> [...]
> That should be:
> if maxlength is not None and len(string) <= maxlength:

Using "imaginary" infinity values defiles the intuitive nature of your
code. What is more intuitive?

def confine_length(string, maxlength=INFINITY):
    if string.length < maxlength:
        do_something()

def confine_length(string, maxlength=None):
    if maxlength is not None and len(string) <= maxlength:
        do_something()

[toc] | [prev] | [next] | [standalone]

#20897

Am 25.02.12 21:35, schrieb Rick Johnson:
> On Feb 25, 11:54 am, MRAB <pyt...@mrabarnett.plus.com> wrote:
>> [...]
>> That should be:
>> if maxlength is not None and len(string) <= maxlength:
> 
> Using "imaginary" infinity values defiles the intuitive nature of your
> code. What is more intuitive?
> 
> def confine_length(string, maxlength=INFINITY):
>     if string.length < maxlength:
>         do_something()
> 
> def confine_length(string, maxlength=None):
>     if maxlength is not None and len(string) <= maxlength:
>         do_something()

I just had a closer look at it. It seems to be more complicated than i
thougth: You will have to write

def confine_length(string, maxlength=None):
    if maxlength: # maxlength exists, comparison possible
        if len(string) <= maxlength:
            do_something()
    else: # maxlength does not exist, so always do something
        do_something()

you migth also write

def confine_length(str, maxlength=None):
    do_it = (len(str) <= maxlength) if maxlength else True
    if do_it:
        do_something()

but it really does not look intuitive. Hmm. My idea was that None is a
perfect Value for infinity since there is no infinitely large number.
But as i see it, you must have two comparisons then. Maybe someone has a
better idea?

Wolfgang

[toc] | [prev] | [next] | [standalone]

#20900

Am 26.02.12 14:16, schrieb Wolfgang Meiners:
> 
> I just had a closer look at it. It seems to be more complicated than i
> thougth: You will have to write

Obviously not close enough, as i just learned.

> 
> def confine_length(string, maxlength=None):
>     if maxlength: # maxlength exists, comparison possible
      if maxlength is not None: # maxlength exists, comparison possible
>         if len(string) <= maxlength:
>             do_something()
>     else: # maxlength does not exist, so always do something
>         do_something()
> 
> you migth also write
> 
> def confine_length(str, maxlength=None):
>     do_it = (len(str) <= maxlength) if maxlength else True
      do_it = (len(str) <= maxlength) if maxlength is not None else True
>     if do_it:
>         do_something()
> 

I hope, it's correct now.
Wolfgang

[toc] | [prev] | [next] | [standalone]

#20902

On 26 February 2012 13:38, Wolfgang Meiners <WolfgangMeiners01@web.de> wrote:
>      do_it = (len(str) <= maxlength) if maxlength is not None else True

That's a funny way to spell:

    do_it = maxlength is None or len(str) <= maxlength

-- 
Arnaud

[toc] | [prev] | [next] | [standalone]

#20903

On Sun, 26 Feb 2012 14:16:24 +0100, Wolfgang Meiners wrote:

> I just had a closer look at it. It seems to be more complicated than i
> thougth: You will have to write
> 
> def confine_length(string, maxlength=None):
>     if maxlength: # maxlength exists, comparison possible
>         if len(string) <= maxlength:
>             do_something()
>     else: # maxlength does not exist, so always do something
>         do_something()

No, that still takes the wrong branch for maxlength = 0.

Be explicit in your code. If you want maxlength=None to be a sentinel for 
"avoid the length test", then explicitly test for maxlength is None, 
don't be tempted to take short-cuts that can fail.

def confine_length(string, maxlength=None):
    if maxlength is None:  # no length comparison needed
        do_something()
    elif len(string) <= maxlength:
        do_something()


This can be simplified to:

def confine_length(string, maxlength=None):
    if maxlength is None or len(string) <= maxlength:
        do_something()


Or even simpler:

def confine_length(string, maxlength=float('inf')):
    if len(string) <= maxlength:
        do_something()


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#20934

On 2012-02-26, Wolfgang Meiners <WolfgangMeiners01@web.de> wrote:
> but it really does not look intuitive. Hmm. My idea was that
> None is a perfect Value for infinity since there is no
> infinitely large number. But as i see it, you must have two
> comparisons then. Maybe someone has a better idea?

I do. A truncated string with a maxlength of INFINITY is just a
string.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#20933

Rick Johnson wrote:
> On Feb 25, 11:54 am, MRAB <pyt...@mrabarnett.plus.com> wrote:
>   
>> [...]
>> That should be:
>> if maxlength is not None and len(string) <= maxlength:
>>     
>
> Using "imaginary" infinity values defiles the intuitive nature of your
> code. What is more intuitive?
>
> def confine_length(string, maxlength=INFINITY):
>     if string.length < maxlength:
>         do_something()
>
> def confine_length(string, maxlength=None):
>     if maxlength is not None and len(string) <= maxlength:
>         do_something()
>   
This one:

def confine_length(string, maxlength=None):
    """Confine the length.

    @param maxlength: the maximum length allowed, set it to None to allow any length.
    """
    if maxlength is not None and len(string) <= maxlength:
        do_something()


I'm just feeding the troll, I know ... :-/

JM

[toc] | [prev] | [next] | [standalone]

#20888

Am 25.02.12 18:54, schrieb MRAB:
>> If there is no limit for len(string), why not simply use
>>
>> # get_limit() returns None if there is no limit
>> maxlength = get_limit()
>> if maxlength and (len(string)<= maxlength):
>>      allow_passage()
>> else:
>>      deny_passage()
>>
> That should be:
> 
> if maxlength is not None and len(string) <= maxlength:

Take a look at

http://docs.python.org/library/stdtypes.html

where  you can read:
=========================================================================
Any object can be tested for truth value, for use in an if or while
condition or as operand of the Boolean operations below. The following
values are considered false:


      None

      False

      zero of any numeric type, for example, 0, 0L, 0.0, 0j.

      any empty sequence, for example, '', (), [].

      any empty mapping, for example, {}.

      instances of user-defined classes, if the class defines
      __nonzero__() or __len__() method, when that method returns the
      integer zero or bool value False. [1]

All other values are considered true — so objects of many types are
always true.
==========================================================================

That means:
if maxlength and (len(string) <= maxlength):

is equivalent to
if (maxlength is not None) and (len(string) <= maxlength):

which is more complicated to type and -in my opinion- not so intuitive.
But because it is equivalent, it is a matter of taste, what to use.

Wolfgang

[toc] | [prev] | [next] | [standalone]

#20893

On Sun, Feb 26, 2012 at 10:56 PM, Wolfgang Meiners
<WolfgangMeiners01@web.de> wrote:
> That means:
> if maxlength and (len(string) <= maxlength):
>
> is equivalent to
> if (maxlength is not None) and (len(string) <= maxlength):

On the contrary, it means they are distinctly NOT equivalent. The
shorter form would treat a maximum length of 0 as meaning "unlimited".
Now, that's an understandable notation, but it's not what's given
here; if None means unlimited, then 0 should enforce that string ==
"".

ChrisA

[toc] | [prev] | [next] | [standalone]

#20899

Am 26.02.12 13:52, schrieb Chris Angelico:
> On Sun, Feb 26, 2012 at 10:56 PM, Wolfgang Meiners
> <WolfgangMeiners01@web.de> wrote:
>> That means:
>> if maxlength and (len(string) <= maxlength):
>>
>> is equivalent to
>> if (maxlength is not None) and (len(string) <= maxlength):
> 
> On the contrary, it means they are distinctly NOT equivalent. The
> shorter form would treat a maximum length of 0 as meaning "unlimited".
> Now, that's an understandable notation, but it's not what's given
> here; if None means unlimited, then 0 should enforce that string ==
> "".
> 
> ChrisA

You are right. It seems I did not get the line
    zero of any numeric type, for example, 0, 0L, 0.0, 0j.
right.

Wolfgang

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web