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

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

Re: Implicit conversion to boolean in if and while statements

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-07 22:16 -0800
    Re: Implicit conversion to boolean in if and while statements Michael Torrie <torriem@gmail.com> - 2013-02-07 23:27 -0700
      Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-07 22:32 -0800
      Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-07 22:32 -0800
    Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-09 02:16 +1100
      Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-08 09:48 -0800
        Re: Implicit conversion to boolean in if and while statements Roy Smith <roy@panix.com> - 2013-02-08 12:58 -0500
        Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-08 11:58 -0800
          Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-09 11:05 +1100
            Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-08 16:49 -0800
              Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-09 12:17 +1100
                Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-09 20:54 -0800
                  Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-10 16:04 +1100
                    Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 04:28 -0800
                      Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-11 23:50 +1100
                        Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 05:28 -0800
                          Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-12 00:52 +1100
                            Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 20:24 -0800
                            Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 20:24 -0800
                        Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 05:28 -0800
                    Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 04:28 -0800
                Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-09 20:54 -0800
              Re: Implicit conversion to boolean in if and while statements Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-08 18:29 -0700
              Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-09 16:01 +1100
                Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-09 20:26 -0800
                  Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-10 15:50 +1100
                    Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 18:09 -0800
                    Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 18:09 -0800
                  Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-10 22:37 +1100
                    Re: Implicit conversion to boolean in if and while statements Roy Smith <roy@panix.com> - 2013-02-10 09:45 -0500
                    Re: Implicit conversion to boolean in if and while statements Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2013-02-10 18:06 +0100
                    Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 04:18 -0800
                      Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-11 23:40 +1100
                        Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 05:13 -0800
                          Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-12 00:35 +1100
                            Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 20:00 -0800
                            Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 20:00 -0800
                          Re: Implicit conversion to boolean in if and while statements 88888 Dihedral <dihedral88888@googlemail.com> - 2013-02-11 17:06 -0800
                            Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-12 16:55 +1100
                              Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-12 09:48 -0800
                                Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-13 08:24 +1100
                                Re: Implicit conversion to boolean in if and while statements 88888 Dihedral <dihedral88888@googlemail.com> - 2013-02-12 18:43 -0800
                                Re: Implicit conversion to boolean in if and while statements 88888 Dihedral <dihedral88888@googlemail.com> - 2013-02-12 18:43 -0800
                                Re: Implicit conversion to boolean in if and while statements Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-15 13:12 -0700
                                Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2013-02-16 11:12 +1100
                              Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-12 09:48 -0800
                          Re: Implicit conversion to boolean in if and while statements 88888 Dihedral <dihedral88888@googlemail.com> - 2013-02-11 17:06 -0800
                        Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 05:13 -0800
                    Re: Implicit conversion to boolean in if and while statements Serhiy Storchaka <storchaka@gmail.com> - 2013-02-15 21:09 +0200
                Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-09 20:26 -0800
            Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-08 16:49 -0800
          Re: Implicit conversion to boolean in if and while statements Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-08 18:06 -0700
            Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-09 22:25 -0800
            Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-09 22:25 -0800
        Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-09 14:16 +1100
          Re: Implicit conversion to boolean in if and while statements Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-09 15:36 -0500
        Re: Implicit conversion to boolean in if and while statements Mark Janssen <dreamingforward@gmail.com> - 2013-02-11 21:12 -0800

Page 1 of 3  [1] 2 3  Next page →

#38413 — Re: Implicit conversion to boolean in if and while statements

On Monday, July 16, 2012 11:18:28 PM UTC-5, Devin Jeanpierre wrote:
> On Mon, Jul 16, 2012 at 12:03 AM, Steven D'Aprano wrote:
> > On Sun, 15 Jul 2012 22:15:13 -0400, Devin Jeanpierre wrote:
> >
> >> For example, instead of "if stack:" or "if bool(stack):", we could use
> >> "if stack.isempty():". This line tells us explicitly that stack is a
> >> container.
> >
> > isempty is not a container method.
> 
> Your entire reply is predicated on this idea that I was talking about
> writing classes with this extra "isempty" method.

Steven's adherence to this implicit conversion is warping his comprehension of your words. He is so accustomed to "guessing" that it has become second nature for him.

> No. I was talking about having "isempty" be part of the collection
> interface, and eliminating polymorphic bool conversion.

Which i believe is a great idea! 

GvR has always been reluctant to incorporate full OOP machinery for some reason. I am not suggesting that Python be 100% OOP, HELL NO! But collections should have had an "isempty" method from the beginning. But the same argument could be made against len, any, all, etc...

