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

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

LangWart: Method congestion from mutate multiplicty

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

Contents

  LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-08 17:50 -0800
    Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-09 14:36 +1100
      Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-09 19:54 -0800
        Re: LangWart: Method congestion from mutate multiplicty Chris Angelico <rosuav@gmail.com> - 2013-02-10 15:20 +1100
        Re: LangWart: Method congestion from mutate multiplicty Mark Janssen <dreamingforward@gmail.com> - 2013-02-09 20:53 -0800
          Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-11 01:29 +1100
            Re: LangWart: Method congestion from mutate multiplicty Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-10 14:03 -0500
              Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-11 11:11 +1100
            Re: LangWart: Method congestion from mutate multiplicty Mark Janssen <dreamingforward@gmail.com> - 2013-02-10 13:28 -0800
              Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-11 11:10 +1100
                Re: LangWart: Method congestion from mutate multiplicty Mark Janssen <dreamingforward@gmail.com> - 2013-02-10 17:14 -0800
            Re: LangWart: Method congestion from mutate multiplicty Chris Angelico <rosuav@gmail.com> - 2013-02-11 08:51 +1100
            Re: LangWart: Method congestion from mutate multiplicty Mark Janssen <dreamingforward@gmail.com> - 2013-02-10 14:01 -0800
        Re: LangWart: Method congestion from mutate multiplicty Terry Reedy <tjreedy@udel.edu> - 2013-02-10 03:39 -0500
          Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 10:45 -0800
            Re: LangWart: Method congestion from mutate multiplicty Terry Reedy <tjreedy@udel.edu> - 2013-02-10 16:44 -0500
            Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-11 11:11 +1100
          Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 10:45 -0800
        Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-10 22:29 +1100
          Re: LangWart: Method congestion from mutate multiplicty Chris Angelico <rosuav@gmail.com> - 2013-02-11 00:24 +1100
            Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-11 01:00 +1100
          Re: LangWart: Method congestion from mutate multiplicty Tim Chase <python.list@tim.thechases.com> - 2013-02-10 07:52 -0600
          Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 15:59 -0800
            Re: LangWart: Method congestion from mutate multiplicty Tim Chase <python.list@tim.thechases.com> - 2013-02-10 18:12 -0600
              Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 17:24 -0800
              Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 17:24 -0800
            Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-11 11:36 +1100
              Re: LangWart: Method congestion from mutate multiplicty MRAB <python@mrabarnett.plus.com> - 2013-02-11 02:03 +0000
              Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 04:53 -0800
                Re: LangWart: Method congestion from mutate multiplicty Chris Angelico <rosuav@gmail.com> - 2013-02-12 00:27 +1100
                  Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 20:55 -0800
                    Re: LangWart: Method congestion from mutate multiplicty Mark Janssen <dreamingforward@gmail.com> - 2013-02-11 21:28 -0800
                      Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-12 12:46 -0800
                      Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-12 12:46 -0800
                  Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 20:55 -0800
            Re: LangWart: Method congestion from mutate multiplicty alex23 <wuwei23@gmail.com> - 2013-02-10 18:05 -0800
              Re: LangWart: Method congestion from mutate multiplicty Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-02-11 07:19 +0000
              Re: LangWart: Method congestion from mutate multiplicty Chris Angelico <rosuav@gmail.com> - 2013-02-11 18:24 +1100
              Re: LangWart: Method congestion from mutate multiplicty Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-02-11 07:35 +0000
              Re: LangWart: Method congestion from mutate multiplicty Tim Chase <tim@thechases.com> - 2013-02-11 06:04 -0600
              Re: LangWart: Method congestion from mutate multiplicty Serhiy Storchaka <storchaka@gmail.com> - 2013-02-11 19:07 +0200
        Re: LangWart: Method congestion from mutate multiplicty Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-02-10 13:30 +0000
          Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 16:25 -0800
            Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-11 11:42 +1100
          Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 16:25 -0800
        Re: LangWart: Method congestion from mutate multiplicty Mark Janssen <dreamingforward@gmail.com> - 2013-02-10 10:45 -0800
      Re: LangWart: Method congestion from mutate multiplicty 88888 Dihedral <dihedral88888@googlemail.com> - 2013-02-10 06:33 -0800
    Re: LangWart: Method congestion from mutate multiplicty Chris Angelico <rosuav@gmail.com> - 2013-02-09 15:51 +1100
      Re: LangWart: Method congestion from mutate multiplicty alex23 <wuwei23@gmail.com> - 2013-02-10 17:56 -0800
        Re: LangWart: Method congestion from mutate multiplicty Chris Angelico <rosuav@gmail.com> - 2013-02-12 19:06 +1100
    Re: LangWart: Method congestion from mutate multiplicty Neil Hodgson <nhodgson@iinet.net.au> - 2013-02-10 20:53 +1100
      Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-10 22:30 +1100
      Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 10:55 -0800
        Re: LangWart: Method congestion from mutate multiplicty Neil Hodgson <nhodgson@iinet.net.au> - 2013-02-11 08:57 +1100

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

#38571

Chris Angelico wrote:

> On Sun, Feb 10, 2013 at 10:29 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> "inserted" is called addition, together with list slicing when needed.
>>
>> newlist = [item_to_insert] + oldlist
>> newlist = oldlist[0:5] + [item_to_insert] + oldlist[5:]
> 
> Really? Wouldn't it be easier to use slice assignment on a copy?
> 
> newlist = oldlist[:]; newlist[pos:pos] = [item_to_insert]

