Path: csiph.com!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <75c82449-773e-4077-a6c9-e9cef08f845f@googlegroups.com>
References: <mailman.2132.1342341291.4697.python-list@python.org> <5002a1f9$0$29995$c3e8da3$5496439d@news.astraweb.com> <mailman.2141.1342369188.4697.python-list@python.org> <7b027612-a07e-40f9-8ad2-3e95c5440482@googlegroups.com> <mailman.2148.1342375350.4697.python-list@python.org> <bbc44546-ffb7-4ff9-bd43-3bfa068df75f@googlegroups.com> <mailman.2154.1342389192.4697.python-list@python.org> <86872ad2-fda0-403b-9f18-d1cb18e41860@t32g2000yqd.googlegroups.com> <CAPTjJmov--b_s5e=OYsWWV8w6byj5a+28NNu-vRWGV8mr8w5cg@mail.gmail.com> <mailman.2159.1342404957.4697.python-list@python.org> <50039290$0$29978$c3e8da3$5496439d@news.astraweb.com> <mailman.2197.1342498752.4697.python-list@python.org> <9309333c-13a0-464c-bd94-9c682363b8c9@googlegroups.com> <511516db$0$29969$c3e8da3$5496439d@news.astraweb.com> <ee71b775-b527-4bb3-a080-12aad962b0ba@googlegroups.com> <62c3e7bb-d023-43b4-b759-f424707fd346@googlegroups.com> <mailman.1521.1360368357.2939.python-list@python.org> <75c82449-773e-4077-a6c9-e9cef08f845f@googlegroups.com>
Date: Sat, 9 Feb 2013 12:17:26 +1100
Subject: Re: Implicit conversion to boolean in if and while statements
From: Chris Angelico <rosuav@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1526.1360372655.2939.python-list@python.org>
Lines: 94
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python: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