But now we are opening a whole bag of cats. What about hasattr, getattr, setattr, type, dir, id, isinstance, issubclass, and many more that could be inherited directly from object; and they should be!

On the flip side i do believe int, float, str, tuple, list, dict... should remain as built-ins, and the obvious: help, input, globals, locals, vars, print, etc... 

Python has too many built-ins. I think we need a PyWart on this subject.

[toc] | [next] | [standalone]

#38419

On 02/07/2013 11:16 PM, Rick Johnson wrote:
> He is so accustomed to "guessing" that it has become second nature
> for him.

I think most of us are guessing as to what you're talking about since
you're responding to a 7 month old thread that I think most people have
long since deleted from their e-mail or nntp readers.

Gotta hand it to you, though.  It's working.

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

#38423

On Friday, February 8, 2013 12:27:09 AM UTC-6, Michael Torrie wrote:
> On 02/07/2013 11:16 PM, Rick Johnson wrote:
> > He is so accustomed to "guessing" that it has become second nature
> > for him.
> 
> I think most of us are guessing as to what you're talking about since
> you're responding to a 7 month old thread that I think most people have
> long since deleted from their e-mail or nntp readers.

Well i know this thread is quite old however i never got a chance to provide a response due to heavy work loads. I feel this subject is very important for the python language, hence my late replies.

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

#38424

On Friday, February 8, 2013 12:27:09 AM UTC-6, Michael Torrie wrote:
> On 02/07/2013 11:16 PM, Rick Johnson wrote:
> > He is so accustomed to "guessing" that it has become second nature
> > for him.
> 
> I think most of us are guessing as to what you're talking about since
> you're responding to a 7 month old thread that I think most people have
> long since deleted from their e-mail or nntp readers.

Well i know this thread is quite old however i never got a chance to provide a response due to heavy work loads. I feel this subject is very important for the python language, hence my late replies.

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

#38459

Rick Johnson wrote:

> GvR has always been reluctant to incorporate full OOP machinery for some
> reason.

Python is a fully object oriented language. It is *more* object oriented
than, say, Java.

- everything in Python is an object, there is no distinction between "boxed"
and "unboxed" variables;

- modules are objects;

- functions and methods are objects;

- classes are objects in Python, and have their own class (the metaclass);

- metaclasses themselves are also objects, and have classes of their own;

- it's objects all the way down, at least until you reach "type" itself,
which is bootstrapped into existence by the compiler.


Although Python is fully object-oriented, it does not insist on one
particular style of object syntax. It allows procedural and functional
style syntax as well.


> I am not suggesting that Python be 100% OOP, HELL NO! But 
> collections should have had an "isempty" method from the beginning. But
> the same argument could be made against len, any, all, etc...

No they shouldn't.

http://effbot.org/pyfaq/why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list.htm

http://lucumr.pocoo.org/2011/7/9/python-and-pola/

http://mail.python.org/pipermail/python-dev/2008-January/076612.html


Python functions operate as *protocols*. any() and all(), for example, are
excellent examples of why your suggestion fails: the principle of "Don't
Repeat Yourself".

In Python today, any() and all() will work perfectly on ANY ITERABLE OBJECT,
for free. The developer of that object doesn't need to do anything to
support any() and all(), all she has to do is make it iterable.

Under your suggestion, every iterable object has to implement an any()
method, and an all() method. Every iterable type has to repeat the same old
code as every other iterable type. 

class list:
    def any(self):
        for x in self:
            if x: return True
        return False

class dict:
    def any(self):
        for x in self:
            if x: return True
        return False

class set:
    def any(self):
        for x in self:
            if x: return True
        return False

class MyFancyIterableThatIsRealCool:
    # Wow, deja vu... 
    def any(self):
        for x in self:
            if x: return True
        return False


See all the pointlessly duplicated code? Now each one needs tests, and
documentation, and the amount of duplication goes through the roof.

Now, a developer of merely average intelligence will see all that duplicated
code, and factor it out into a global function (two actually, one for
any(), one for all()):

def any(iterable):
    # Write this once. Test it once. Document it once.
    for x in iterable:
        if x: return True
    return False

class list:
    # Gotta have a method, or Rick will cry.
    def any(self):
        return any(self)

class dict:
    def any(self):
        return any(self)

class set:
    def any(self):
        return any(self)

class MyFancyIterableThatIsRealCool:
    # This code seems trivial, and familiar... 
    def any(self):
        return any(self)