I don't know about "easier", but it's two statements rather than a single
expression, which means you cannot easily include it as part of a larger
expression.


> Actually, come to think of it, that scores about the same on
> readability. Six of one, half dozen of the other.

Pretty much.


-- 
Steven

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

#38569

On Sun, 10 Feb 2013 22:29:54 +1100, Steven D'Aprano wrote:
> Rick Johnson wrote:
> >  map, mapped
> >  filter, filtered
> >  reduce, reduced
> 
> Those are nonsense. None of those are in-place mutator methods.
> Especially reduce, which reduces a list to a single item. You might
> as well have suggested "len, "lened".

And, if you want those in-place, indexing trivially comes to the
rescue again:

  lst[:] = map(transform_fn, lst)
  lst[:] = filter(check_fn, lst)

or, as I prefer:

  lst[:] = [transform_fn(x) for x in lst]
  lst[:] = [x for x in lst if check_fn(x)]

as they can be combined simply.

-tkc

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

#38616

On Sunday, February 10, 2013 5:29:54 AM UTC-6, Steven D'Aprano wrote:
> Rick wrote:
> And you have missed my point, which is that reversed(), and sorted(), were
> not added to the language on a whim, but because they were requested, over
> and over and over again.

Well, well, this explains everything!

We don't add features because of logic, or because of consistency, or even because of good sense, we simply add them to appease the masses.

psst: Steven, maybe if the C and Java heads moan long enough we can get braced scoping, or, if the ruby guys pester us enough we can adopt the dollar sign to denote globals, the "@@" for class variables, and the "@" for instance variables! Oh yes! Because being loved is SO much more important than sticking to our philosophy of the Python Zen.

> "appended" is called list addition.
>
> newlist = oldlist + [item_to_append]

But where is the consistency?

Yes the syntactic sugar of the "plus sign" is concise, however, the "+" operator does not "pair" intuitively with the "append" method. Even IF you transformed the "+" operator into a named method like "add" (or call the magic method "__add__") it still fails to mesh properly with "append", and the two words utterly fail to intuitively establish an "in-place" versus "copy-mutate" relationship. Consider the English definitions of "add" and "append" when applied to sequence objects:

  DEFINE "add"
    Expand a sequence of "somethings" to include
    additional "somethings" -- which may be another
    sequence of N somethings. However the exact
    location of the new "somethings" is not clearly
    intuit-able from the word "add" alone!

  DEFINE "append"
    Expand a sequence of "somethings" to include an
    additional "something". Here the exact location
    is can be intuited as: "at the end".

> >  flatten, flattened
> 
> flatten is another often requested, hard to implement correctly, function.
> The only reason that Python doesn't have a flatten is that nobody can agree
> on precisely what it should do.

Steven, the definition of flatten (as relates to sequences) is very, VERY simple:

    Return a new sequence that is the result of reducing
    a nested sequence of sequences into a single depth 
    sequence.

> Like map, filter, reduce, etc. flatten is not sensibly implemented as a
> mutator method, but as a function.

Only because you, along with a few other high ranking members of this community (including the BDFL himself!) have this /aversion/ to true OOP paradigm. 

Can you provide an example of how flatten "as a method" is incorrect versus flatten "as a function" is correct, or will this challenge be silently swept under the rug as so many before?