But a developer of above average intelligence will recognise that all those
x.any() boilerplate methods are *pointless and stupid*, since you have a
function that does everything you need, for every possible iterator, for
free. All you need do is use any(obj) syntax instead of obj.any() syntax,
which also saves one keystroke.

And a *really* smart language designer will have realised this ahead of
time, and designed the language to encourage the use of protocols like
this, instead of insisting on the slavish application of obj.method syntax.




-- 
Steven

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

#38469

On Friday, February 8, 2013 9:16:42 AM UTC-6, Steven D'Aprano wrote:
> Rick Johnson wrote:
>
> > GvR has always been reluctant to incorporate full OOP machinery for some
> > reason.
>
> Python is a fully object oriented language. It is *more* object oriented
> than, say, Java.

Oh really? *chuckles*

> - everything in Python is an object, there is no distinction between "boxed"
> and "unboxed" variables;

Just because /everything/ in Python is an object does not mean that Python is 100% OOP. This fact is just one of the many attributes of a 100% OOP language. Yes, Python allows OOP style, but python is NOT 100% OOP! Ruby on the other hand /is/ 100% OOP. Although it has identity issues like Python. Ruby thinks it's multi-paridigm and Python thinks it's a good example of OOP. Neither are correct.

> - modules are objects;
>
> - functions and methods are objects;
>
> - classes are objects in Python, and have their own class (the metaclass);
>
> - metaclasses themselves are also objects, and have classes of their own;
>
> - it's objects all the way down, at least until you reach "type" itself,
> which is bootstrapped into existence by the compiler.
>
>
> Although Python is fully object-oriented, it does not insist on one
> particular style of object syntax. It allows procedural and functional
> style syntax as well.

Well you just defeated yourself. How can Python be 100% OOP and then allow other paradigms? 

> > I am not suggesting that Python be 100% OOP, HELL NO! But
> > collections should have had an "isempty" method from the beginning. But
> > the same argument could be made against len, any, all, etc...
> 
> No they shouldn't.
> 
> [...]
> 
> Python functions operate as *protocols*. any() and all(), for example, are
> excellent examples of why your suggestion fails: the principle of "Don't
> Repeat Yourself".
> 
> In Python today, any() and all() will work perfectly on ANY ITERABLE OBJECT,
> for free. The developer of that object doesn't need to do anything to
> support any() and all(), all she has to do is make it iterable.
> 
> Under your suggestion, every iterable object has to implement an any()
> method, and an all() method. Every iterable type has to repeat the same old
> code as every other iterable type.

NOT IF PYTHON WERE TRULY 100% OOP! 

If so, Python would have a supertype called "Collection" that wold define all methods that operate on collections. Some of these include:

 len, any, all, length, isempty, __getitem__, __setitem__, etc...
 
Then any collection subtype would inherit from this supertype and get the methods for free.

> 
> [...]
> See all the pointlessly duplicated code? Now each one needs tests, and
> documentation, and the amount of duplication goes through the roof.
>
> Now, a developer of merely average intelligence will see all that duplicated
> code, and factor it out into a global function (two actually, one for
> any(), one for all()):

Only if that developer does not understand sub-typing! All he has to do is write the method ONE TIME in a super-type, and then inherit the method into ANY number of sub-types for free. Now, if he wants to pervert the usage of a method to fit some niche, THEN he will need to overload the method and provide proper return value.

> But a developer of above average intelligence will recognise that all those
> x.any() boilerplate methods are *pointless and stupid*, since you have a
> function that does everything you need, for every possible iterator, for
> free. All you need do is use any(obj) syntax instead of obj.any() syntax,
> which also saves one keystroke.
>
> And a *really* smart language designer will have realised this ahead of
> time, and designed the language to encourage the use of protocols like
> this, instead of insisting on the slavish application of obj.method syntax.

Using built-in functions to operate on objects is foolish because you are placing extra burden on the programmer to know which /functions/ work with which /types/. The *only* functions that should be global are the kind that will work on *ANY* object. But then again, the Object type could hold these methods!

len, all, and any (just to name a few) only work for collections types and as such should be methods of these types. The global functions:
  
  sum, len, any, all, enumerate, map, max, min, reversed, sorted, zip
  
can only be applied to sequence types, or subtypes of a sequence type. So using a /real/ OOP paridigm we would do the following:

## START TRUE OOP PARIDIGM ##

class Object(SuperType):
    def __class__
    def __delattr__
    def __doc__
    def __format__
    def __getattribute__
    def __init__
    def __new__
    def __repr__
    def __setattr__
    def __sizeof__
    def __str__
    def __subclasshook__
    def true? # aka: bool
    def callable?
    def compare(other)
    def dir
    def hash
    def help
    def id
    def isinstance?(Type)
    def issubclass?(Type)
    def super
    def type

class SequenceBase(Object):
    # Methods from object are free
    def __add__
    def __contains__
    def __delattr__
    def __delitem__
    def __delslice__
    def __eq__
    def __ge__
    def __getitem__
    def __getslice__
    def __gt__
    def __iadd__
    def __imul__
    def __iter__
    def __le__
    def __lt__
    def __mul__
    def __ne__
    def __reduce_ex__
    def __rmul__
    def __setitem__
    def __setslice__
    def __subclasshook__
    #
    # Interface
    #
    def iterator
    def length
    def sum
    def any
    def all
    def enumerate
    def filter(proc)
    def frozenset
    def map
    def max
    def min
    def reverse
    def reduce(proc)
    def slice
    def sort
    def zip
    

class MySequencyThing(SequenceBase):
    # do something here
    

class List(SequenceBase):
    # Methods from SequenceBase and Object are free!
    #
    # Interface
    #
    def append
    def count
    def extend
    def index
    def insert
    def pop
    def remove
    def reverse
    def sort
    

class MyListyThing(List):
    # do something here

## END TRUE OOP PARIDIGM ##

You see, 100% OOP uses encapsulation, inheritance, sub-typing, etc, etc... But most fundamental to OOP is interface (methods belonging to objects), not global functions applied to objects in some haphazard fashion that some self-appointed dictator pull from his backside due to his fear of true OOP style!

Python is not 100% OOP. Heck you cannot fairly apply a specific percentage level because Python's level of OOP is defined by each user of the language. The best way to describe Python is as promiscuous language who secretly longs to be 100% OOP, and to fulfill this fantasy it cross-dresses in OOP lingerie on the weekends.

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

#38471

In article <ee71b775-b527-4bb3-a080-12aad962b0ba@googlegroups.com>,
 Rick Johnson <rantingrickjohnson@gmail.com> wrote:

>  The best way to describe Python is as promiscuous language who secretly 
>  longs to be 100% OOP, and to fulfill this fantasy it cross-dresses in OOP 
>  lingerie on the weekends.

+1 QOTD :-)

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

#38476

On Friday, February 8, 2013 11:48:43 AM UTC-6, Rick Johnson wrote:
>
> [...] 
> 
> So using a /real/ OOP paridigm we would do the following:
> 
> ## START TRUE OOP PARIDIGM ##
> 
> [...snip naive example...]

Actually my example API is littered with artifacts of a python "global function architecture". In a /true/ 100% OOP language most of these "dunder" methods would become interface members of the object.

There is also the question of WHEN to use and WHEN NOT to use the "dunder" naming convention. I actually like the convention myself for clearly defining methods that are called by "syntactic sugar". However, python employs the convention quite haphazardly. 

For example:  
    __iadd__ is called by an expression such as: "1+=1"
    which is translated into: "1.__iadd__(1)"
    
However:
    __repr__ is called by the the global "repr" function
    which is translated into: "obj.__repr__()"
   
I don't like the second usage because i believe this naming convention should be reserved for syntactical sugar only. But i digress...

Here is a better example of Python converted into true OOP paridigm (renaming and removing methods appropriately to fit my logical 100% OOP API).

class Object(SuperType):
    def construct # aka: __init__
    def desconstruct # aka: __del__
    def class
    def delattr(name)
    def doc
    def getattr(name)
    def __new__ # dunder???
    def repr
    def setattr(name, value)
    def size
    def stringify # aka: __str__
    def subclasshook # XXX: dunder???
    def true? # aka: __bool__
    def callable?
    def compare(other)
    def methods
    def instance_methods 
    def hash
    def help
    def id
    def isinstance?(this)
    def issubclass?(this)
    def super
    def type

class SequenceBase(Object):
    # Methods from object are free
    def __add__
    def __contains?__
    def __delitem__
    def __delslice__
    def __eq__
    def __ge__
    def __getitem__
    def __getslice__
    def __gt__
    def __iadd__
    def __imul__
    def __iter__
    def __le__
    def __lt__
    def __mul__
    def __ne__
    def __rmul__
    def __setitem__
    def __setslice__
    #
    # Interface
    #
    slice = __getslice__
    extend = __add__
    contains? = __contains?__
    def length # pka: __len__
    def any
    def all
    def enumerate -> iterator
    def filter(proc)
    def map(proc)
    def max
    def min
    def reverse
    def reduce(proc)
    def sort
    def zip
    