> >  insert, inserted
> 
> "inserted" is called addition, together with list slicing when needed.
> newlist = [item_to_insert] + oldlist
> newlist = oldlist[0:5] + [item_to_insert] + oldlist[5:


"inserted" is called "addition" by who?

If are implying that "seq.__add__()" employs the semantics of the English word "addition" and seq.insert(arg) is a thin wrapper around "oldlist[0:5]+[item]+oldlist[5:]", then fine. But how will someone intuit those two methods as have a "mutating pairs relationship" from the names alone? Not to mention that calling magic methods is anti-pythonic!

> >  map, mapped
> >  filter, filtered
> >  reduce, reduced
> 
> Those are nonsense. None of those are in-place mutator methods.

Well not in the current implementation of Python; but they could be if we wanted them to be. Applying mutations both "in-place" and "to a copy" are very helpful. For example, Ruby supplies both forms for many commonly used operations on arrays: (However i am not a fan of these "mutator pairs")

    slice, slice!
    sort, sort!
    flatten, flatten!
    collect, collect!
    map, map!
    uniq, uniq!
    reject, reject!
    reverse, reverse!
    compact, compact!


Steven, just because you have yet to encounter such usage does not mean the usage is "non-sense"

    seq.map(func)
    new = seq.mapped(func)

    seq.filter(lambda x: x<2)
    new = seq.filtered(lambda x: x<2)


> Especially reduce, which reduces a list to a single item. 

Nice to see you are paying attention! I am sure you already know this, although your wording was clumsy and suggests otherwise, but reduce does NOTHING to the list itself:

py> from operator import add
py> a = [1,2,3]
py> reduce(add, a)
6
py> a
[1, 2, 3]

reduce simply returns the result of the reduction; which is an Integer.

However it is my strong belief that the sum function should not exist when a reduce function does. Why? Because "sum([1,2,3])" is the equivalent of "reduce(operator.add, [1,2,3])"; the latter being significantly explicit and the former being a potential linguistical interpretation nightmare.

Now some might complain about this proposed removal of "sum" because the reduce function requires two arguments whereas the sum only needs one, and I say you're correct, however, this negative attribute is an artifact of a "global function nightmare architecture" and IF the core developers of Python would accept the fine principals of true OOP paradigm, then the call would look like this instead:

    seq.reduce(operator.add)

This fine example of OOP style is much easier to grok than the either the sum or reduce global functions could ever wish to be.

> >  extend, extended
> 
> Again, "extended" is spelled list addition.
> 
> Are you sure you've actually programmed in Python before? You seem awfully
> ignorant of language features.

So you are saying that "addition" is a "language feature"(sic). Can you please provide an example of "addition" as a language feature?

py> 'addition' in dir(list)
False

> [...]
> > My point was this: All mutate methods should mutate "in-place",
> 
> Well duh. All mutator methods do mutate in-place, otherwise they wouldn't be
> mutator methods.

So "reversed()" and "sorted()" mutate in-place? Do you realize that these two functions are an extension of the list (or sub-types of list) interface and are in fact mutating a seq object in-place! Maybe not the sequence object you called the function on, but a seq object none-the-less!

> > if the
> > programmer wishes to create a mutated copy of the object, then the
> > programmer should /explicitly/ create a copy of the object and then apply
> > the correct mutator method to the copy.
> 
> Been there, done that, it sucks. That's about a dozen steps backwards to a
> worse time in Python development.

Why? Because you have to type this

    reversed = list(seq).reverse()

Instead of this:

    reversed = reversed(seq)

*rolls-eyes*

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

#38620

> > >  flatten, flattened
> > 
> > flatten is another often requested, hard to implement correctly,
> > function. The only reason that Python doesn't have a flatten is
> > that nobody can agree on precisely what it should do.
> 
> Steven, the definition of flatten (as relates to sequences) is
> very, VERY simple:
> 
>     Return a new sequence that is the result of reducing
>     a nested sequence of sequences into a single depth 
>     sequence.

What should you get if you flatten

  [[[1,2],[3,4]],[[5,6],[7,8]]]

Should the result be

  [[1,2],[3,4],[5,6],[7,8]]

or

  [1,2,3,4,5,6,7,8]

I've needed both cases, depending on the situation.

-tkc

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

#38628

On Sunday, February 10, 2013 6:12:57 PM UTC-6, Tim Chase wrote:
> What should you get if you flatten
> 
>   [[[1,2],[3,4]],[[5,6],[7,8]]]
> 
> Should the result be
> 
>   [[1,2],[3,4],[5,6],[7,8]]
> 
> or
> 
>   [1,2,3,4,5,6,7,8]
> 
> I've needed both cases, depending on the situation.

Well providing /every/ possible solution for /every/ possible answer to /every/ problem is not going to be possible unless you are willing to endure an endless amount of complexity. 

My opinion is that flatten should should call seq.flatten() on all sub-sequences. That seems like the only /reasonable/ resolution to allow. At least sub-types could define how they get flattened. 

However, that does not solve your problem: where you wish to flatten a sequence down to a prescribed sub-depth; in your example: flatten(subdepth=1). 

class Sequence():
    """Hypothetical sequence object."""
    def flatten(self, depth=INFINITY):
        # ...
        
py> seq = [[[1,2],[3,4]],0,[[5,6],[7,8]]]
py> seq.flatten()
[1,2,3,4,0,5,6,7,8]
py> seq.flatten(depth=1)
[[1,2,3,4],0,[5,6,7,8]]
py> seq.flatten(depth=2)
[1,2,3,4,0,5,6,7,8]
py> seq.flatten(depth=3)
# Throw error or just quietly return flat list???

I don't feel very good about this API though. But i admit it might be beneficial to some folks. Should this example be the built-in behavior of Sequence#flatten, probably not. But hey, here at pydev we add features that appease the masses because we want to be loved. So folks, get your votes in! :-)

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

#38633

On Sunday, February 10, 2013 6:12:57 PM UTC-6, Tim Chase wrote:
> What should you get if you flatten
> 
>   [[[1,2],[3,4]],[[5,6],[7,8]]]
> 
> Should the result be
> 
>   [[1,2],[3,4],[5,6],[7,8]]
> 
> or
> 
>   [1,2,3,4,5,6,7,8]
> 
> I've needed both cases, depending on the situation.

Well providing /every/ possible solution for /every/ possible answer to /every/ problem is not going to be possible unless you are willing to endure an endless amount of complexity. 

My opinion is that flatten should should call seq.flatten() on all sub-sequences. That seems like the only /reasonable/ resolution to allow. At least sub-types could define how they get flattened. 

However, that does not solve your problem: where you wish to flatten a sequence down to a prescribed sub-depth; in your example: flatten(subdepth=1). 

class Sequence():
    """Hypothetical sequence object."""
    def flatten(self, depth=INFINITY):
        # ...
        
py> seq = [[[1,2],[3,4]],0,[[5,6],[7,8]]]
py> seq.flatten()
[1,2,3,4,0,5,6,7,8]
py> seq.flatten(depth=1)
[[1,2,3,4],0,[5,6,7,8]]
py> seq.flatten(depth=2)
[1,2,3,4,0,5,6,7,8]
py> seq.flatten(depth=3)
# Throw error or just quietly return flat list???

I don't feel very good about this API though. But i admit it might be beneficial to some folks. Should this example be the built-in behavior of Sequence#flatten, probably not. But hey, here at pydev we add features that appease the masses because we want to be loved. So folks, get your votes in! :-)

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

#38623

Rick Johnson wrote:

> On Sunday, February 10, 2013 5:29:54 AM UTC-6, Steven D'Aprano wrote:
>> Rick wrote:
>> And you have missed my point, which is that reversed(), and sorted(),
>> were not added to the language on a whim, but because they were
>> requested, over and over and over again.
> 
> Well, well, this explains everything!
> 
> We don't add features because of logic, or because of consistency, or even
> because of good sense, we simply add them to appease the masses.

They were requested because people kept re-inventing them. They kept
re-inventing them because they are useful functions that make good sense to
have.


>> "appended" is called list addition.
>>
>> newlist = oldlist + [item_to_append]
> 
> But where is the consistency?

Strings use + for concatenation. Tuples use + for concatenation. Lists use +
for concatenation. Seems pretty consistent to me.

Are you sure you've used Python before?


> Yes the syntactic sugar of the "plus sign" is concise, however, the "+"
> operator does not "pair" intuitively with the "append" method. 

Adding "ed" to a word does not pair intuitively with the method name. You
have to learn it, which in the case of most English speakers you probably
did between the ages of 2 and 6.

Using + to represent concatenation is no less intuitive.



> Even IF you 
> transformed the "+" operator into a named method like "add" (or call the
> magic method "__add__") it still fails to mesh properly with "append", and
> the two words utterly fail to intuitively establish an "in-place" versus
> "copy-mutate" relationship. 

So what?



>> >  flatten, flattened
>> 
>> flatten is another often requested, hard to implement correctly,
>> function. The only reason that Python doesn't have a flatten is that
>> nobody can agree on precisely what it should do.
> 
> Steven, the definition of flatten (as relates to sequences) is very, VERY
> simple:
> 
>     Return a new sequence that is the result of reducing
>     a nested sequence of sequences into a single depth
>     sequence.

Very, VERY simple until you actually implement this function, and discover
that it does too much e.g.

flatten([None, 23, [1, 2, 3], Point(x=2, y=3), ["spam", "ham"]])

=> [None, 23, 1, 2, 3, 2, 3, 's', 'p', 'a', 'm', 'h', 'a', 'm']


So people who have *actually programmed*, instead of just talking about
programming, have discovered that in practice you need to treat some
sequences as primitives that don't get expanded.



>> Like map, filter, reduce, etc. flatten is not sensibly implemented as a
>> mutator method, but as a function.
> 
> Only because you, along with a few other high ranking members of this
> community (including the BDFL himself!) have this /aversion/ to true OOP
> paradigm.
> 
> Can you provide an example of how flatten "as a method" is incorrect
> versus flatten "as a function" is correct, or will this challenge be
> silently swept under the rug as so many before?

Simple efficiency. The most efficient, and sensible, way to flatten a list
is to create a new list. Trying to flatten a list in place is a dumb
idea -- it is O(n**2), or possibly even worse. Since only an idiot would
write flatten as an in-place method, any mutator version of flatten would
have to use a non-mutator version, then use slicing to over-write itself:

def flatten(self):
    new_list = flatten(self)
    self[:] = new_list


which is fine if you absolutely have to have an in-place version, but why
bother? The caller can do it themselves:

mylist = flatten(mylist)


[snip]
>> >  map, mapped
>> >  filter, filtered
>> >  reduce, reduced
>> 
>> Those are nonsense. None of those are in-place mutator methods.
> 
> Well not in the current implementation of Python; but they could be if we
> wanted them to be.

Now you're smoking crack. How can *reduce* be an in-place mutator method?

py> mylist = [1, 2, 3, 4, 5]
py> from operator import mul
py> reduce(mul, mylist)
120

I would really like to see your implementation of a reduce method that turns
a list into an int *in-place*.



> Applying mutations both "in-place" and "to a copy" are 
> very helpful.

Exactly.


[snip]
>> > My point was this: All mutate methods should mutate "in-place",
>> 
>> Well duh. All mutator methods do mutate in-place, otherwise they wouldn't
>> be mutator methods.
> 
> So "reversed()" and "sorted()" mutate in-place?

No. They are not mutator methods, because they do not mutate in place.


>> > if the
>> > programmer wishes to create a mutated copy of the object, then the
>> > programmer should /explicitly/ create a copy of the object and then
>> > apply the correct mutator method to the copy.
>> 
>> Been there, done that, it sucks. That's about a dozen steps backwards to
>> a worse time in Python development.
> 
> Why? Because you have to type this
> 
>     reversed = list(seq).reverse()

Are you sure you've programmed in Python before? That gives reversed = None.


-- 
Steven

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

#38632

On 2013-02-11 00:36, Steven D'Aprano wrote:
> Rick Johnson wrote:
>
>> On Sunday, February 10, 2013 5:29:54 AM UTC-6, Steven D'Aprano wrote:
>>> Rick wrote:
>>> And you have missed my point, which is that reversed(), and sorted(),
>>> were not added to the language on a whim, but because they were
>>> requested, over and over and over again.
>>
>> Well, well, this explains everything!
>>
>> We don't add features because of logic, or because of consistency, or even
>> because of good sense, we simply add them to appease the masses.
>
I remember a time when he was saying that the developers of the
language were ignoring the silent majority. Now he's saying that we
shouldn't simply add things to appease the masses.

> They were requested because people kept re-inventing them. They kept
> re-inventing them because they are useful functions that make good sense to
> have.
>
Exactly.

Practicality beats purity, and all that.

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

#38674

On Sunday, February 10, 2013 6:36:20 PM UTC-6, Steven D'Aprano wrote:
> Rick Johnson wrote:
> > On Sunday, February 10, 2013 5:29:54 AM UTC-6, Steven D'Aprano wrote:
> >> Rick wrote:
> > [...]
> > Steven, the definition of flatten (as relates to sequences) is very, VERY
> > simple:
> > 
> >     Return a new sequence that is the result of reducing
> >     a nested sequence of sequences into a single depth
> >     sequence.
> 
> Very, VERY simple until you actually implement this function, and discover
> that it does too much e.g.

I would implement it as a method of sequence types, but i digress!

> flatten([None, 23, [1, 2, 3], Point(x=2, y=3), ["spam", "ham"]])
> => [None, 23, 1, 2, 3, 2, 3, 's', 'p', 'a', 'm', 'h', 'a', 'm']
> 
> So people who have *actually programmed*, instead of just talking about
> programming, have discovered that in practice you need to treat some
> sequences as primitives that don't get expanded.

Which primitive(s) should NOT have been expanded in your opinion? The "Point" object? I agree, that's why MY implementation would call seq.flatten() on all sub-sequences THEREBY allowing each subtype to define it's own flatten behavior. Of course the default behavior of the SequenceBase#flatten would be to flatten everything. 

However, ImmutableSequence Types would not flatten. In your example ["spam", "ham"] would not be expanded to ['s', 'p', 'a', 'm', 'h', 'a', 'm']. psst: strings and tuples are immutable!


I'm not convinced that flattening immutable types is a good idea anyway, because heck, they're designed to be immutable! I suppose if we are not flattening "in-place" it really would not matter though. Creating a new immutable object that is the result of reordering an existing immutable object's values is not mutation.

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

#38679

On Mon, Feb 11, 2013 at 11:53 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> Which primitive(s) should NOT have been expanded in your opinion? The "Point" object? I agree, that's why MY implementation would call seq.flatten() on all sub-sequences THEREBY allowing each subtype to define it's own flatten behavior. Of course the default behavior of the SequenceBase#flatten would be to flatten everything.
>
> However, ImmutableSequence Types would not flatten. In your example ["spam", "ham"] would not be expanded to ['s', 'p', 'a', 'm', 'h', 'a', 'm']. psst: strings and tuples are immutable!

So...

flatten([None, 23, [1, 2, 3], (2, 3), ["spam", "ham"]])

would return

[None, 23, 1, 2, 3, (2, 3), "spam", "ham"]

? I think that's even more unexpected.

ChrisA

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

#38723

On Monday, February 11, 2013 7:27:30 AM UTC-6, Chris Angelico wrote:

> So...
> flatten([None, 23, [1, 2, 3], (2, 3), ["spam", "ham"]])
> 
> would return
> 
> [None, 23, 1, 2, 3, (2, 3), "spam", "ham"]
> 
> I think that's even more unexpected.

Why? Are you over-analyzing? Show me a result that /does/ make you happy. 

Do you remember when i was talking about how i attempt to intuit interfaces before reading any docs? Well i have news for you Chris, what you are doing is NOT "intuiting" how flatten will work, what you are doing is "projecting" how flatten will work; these are two completely different concepts Chris.

The word "flatten" is too ambiguous to intuit the /exact/ "result". The only intuit-able attribute of flatten is that calling list.flatten() will result in a list that probably looks different than the current list. Intuition is your friend; not your own personal "clairvoyant side-kick"!

To learn the interface you need to initially "intuit", but then you need to test. Run a few example sequences and see what results you get, compare those results to what you /expected/ to get. If it works the way you expect, move on to the next topic, if not, dig deeper. 

You can't procrastinate over this method forever because NEWSFLASH you will /never/ find a perfect flatten algorithm that will please /everyone/, so just pick the most logical and consistent, and MOVE ON! 

Infinite recursion anyone?

while obj.repeat is True:
   obj.lather()
   obj.rinse()
   obj.repeat = True
   
   

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

#38728

On Mon, Feb 11, 2013 at 8:55 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Monday, February 11, 2013 7:27:30 AM UTC-6, Chris Angelico wrote:
>
>> So...
>> flatten([None, 23, [1, 2, 3], (2, 3), ["spam", "ham"]])
>>
>> would return
>>
>> [None, 23, 1, 2, 3, (2, 3), "spam", "ham"]
>>
>> I think that's even more unexpected.
>
> Why? Are you over-analyzing? Show me a result that /does/ make you happy.
>
> Do you remember when i was talking about how i attempt to intuit interfaces before reading any docs? Well i have news for you Chris, what you are doing is NOT "intuiting" how flatten will work, what you are doing is "projecting" how flatten will work; these are two completely different concepts Chris.
>
> You can't procrastinate over this method forever because NEWSFLASH you will /never/ find a perfect flatten algorithm that will please /everyone/, so just pick the most logical and consistent, and MOVE ON!

Yeah, this is where one has to consider the idea of a unified data
model (a sort of OOPv2).  Right now, it's all confused because people
are using their own internal, subconscious ideas of data.  There are
natural ways of working with data that ***actually map onto the world
we all share*** and there are other ways which are purely abstract and
not-pragmatic however "pure".   (Apart from this, there is the
ultra-concrete data model, like C, which only maps onto the machine
architecture).  This is where pretty much every computer language is
today.

What I'm suggesting I think is somewhat novel.  The first version of
OOP was too concrete in the sense that it was actually trying to make
real-world objects in the machine (class Chevy(Car):).  This is
ridiculous.  There needs to be a refactor of the OOP paradigm.  In
practice OOP never was used to represent real-world objects.  It came
to model virtual world objects, a very different world with different
relationships.  It became the evolution of the data type itself.  The
unified object model needs to do for OOP what arithmetic did for
number:  defined a very basic and general set of operations on the
concept of "quantificiation".  But here were trying to do that not for
quantification but for structures.

My suggestion is to create the "fractal graph" data type to end (and
represent) all data types.  (Keep all the special, high-speed matrix
ideas in SciPi/VPython.)  But generally, re-arrange the data model
around the fractal graph for efficiency and start watching the magic
happen.

markj
pangaia.sf.net

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

#38783

On Monday, February 11, 2013 11:28:57 PM UTC-6, zipher wrote:
> [...]
> Yeah, this is where one has to consider the idea of a unified data
> model (a sort of OOPv2).  Right now, it's all confused because people
> are using their own internal, subconscious ideas of data.

Indeed! 

The current paradigms lack concrete structures which will prevent these ever-long bickering over minutiae. Our current paradigms are actually self-defeating because they allow too much "interpretation" of what is correct, and what is incorrect. It's like the early pioneer days, cowboys everywhere. We need Wyatt Earp!

> There are
> natural ways of working with data that ***actually map onto the world
> we all share*** and there are other ways which are purely abstract and
> not-pragmatic however "pure".   (Apart from this, there is the
> ultra-concrete data model, like C, which only maps onto the machine
> architecture).  This is where pretty much every computer language is
> today.
> 
> What I'm suggesting I think is somewhat novel.  The first version of
> OOP was too concrete in the sense that it was actually trying to make
> real-world objects in the machine (class Chevy(Car):).  This is
> ridiculous.  There needs to be a refactor of the OOP paradigm.  In
> practice OOP never was used to represent real-world objects.  It came
> to model virtual world objects, a very different world with different
> relationships.  It became the evolution of the data type itself.

> The
> unified object model needs to do for OOP what arithmetic did for
> number:  defined a very basic and general set of operations on the
> concept of "quantificiation".  But here were trying to do that not for
> quantification but for structures.

Most people in the this group would probably consider this to be a fantastical idea. But aren't ALL great ideas fantastical?

From as long as man has existed he has wanted to fly like a bird -- whether his wish was based on logistical expeditiously or simply a primitive egotistical rebelliousness to overcome the limits of his own physiology.

It's no surprise that the initial attempts were naive at best and resulted in total embarrassment. When he attempted to borrow some "flight attributes" of his feathered friends by "taring-and-feathering" himself, he did /look/ like a bird, however, when he executed the "perfect 10" swan-dive from his second story cave dwelling, only to bounce his face off the granite welcome mat, he was reminded by his audience of the one bird-like feature he already had... his brain!

You see, early man wanted to fly, and knew /somehow/ it was possible, however, his folly was to attempt flight by borrowing attributes of the bird /directly/. In reality, even if could borrow /every/ flight specific attribute of the bird: light weight frame from hollow bones, large lung capacity, aerodynamic body shape and wing structure, features, etc. He would then be /himself/ a bird, and NOT a /human/ flying. Besides, a human changing into a bird is impossible... or is it?[3]

[Warning: Slight tangent curve ahead!]

I think a lot of the failure of achieving flight "hinged" around the superfluous complexity of articulated wings-- of which is something that we have trouble replicating even today with our advancements in mechanical, hydraulic, and computing technology. But articulating wings are another fine example of how "intelligent design" will always beat the pants off "evolution". The simple technology of combining "fixed wings" with "brute force propulsion" can overcome the complex design of articulating wings and gain maintainability in the process. It seems the bird should have developed a squid-like air propulsion emanating from his anus instead of articulating wings and large breast muscles; But i digress!

RR: "A billion years worth of "dice rolling" is no replacement one human imagination! Evolution, you have created your replacement; prepare for your deprecation!"

[Back to the beaten path!]

What early man failed to realize is that he should create a model of the bird, and then hitch a ride on the model! This is an example if utilizing an /indirect/ approach to solving the problem of "human flight".

However, it is still possible to solve the problem directly. Although this direct approach involves man manipulating atomic structures (using nano-technology) and then transforming cognitive state from one entity into another entity (or in-place if we're really good![1]); AKA: "Shapeshifting"

But some rules require too much time to hack, so while the brute algorthim is chewing away for the next 100 years, we need to follow these steps:
  0. Start the brute force algorithm (study nano-tech, computing)
  1. in the short term use the indirect approach (aeroplane)
  2. until the direct approach becomes attainable (shapeshifting)

> My suggestion is to create the "fractal graph" data type to end (and
> represent) all data types.  (Keep all the special, high-speed matrix
> ideas in SciPi/VPython.)  But generally, re-arrange the data model
> around the fractal graph for efficiency and start watching the magic
> happen.

This is interesting. I would love to learn more about your ideas in this direction. Do you have any writings on the subject matter?

============================================================
 REFERENCES:
============================================================

[1]: because creating a temporary entity and then destroying it could have some moral concerns at worst and possible loss of government funding[2] at best.

[2]: Of course that depends on how moral the government in question is.

[3]: I don't believe anything is impossible. If a human mind can imagine something, that something can be made reality; IF the human (or descendants) are willing to invest the time required to achieve the dream. 

It is our very imagination that creates the future. If you want Distopia, then just keep reading/writing/evangelizing about it, and if enough people accept it, it will be true! If you want utopia, well then forget about it! The universe will not allow such abominations!

Utopian environments do not propagate struggles that are life threatening; heck they probably don't contain any struggles at all! Just a bunch of fat a$$es racing around on motorized chairs down the highway of slothfulness to gorge on selfishness at the next "evolutionary dead end" buffet!

Only struggles that hang the very life of these lazy lifeforms in the balance will get their attention and force them to play the "war games" of survival, which in-turn spins the cogs of evolution to the benefit of, well, of...? Hmm. Who benefits from this eternal struggle? 

Lifeforms themselves are but pawns in the game /slaved/ to play or die, and evolution is the game itself, but who benefits? A good question that should haunt your nightmares for some time to come, sweet dreams folks!

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

#38785

On Monday, February 11, 2013 11:28:57 PM UTC-6, zipher wrote:
> [...]
> Yeah, this is where one has to consider the idea of a unified data
> model (a sort of OOPv2).  Right now, it's all confused because people
> are using their own internal, subconscious ideas of data.

Indeed! 

The current paradigms lack concrete structures which will prevent these ever-long bickering over minutiae. Our current paradigms are actually self-defeating because they allow too much "interpretation" of what is correct, and what is incorrect. It's like the early pioneer days, cowboys everywhere. We need Wyatt Earp!

> There are
> natural ways of working with data that ***actually map onto the world
> we all share*** and there are other ways which are purely abstract and
> not-pragmatic however "pure".   (Apart from this, there is the
> ultra-concrete data model, like C, which only maps onto the machine
> architecture).  This is where pretty much every computer language is
> today.
> 
> What I'm suggesting I think is somewhat novel.  The first version of
> OOP was too concrete in the sense that it was actually trying to make
> real-world objects in the machine (class Chevy(Car):).  This is
> ridiculous.  There needs to be a refactor of the OOP paradigm.  In
> practice OOP never was used to represent real-world objects.  It came
> to model virtual world objects, a very different world with different
> relationships.  It became the evolution of the data type itself.

> The
> unified object model needs to do for OOP what arithmetic did for
> number:  defined a very basic and general set of operations on the
> concept of "quantificiation".  But here were trying to do that not for
> quantification but for structures.

Most people in the this group would probably consider this to be a fantastical idea. But aren't ALL great ideas fantastical?

>From as long as man has existed he has wanted to fly like a bird -- whether his wish was based on logistical expeditiously or simply a primitive egotistical rebelliousness to overcome the limits of his own physiology.

It's no surprise that the initial attempts were naive at best and resulted in total embarrassment. When he attempted to borrow some "flight attributes" of his feathered friends by "taring-and-feathering" himself, he did /look/ like a bird, however, when he executed the "perfect 10" swan-dive from his second story cave dwelling, only to bounce his face off the granite welcome mat, he was reminded by his audience of the one bird-like feature he already had... his brain!

You see, early man wanted to fly, and knew /somehow/ it was possible, however, his folly was to attempt flight by borrowing attributes of the bird /directly/. In reality, even if could borrow /every/ flight specific attribute of the bird: light weight frame from hollow bones, large lung capacity, aerodynamic body shape and wing structure, features, etc. He would then be /himself/ a bird, and NOT a /human/ flying. Besides, a human changing into a bird is impossible... or is it?[3]

[Warning: Slight tangent curve ahead!]

I think a lot of the failure of achieving flight "hinged" around the superfluous complexity of articulated wings-- of which is something that we have trouble replicating even today with our advancements in mechanical, hydraulic, and computing technology. But articulating wings are another fine example of how "intelligent design" will always beat the pants off "evolution". The simple technology of combining "fixed wings" with "brute force propulsion" can overcome the complex design of articulating wings and gain maintainability in the process. It seems the bird should have developed a squid-like air propulsion emanating from his anus instead of articulating wings and large breast muscles; But i digress!

RR: "A billion years worth of "dice rolling" is no replacement one human imagination! Evolution, you have created your replacement; prepare for your deprecation!"

[Back to the beaten path!]

What early man failed to realize is that he should create a model of the bird, and then hitch a ride on the model! This is an example if utilizing an /indirect/ approach to solving the problem of "human flight".

However, it is still possible to solve the problem directly. Although this direct approach involves man manipulating atomic structures (using nano-technology) and then transforming cognitive state from one entity into another entity (or in-place if we're really good![1]); AKA: "Shapeshifting"

But some rules require too much time to hack, so while the brute algorthim is chewing away for the next 100 years, we need to follow these steps:
  0. Start the brute force algorithm (study nano-tech, computing)
  1. in the short term use the indirect approach (aeroplane)
  2. until the direct approach becomes attainable (shapeshifting)

> My suggestion is to create the "fractal graph" data type to end (and
> represent) all data types.  (Keep all the special, high-speed matrix
> ideas in SciPi/VPython.)  But generally, re-arrange the data model
> around the fractal graph for efficiency and start watching the magic
> happen.

This is interesting. I would love to learn more about your ideas in this direction. Do you have any writings on the subject matter?

============================================================
 REFERENCES:
============================================================

[1]: because creating a temporary entity and then destroying it could have some moral concerns at worst and possible loss of government funding[2] at best.

[2]: Of course that depends on how moral the government in question is.

[3]: I don't believe anything is impossible. If a human mind can imagine something, that something can be made reality; IF the human (or descendants) are willing to invest the time required to achieve the dream. 

It is our very imagination that creates the future. If you want Distopia, then just keep reading/writing/evangelizing about it, and if enough people accept it, it will be true! If you want utopia, well then forget about it! The universe will not allow such abominations!

Utopian environments do not propagate struggles that are life threatening; heck they probably don't contain any struggles at all! Just a bunch of fat a$$es racing around on motorized chairs down the highway of slothfulness to gorge on selfishness at the next "evolutionary dead end" buffet!

Only struggles that hang the very life of these lazy lifeforms in the balance will get their attention and force them to play the "war games" of survival, which in-turn spins the cogs of evolution to the benefit of, well, of...? Hmm. Who benefits from this eternal struggle? 

Lifeforms themselves are but pawns in the game /slaved/ to play or die, and evolution is the game itself, but who benefits? A good question that should haunt your nightmares for some time to come, sweet dreams folks!

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

#38724

On Monday, February 11, 2013 7:27:30 AM UTC-6, Chris Angelico wrote:

> So...
> flatten([None, 23, [1, 2, 3], (2, 3), ["spam", "ham"]])
> 
> would return
> 
> [None, 23, 1, 2, 3, (2, 3), "spam", "ham"]
> 
> I think that's even more unexpected.

Why? Are you over-analyzing? Show me a result that /does/ make you happy. 

Do you remember when i was talking about how i attempt to intuit interfaces before reading any docs? Well i have news for you Chris, what you are doing is NOT "intuiting" how flatten will work, what you are doing is "projecting" how flatten will work; these are two completely different concepts Chris.

The word "flatten" is too ambiguous to intuit the /exact/ "result". The only intuit-able attribute of flatten is that calling list.flatten() will result in a list that probably looks different than the current list. Intuition is your friend; not your own personal "clairvoyant side-kick"!

To learn the interface you need to initially "intuit", but then you need to test. Run a few example sequences and see what results you get, compare those results to what you /expected/ to get. If it works the way you expect, move on to the next topic, if not, dig deeper. 

You can't procrastinate over this method forever because NEWSFLASH you will /never/ find a perfect flatten algorithm that will please /everyone/, so just pick the most logical and consistent, and MOVE ON! 

Infinite recursion anyone?

while obj.repeat is True:
   obj.lather()
   obj.rinse()
   obj.repeat = True
   
   

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

#38634

On Feb 11, 9:59 am, Rick Johnson <rantingrickjohn...@gmail.com> wrote:
> We don't add features because of logic, or because of consistency,
> or even because of good sense, we simply add them to appease the masses.

When "logic" or "good sense" are writing programs, maybe then we'll
listen more to what they want in a language.

"Good sense" would dictate that someone actually read documentation
when dealing with a new programming language. "Logic" would indicate
that expecting things outside of your control to confirm with your
intuition is a fool's game; I highly recommend not reading up on any
modern physics as there'll be plenty there that just makes you angry.

PS pragmatism is a perfectly valid philosophical approach too. Far
more practical than more "pure" approaches, and something something
foolish consistency blah blah small minds.

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

#38650

On 11/02/2013 02:05, alex23 wrote:
>
> I highly recommend not reading up on any
> modern physics as there'll be plenty there that just makes you angry.
>

Spoil sport.  Fancy not wanting rr's views on string theory :)

-- 
Cheers.

Mark Lawrence

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

#38651

On Mon, Feb 11, 2013 at 6:19 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 11/02/2013 02:05, alex23 wrote:
>>
>>
>> I highly recommend not reading up on any
>> modern physics as there'll be plenty there that just makes you angry.
>>
>
> Spoil sport.  Fancy not wanting rr's views on string theory :)

Is that Unicode string theory or ASCII string theory?

Can I get a ringside seat at the debate between Rick and jmf on which
kind of string theory was the wronger decision?

ChrisA
(And on whether "wronger" is permitted on this forum. Have at it,trolls!)

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

#38654

On 11/02/2013 07:24, Chris Angelico wrote:
> On Mon, Feb 11, 2013 at 6:19 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> On 11/02/2013 02:05, alex23 wrote:
>>>
>>>
>>> I highly recommend not reading up on any
>>> modern physics as there'll be plenty there that just makes you angry.
>>>
>>
>> Spoil sport.  Fancy not wanting rr's views on string theory :)
>
> Is that Unicode string theory or ASCII string theory?
>
> Can I get a ringside seat at the debate between Rick and jmf on which
> kind of string theory was the wronger decision?
>

I guess that the black market would put the price beyond the pocket of 
the average Python programmer.

> ChrisA
> (And on whether "wronger" is permitted on this forum. Have at it,trolls!)
>

<incoming, take cover>

And I'll allow wronger as you're the righter.

</incoming, take cover>

-- 
Cheers.

Mark Lawrence

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

#38663

On Mon, 11 Feb 2013 18:24:05 +1100 Chris Angelico <rosuav@gmail.com>
wrote:
> Is that Unicode string theory or ASCII string theory?

+1 QOTW :-)

-tkc

[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