class Sequence(SequenceBase): # aka: list
    # Methods from SequenceBase and Object are free!
    #
    # Interface
    #
    def append(this)
    def count(this)
    def index(this)
    def insert(idx, this)
    def pop()
    def remove(this)
    def reverse
    def sort
 
I'm a bit unnerved by the sum function. Summing a sequence only makes sense if the sequence in question contains /only/ numeric types. For that reason i decided to create a special type for holding Numerics. This will probably result in many complaints from lazy people who want to use only one Sequence type, which holds mixed types, THEN jamb nothing but numeric types into it, THEN have a sum method that throws errors when it encounters a non-numeric type!!! I say, too bad for you. 

Stop obfuscating your code! Of course someone could probably find a legitimate reason to apply a sum method to non-numeric values; if so, then inherit from NumericSequence and create your custom type!

class NumericSequence(Sequence):
    # Methods from Sequence, SequenceBase, and Object are free!
    def __setitem__(item):
        if not item.isinstance(Numeric):
            raise TypeError()
    def __add__(other):
        if not other.isinstance(NumericSequence):
            raise TypeError()
    def __setslice__(other):
        # blah
    #
    # Interface
    #
    def sum -> Integer

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

#38481

On Sat, Feb 9, 2013 at 6:58 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> I'm a bit unnerved by the sum function. Summing a sequence only makes sense if the sequence in question contains /only/ numeric types. For that reason i decided to create a special type for holding Numerics. This will probably result in many complaints from lazy people who want to use only one Sequence type, which holds mixed types, THEN jamb nothing but numeric types into it, THEN have a sum method that throws errors when it encounters a non-numeric type!!! I say, too bad for you.


Most assuredly not. The sum builtin works happily on any sequence of
objects that can be added together. It works as an excellent flatten()
method:

>>> nested_list = [["q"], ["w","e"], ["r","t","u"], ["i","o","p"]]
>>> sum(nested_list,[])
['q', 'w', 'e', 'r', 't', 'u', 'i', 'o', 'p']
>>> nested_list
[['q'], ['w', 'e'], ['r', 't', 'u'], ['i', 'o', 'p']]

I'm not sure what your definition of a numeric type is, but I suspect
that list(str) isn't part of it.

ChrisA

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

#38483

On Friday, February 8, 2013 6:05:54 PM UTC-6, Chris Angelico wrote:
> The sum builtin works happily on any sequence of objects
> that can be added together. It works as an excellent
> flatten() method:
> 
> >>> nested_list = [["q"], ["w","e"], ["r","t","u"], ["i","o","p"]]
> >>> sum(nested_list,[])
> ['q', 'w', 'e', 'r', 't', 'u', 'i', 'o', 'p']
> >>> nested_list
> [['q'], ['w', 'e'], ['r', 't', 'u'], ['i', 'o', 'p']]

What the hell? Oh yeah, you must be using pike again. No, if it were pike the list would look like this:

({({"q"}), ({"w","e"}), ({"r","t","u"}), ({"i","o","p"})})

Of course you'd have to declare it first using an /expanded/ Java syntax:

 nested_list = array(array(string))
 
Folks, i couldn't make this stuff up if i wanted to. Go read for yourself if want a few laughs.
  
  http://pike.lysator.liu.se/docs/tutorial/data_types/container_types.xml

> I'm not sure what your definition of a numeric type is, but I suspect
> that list(str) isn't part of it.

Of course not. 

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

#38487

On Sat, Feb 9, 2013 at 11:49 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Friday, February 8, 2013 6:05:54 PM UTC-6, Chris Angelico wrote:
>> The sum builtin works happily on any sequence of objects
>> that can be added together. It works as an excellent
>> flatten() method:
>>
>> >>> nested_list = [["q"], ["w","e"], ["r","t","u"], ["i","o","p"]]
>> >>> sum(nested_list,[])
>> ['q', 'w', 'e', 'r', 't', 'u', 'i', 'o', 'p']
>> >>> nested_list
>> [['q'], ['w', 'e'], ['r', 't', 'u'], ['i', 'o', 'p']]
>
> What the hell? Oh yeah, you must be using pike again. No, if it were pike the list would look like this:
>
> ({({"q"}), ({"w","e"}), ({"r","t","u"}), ({"i","o","p"})})
>
> Of course you'd have to declare it first using an /expanded/ Java syntax:
>
>  nested_list = array(array(string))

Strange... normally I have to actually bring Pike up, no idea why
you're doing it for me. But okay.

Actually, that's not a declaration, that's an assignment; and in Pike,
a 'type' is a thing, same as it is in Python (though not quite). If I
were to declare it in Pike, it would be:

array(array(string)) nested_list;

Though the part inside the parens can be omitted, in which case the
array can contain anything, rather than being restricted to strings.
In actual fact, Rick, despite your complaints about the syntax, it's
able to achieve exactly what you were thinking Python should do:
declare an array/list that contains only numbers.

> Folks, i couldn't make this stuff up if i wanted to. Go read for yourself if want a few laughs.
>
>   http://pike.lysator.liu.se/docs/tutorial/data_types/container_types.xml

Apart from some syntactic differences, which in the scheme of things
are pretty trivial, the only difference is that Pike permits (without
demanding) you to restrict an array's members. In fact, Pike lets you
declare everything as 'mixed' if you like, allowing you to put
*anything* into *anywhere*... which, yaknow, is pretty much identical
to Python's model (only with declared variables), and takes advantage
of the fact that there are no Java-style "unboxed" types (the Pike int
is like the Py3 int or the Py2 long, arbitrary precision).

>> I'm not sure what your definition of a numeric type is, but I suspect
>> that list(str) isn't part of it.
>
> Of course not.

And yet, in both Pike and Python, adding lists/arrays of strings
together is not just legal but extremely useful. Do we need to rewrite
the sum() function to handle lists instead of letting operator
overloading take care of it for us? Suppose I make a string subclass
with a division operator:

class divisible_string(str):
	def __truediv__(self,n):
		n=(len(self)+n-1)//n
		return [self[pos:pos+n] for pos in range(0,len(self),n)]
# and a bunch of functions so operations on a divisible_string return
a divisible_string

Now, I should be able to divide a string by 2 and get a two-element
list. Kinda convenient, would be cool if str supported this, but it's
OOP and OOP is all about operator overloading, even if it makes your
code less readable - a language isn't 100% OOP unless this sort of
thing is normal, right?

Suppose also that I have an avg() function that does this:

def avg(it):
	it=iter(it)
	tot=next(it)
	pos=-1
	for pos,val in enumerate(it):
		tot+=val
	return tot/(pos+2)

I can take the avg() of a list (or other iterable) of integers, and
get back a number. Do I need to rewrite this function to handle my
divisible_string? Or do I need to have divisible_string subclass some
"averageable" class/interface in order to permit them to be used
inside a list that has an avg() method?

lst=avg(map(divisible_string,("asdf","qwer","a","z","f","qqqqq","asdfasdfasdf")))

How do you solve the puzzle, Rick?

ChrisA

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

#38553

On Friday, February 8, 2013 7:17:26 PM UTC-6, Chris Angelico wrote:
> On Sat, Feb 9, 2013 at 11:49 AM, Rick Johnson
> >  nested_list = array(array(string))
> 
> Actually, that's not a declaration, that's an assignment; and in Pike,
> a 'type' is a thing, same as it is in Python (though not quite). If I
> were to declare it in Pike, it would be:
> 
> array(array(string)) nested_list;
> 
> Though the part inside the parens can be omitted, in which case the
> array can contain anything, rather than being restricted to strings.
> In actual fact, Rick, despite your complaints about the syntax, it's
> able to achieve exactly what you were thinking Python should do:
> declare an array/list that contains only numbers.

Well Chris i have wonderful news for you! Python /does/ have "homogenous arrays", and they're called, wait for it......... arrays! Imagine that!

py> import array
py> intSeq = array.array('i')
py> intSeq.append(1)
py> intSeq.append(2)
py> intSeq.append(5000)
py> intSeq.append(5000.333)
TypeError: integer argument expected, got float
py> intSeq.append('5000.333')
TypeError: an integer is required

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

#38556

On Sun, Feb 10, 2013 at 3:54 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> Well Chris i have wonderful news for you! Python /does/ have "homogenous arrays", and they're called, wait for it......... arrays! Imagine that!

That's not a built-in. But you were the one who complained about the
way sum() could be applied to a list that contains a non-integer;
maybe your solution is simply to ignore sum() and work with
array.array?

Nice how you can complain about Python for not having something, then
heap scorn on me for not being aware that it's there in the stdlib.
(Which, by the way, I freely admit to being less than fully familiar
with. Even less familiar with what's on PyPI.)

ChrisA

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

#38669

On Saturday, February 9, 2013 11:04:42 PM UTC-6, Chris Angelico wrote:
> On Sun, Feb 10, 2013 at 3:54 PM, Rick Johnson wrote:
> > Well Chris i have wonderful news for you! Python /does/
> > have "homogenous arrays", and they're called, wait for
> > it......... arrays!

> That's not a built-in. But you were the one who complained about the
> way sum() could be applied to a list that contains a non-integer;
> maybe your solution is simply to ignore sum() and work with
> array.array?

Yes i could, however by doing so i would be ignoring the inconsistent elephant in the room. My crusade is to bring consistency and logic to languages, and if i have any free time afterwards, to remove multiplicity. There are two types of people in the world Chris, those that lead and those that follow. 

> Nice how you can complain about Python for not having something, then
> heap scorn on me for not being aware that it's there in the stdlib.
> (Which, by the way, I freely admit to being less than fully familiar
> with. Even less familiar with what's on PyPI.)

Well i would expect anyone who considers himself a python programmer (not to mention "pythonista"!) to at minimum be familiar with the stdlib. That does not mean he must have attained black belt level kung-fu in /every/ stdlib module, but he must at least /know/ all the modules names and all types that Python offers. Is that really too much to ask Chris?

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

#38673

On Mon, Feb 11, 2013 at 11:28 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Saturday, February 9, 2013 11:04:42 PM UTC-6, Chris Angelico wrote:
>> On Sun, Feb 10, 2013 at 3:54 PM, Rick Johnson wrote:
>> > Well Chris i have wonderful news for you! Python /does/
>> > have "homogenous arrays", and they're called, wait for
>> > it......... arrays!
>
>> That's not a built-in. But you were the one who complained about the
>> way sum() could be applied to a list that contains a non-integer;
>> maybe your solution is simply to ignore sum() and work with
>> array.array?
>
> Yes i could, however by doing so i would be ignoring the inconsistent elephant in the room. My crusade is to bring consistency and logic to languages, and if i have any free time afterwards, to remove multiplicity. There are two types of people in the world Chris, those that lead and those that follow.

In other words, you prefer to argue than to code.

>> Nice how you can complain about Python for not having something, then
>> heap scorn on me for not being aware that it's there in the stdlib.
>> (Which, by the way, I freely admit to being less than fully familiar
>> with. Even less familiar with what's on PyPI.)
>
> Well i would expect anyone who considers himself a python programmer (not to mention "pythonista"!) to at minimum be familiar with the stdlib. That does not mean he must have attained black belt level kung-fu in /every/ stdlib module, but he must at least /know/ all the modules names and all types that Python offers. Is that really too much to ask Chris?

Actually, it is. How many modules and types does Python offer? Can you
tell me, without looking it up? Okay. Now how many does Ruby offer?
Presumably you extend the same courtesy to other languages. Now
imagine someone who knows twenty languages. Will s/he know their
entire stdlibs?

If there is anyone here who can honestly boast knowing the ENTIRE
stdlib of a language the size of Python, I would be impressed. Very
impressed.

ChrisA

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

#38680

On Monday, February 11, 2013 6:50:03 AM UTC-6, Chris Angelico wrote:
> On Mon, Feb 11, 2013 at 11:28 PM, Rick Johnson
> > Well i would expect anyone who considers himself a
> > python programmer (not to mention "pythonista"!) to at
> > minimum be familiar with the stdlib. [...]
> 
> [...]
> 
> If there is anyone here who can honestly boast knowing the ENTIRE
> stdlib of a language the size of Python, I would be impressed. Very
> impressed.

I am sure there are quite a few Chris. But if you expect to around making statements like: "Python does not have typed arrays", then don't get all upset when someone corrects you. 

Maybe, before you go and pop your mouth off next time, if it isn't too much trouble, i mean, i don't want you to get a cramp in your wrist or a blister on your finger, much less a headache reading a few lines of documentation, but if is not too much to ask, "Mr. Angelico", i would suggest you stuff this tiny little code snippet into your favorite Python interpreter and run it!

py> help('modules')

See, some python functions are useful. 

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

#38683

On Tue, Feb 12, 2013 at 12:28 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> I am sure there are quite a few Chris. But if you expect to around making statements like: "Python does not have typed arrays", then don't get all upset when someone corrects you.

Oh, I don't mind being corrected on those sorts of points. And if ever
I say "Python doesn't have a module for creating a DNS server", I will
be quite happy to be corrected, because DNS servers are fun.

But my statement wasn't based on my own knowledge of the stdlib, but
rather on this:

On Sat, Feb 9, 2013 at 6:58 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> I'm a bit unnerved by the sum function. Summing a sequence only makes sense if the sequence in question contains /only/ numeric types. For that reason i decided to create a special type for holding Numerics.

Why create a special type if it already exists?

> Maybe, before you go and pop your mouth off next time, if it isn't too much trouble, i mean, i don't want you to get a cramp in your wrist or a blister on your finger, much less a headache reading a few lines of documentation, but if is not too much to ask, "Mr. Angelico", i would suggest you stuff this tiny little code snippet into your favorite Python interpreter and run it!
>
> py> help('modules')
>
> See, some python functions are useful.

Yep. By the way, how does the help function fit into your wonderfully
OOP model? What's it a method on?

ChrisA

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

#38721

On Monday, February 11, 2013 7:52:24 AM UTC-6, Chris Angelico wrote:
> [...]
> But my statement wasn't based on my own knowledge of the stdlib, but
> rather on this:
> 
> On Sat, Feb 9, 2013 at 6:58 AM, Rick Johnson wrote:
> > I'm a bit unnerved by the sum function. Summing a
> > sequence only makes sense if the sequence in question
> > contains /only/ numeric types. For that reason i decided
> > to create a special type for holding Numerics.
> 
> Why create a special type if it already exists?

Because at the time i made this statement we were discussing 100% true OOP (you know, the kind of paradigm where object definition identifiers start with a capital letter? *estoeric-wink*), but more importantly because i don't find the current implementation of array and list to be consistent.

> Yep. By the way, how does the help function fit into your wonderfully
> OOP model? What's it a method on?

Well since /all/ objects will have help available it should be defined Object#help and then propagate downwards. But even true OOP languages need a few global functions... *gasp*... oh yes! A few that come to mind include:

 globals, locals, vars, compile, eval, exec, input, print, dir
 
And don't forget, we still have module namespace to deal with!
 
 

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

#38722

On Monday, February 11, 2013 7:52:24 AM UTC-6, Chris Angelico wrote:
> [...]
> But my statement wasn't based on my own knowledge of the stdlib, but
> rather on this:
> 
> On Sat, Feb 9, 2013 at 6:58 AM, Rick Johnson wrote:
> > I'm a bit unnerved by the sum function. Summing a
> > sequence only makes sense if the sequence in question
> > contains /only/ numeric types. For that reason i decided
> > to create a special type for holding Numerics.
> 
> Why create a special type if it already exists?

Because at the time i made this statement we were discussing 100% true OOP (you know, the kind of paradigm where object definition identifiers start with a capital letter? *estoeric-wink*), but more importantly because i don't find the current implementation of array and list to be consistent.

> Yep. By the way, how does the help function fit into your wonderfully
> OOP model? What's it a method on?

Well since /all/ objects will have help available it should be defined Object#help and then propagate downwards. But even true OOP languages need a few global functions... *gasp*... oh yes! A few that come to mind include:

 globals, locals, vars, compile, eval, exec, input, print, dir
 
And don't forget, we still have module namespace to deal with!
 
 

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

#38684

On Monday, February 11, 2013 6:50:03 AM UTC-6, Chris Angelico wrote:
> On Mon, Feb 11, 2013 at 11:28 PM, Rick Johnson
> > Well i would expect anyone who considers himself a
> > python programmer (not to mention "pythonista"!) to at
> > minimum be familiar with the stdlib. [...]
> 
> [...]
> 
> If there is anyone here who can honestly boast knowing the ENTIRE
> stdlib of a language the size of Python, I would be impressed. Very
> impressed.

I am sure there are quite a few Chris. But if you expect to around making statements like: "Python does not have typed arrays", then don't get all upset when someone corrects you. 

Maybe, before you go and pop your mouth off next time, if it isn't too much trouble, i mean, i don't want you to get a cramp in your wrist or a blister on your finger, much less a headache reading a few lines of documentation, but if is not too much to ask, "Mr. Angelico", i would suggest you stuff this tiny little code snippet into your favorite Python interpreter and run it!

py> help('modules')

See, some python functions are useful. 

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web