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

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

I'm wrong or Will we fix the ducks limp?

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

Contents

  I'm wrong or Will we fix the ducks limp? Sayth Renshaw <flebber.crue@gmail.com> - 2016-06-03 07:20 -0700
    Re: I'm wrong or Will we fix the ducks limp? Paul Rudin <paul.nospam@rudin.co.uk> - 2016-06-03 15:34 +0100
      Re: I'm wrong or Will we fix the ducks limp? Sayth Renshaw <flebber.crue@gmail.com> - 2016-06-03 08:04 -0700
        Re: I'm wrong or Will we fix the ducks limp? Ian Kelly <ian.g.kelly@gmail.com> - 2016-06-03 09:35 -0600
          Re: I'm wrong or Will we fix the ducks limp? Sayth Renshaw <flebber.crue@gmail.com> - 2016-06-03 08:50 -0700
            Re: I'm wrong or Will we fix the ducks limp? Michael Selik <michael.selik@gmail.com> - 2016-06-03 16:04 +0000
              Re: I'm wrong or Will we fix the ducks limp? Sayth Renshaw <flebber.crue@gmail.com> - 2016-06-03 16:06 -0700
                Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve@pearwood.info> - 2016-06-04 12:31 +1000
                  Re: I'm wrong or Will we fix the ducks limp? Christopher Reimer <christopher_reimer@icloud.com> - 2016-06-03 19:50 -0700
                    Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve@pearwood.info> - 2016-06-04 19:12 +1000
        Re: I'm wrong or Will we fix the ducks limp? Matt Wheeler <m@funkyhat.org> - 2016-06-03 15:54 +0000
          Re: I'm wrong or Will we fix the ducks limp? Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-04 20:17 -0700
            Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve@pearwood.info> - 2016-06-05 16:37 +1000
              Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-05 11:01 +0300
                Re: I'm wrong or Will we fix the ducks limp? Random832 <random832@fastmail.com> - 2016-06-05 13:53 -0400
                  Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-05 22:20 +0300
                    Re: I'm wrong or Will we fix the ducks limp? Random832 <random832@fastmail.com> - 2016-06-05 17:16 -0400
                      Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-06 11:13 +0300
                  Re: I'm wrong or Will we fix the ducks limp? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-06 13:08 +1200
                    Re: I'm wrong or Will we fix the ducks limp? Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-05 18:28 -0700
              Re: I'm wrong or Will we fix the ducks limp? Random832 <random832@fastmail.com> - 2016-06-05 13:42 -0400
                Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-05 22:38 +0300
                Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve@pearwood.info> - 2016-06-06 13:52 +1000
                  Re: I'm wrong or Will we fix the ducks limp? Random832 <random832@fastmail.com> - 2016-06-06 00:08 -0400
                    Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve@pearwood.info> - 2016-06-07 01:42 +1000
                      Re: I'm wrong or Will we fix the ducks limp? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-07 17:42 +1200
                        Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-07 20:18 +1000
                          Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-07 14:32 +0200
                            Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve@pearwood.info> - 2016-06-08 02:03 +1000
                              Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-08 10:08 +0200
                          Re: I'm wrong or Will we fix the ducks limp? Random832 <random832@fastmail.com> - 2016-06-07 11:33 -0400
                          Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-08 09:53 +0200
                            Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-08 18:47 +1000
                              Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-08 11:41 +0200
                                Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-08 11:33 +0100
                                  Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-08 13:01 +0200
                                    Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-08 13:34 +0100
                                      Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-08 16:18 +0200
                                        Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-08 19:37 +0300
                                          Re: I'm wrong or Will we fix the ducks limp? Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-08 19:49 -0700
                                          Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 09:30 +0200
                                            Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-09 12:19 +0300
                                              Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 12:19 +0200
                                                Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-09 16:13 +0300
                                            Re: I'm wrong or Will we fix the ducks limp? lists@juliensalort.org (Julien Salort) - 2016-06-09 13:46 +0200
                                              Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 14:35 +0200
                                          Re: I'm wrong or Will we fix the ducks limp? Paul Rudin <paul.nospam@rudin.co.uk> - 2016-06-09 11:00 +0100
                                            Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-09 15:56 +0300
                                              Re: I'm wrong or Will we fix the ducks limp? Paul Rudin <paul.nospam@rudin.co.uk> - 2016-06-09 15:09 +0100
                                                Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-09 18:14 +0300
                                                  Re: I'm wrong or Will we fix the ducks limp? Paul Rudin <paul.nospam@rudin.co.uk> - 2016-06-09 17:22 +0100
                                                    Re: I'm wrong or Will we fix the ducks limp? Paul Rudin <paul.nospam@rudin.co.uk> - 2016-06-09 17:48 +0100
                                                    Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-09 22:35 +0300
                                                  Re: I'm wrong or Will we fix the ducks limp? Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-06-10 08:31 +0300
                                          Re: I'm wrong or Will we fix the ducks limp? Random832 <random832@fastmail.com> - 2016-06-09 14:36 -0400
                                        Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-08 18:29 +0100
                                          Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 09:50 +0200
                                            Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-09 10:10 +0100
                                              Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 11:55 +0200
                                                Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-09 11:48 +0100
                                                  Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 13:08 +0200
                                                    Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-09 13:25 +0100
                                                      Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 14:48 +0200
                                    Re: I'm wrong or Will we fix the ducks limp? Rustom Mody <rustompmody@gmail.com> - 2016-06-08 05:36 -0700
                                Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-09 17:36 +1000
                                  Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 11:46 +0200
                                    Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-09 13:03 +0300
                                      Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-09 11:42 +0100
                                    Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-09 11:53 +0100
                                      Re: I'm wrong or Will we fix the ducks limp? Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-06-09 13:56 +0300
                                      Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 13:19 +0200
                                        Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-09 13:17 +0100
                                          Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 14:59 +0200
                  Re: I'm wrong or Will we fix the ducks limp? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-06 18:37 +1200
                    Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve@pearwood.info> - 2016-06-07 02:19 +1000
                      Re: I'm wrong or Will we fix the ducks limp? Random832 <random832@fastmail.com> - 2016-06-06 12:57 -0400
                        Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve@pearwood.info> - 2016-06-07 04:59 +1000
                          Re: I'm wrong or Will we fix the ducks limp? Random832 <random832@fastmail.com> - 2016-06-06 17:13 -0400
                            Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-07 00:47 +0300
                              Re: I'm wrong or Will we fix the ducks limp? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-07 19:03 +1200
                                Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-07 10:56 +0300
                                  Re: I'm wrong or Will we fix the ducks limp? Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-06-07 11:41 +0300
                                  Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-07 11:49 +0100
                                Re: I'm wrong or Will we fix the ducks limp? Random832 <random832@fastmail.com> - 2016-06-07 11:14 -0400
                                  Re: I'm wrong or Will we fix the ducks limp? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-08 17:59 +1200
                          Re: I'm wrong or Will we fix the ducks limp? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-07 18:33 +1200
                            Re: I'm wrong or Will we fix the ducks limp? Chris Angelico <rosuav@gmail.com> - 2016-06-07 16:55 +1000
                      Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-06 22:55 +0100
                      Re: I'm wrong or Will we fix the ducks limp? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-07 18:20 +1200
                  Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-06 11:23 +0200
                    Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-06 13:10 +0300
                  Re: I'm wrong or Will we fix the ducks limp? Chris Angelico <rosuav@gmail.com> - 2016-06-06 21:57 +1000
              Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-06 13:35 +0100
            Re: I'm wrong or Will we fix the ducks limp? Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-05 18:25 -0700
    Re: I'm wrong or Will we fix the ducks limp? Peter Pearson <pkpearson@nowhere.invalid> - 2016-06-03 16:05 +0000
      Re: I'm wrong or Will we fix the ducks limp? Sayth Renshaw <flebber.crue@gmail.com> - 2016-06-03 16:09 -0700
        Re: I'm wrong or Will we fix the ducks limp? cs@zip.com.au - 2016-06-06 08:41 +1000
    Re: I'm wrong or Will we fix the ducks limp? Nagy László Zsolt <gandalf@shopzeus.com> - 2016-06-03 18:11 +0200
      Re: I'm wrong or Will we fix the ducks limp? Sayth Renshaw <flebber.crue@gmail.com> - 2016-06-03 16:11 -0700
    Re: I'm wrong or Will we fix the ducks limp? Terry Reedy <tjreedy@udel.edu> - 2016-06-03 22:12 -0400
    Re: I'm wrong or Will we fix the ducks limp? jfine2358@gmail.com - 2016-06-06 07:32 -0700

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#109415 — I'm wrong or Will we fix the ducks limp?

Very briefly because I hope to shot down eloquently.

Python is beautiful and is supposed to be a duck typed language, Yes?

Then if I create and assign to a new variable with a list action why does the duck not quack?

It feels wrong to spend a line writing what is already obvious

def getsMeet(files=file_list):
    """Get a File or List of Files.

    From the list of files determine
    what meetings exist and prepare them
    to be parsed
    """
    pyqFiles = []
    for filename in sorted(file_list):
        pyqFiles = pyqFiles.append(pq(filename=my_dir + filename))

    return pyqFiles


Here I have to write that pyqFiles is a list before I take an explicit list action and append to it, if i create a variable and make it quack a list isn't it a list?

Assuming the answer is going to be that some methods apply to multiple types if not then what is happening?

Sayth

PS I am really having a lot of fun coding.

[toc] | [next] | [standalone]

#109417

Sayth Renshaw <flebber.crue@gmail.com> writes:

> Very briefly because I hope to shot down eloquently.
>
> Python is beautiful and is supposed to be a duck typed language, Yes?
>
> Then if I create and assign to a new variable with a list action why
> does the duck not quack?
>
> It feels wrong to spend a line writing what is already obvious
>

The problem is that you think that *variables* have a type. This isn't
the case. Objects have a type. A variable is a name by which you can
refer to an object. There are various ways in which you can associate a
object with a variable, the most obvious being an assignment statement.

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

#109419

> The problem is that you think that *variables* have a type. This isn't
> the case. Objects have a type. A variable is a name by which you can
> refer to an object. There are various ways in which you can associate a
> object with a variable, the most obvious being an assignment statement.

So at the point I create the variable it refers to an object.

More correctly when I create the variable and assign a list action to the variable I believe I should be creating a reference to a list object in one motion; however python would like me to create the object first before creating a reference to it, is that the catch?

I am not allowed to create references to an object at the same time I create the object is that correct?

Sayth

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

#109421

On Fri, Jun 3, 2016 at 9:04 AM, Sayth Renshaw <flebber.crue@gmail.com> wrote:
>
>
>> The problem is that you think that *variables* have a type. This isn't
>> the case. Objects have a type. A variable is a name by which you can
>> refer to an object. There are various ways in which you can associate a
>> object with a variable, the most obvious being an assignment statement.
>
> So at the point I create the variable it refers to an object.
>
> More correctly when I create the variable and assign a list action to the variable I believe I should be creating a reference to a list object in one motion; however python would like me to create the object first before creating a reference to it, is that the catch?
>
> I am not allowed to create references to an object at the same time I create the object is that correct?

I'd say leave references out of this. They don't correspond 1:1 with
variables, and bringing them up is only going to confuse the issue.

When you call the append method you're not "assigning a list action"
to the variable. You're just trying to call a method named "append".
That could be the list append method. Or it could be the array append
method. Or the deque append method. Or you may have written your own
class with an append method. How is the interpreter supposed to know
which one you mean?

In general, it can't, so it doesn't try. You have to create an object
before you can start doing anything it.

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

#109422

That totally makes sense I was just double checking, had hoped I could create a variable assign it to a list and append in one stroke. 

Thanks 

Sayth 

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

#109426

On Fri, Jun 3, 2016 at 11:58 AM Sayth Renshaw <flebber.crue@gmail.com>
wrote:

> That totally makes sense I was just double checking, had hoped I could
> create a variable assign it to a list and append in one stroke.
>

In fact you can! It's called a "list comprehension"

    pyqFiles = [pq(my_dir + filename) for filename in sorted(file_list)]

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

#109441

On Saturday, 4 June 2016 02:04:43 UTC+10, Michael Selik  wrote:

> 
> > That totally makes sense I was just double checking, had hoped I could
> > create a variable assign it to a list and append in one stroke.
> >
> 
> In fact you can! It's called a "list comprehension"
> 
>     pyqFiles = [pq(my_dir + filename) for filename in sorted(file_list)]

Actually thats where I was coming from I can create a list with a list comprehension in one go, but I cant create a list with an append method pf.append(thing) in one go .

Sayth

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

#109458

On Sat, 4 Jun 2016 09:06 am, Sayth Renshaw wrote:

> I cant create a list with an append method pf.append(thing) in one go .

Correct. You cannot append to a list until the list exists.

Nor can you uppercase a string until the string exists:

s = "hello world"
s = s.uppercase()


Nor can you add one to a number until the number exists.

x = 0
x += 1


Why should lists be different? How is Python supposed to know pf is a list
with an append method if pf doesn't exist?

# pf = []
pf.append(thing)



-- 
Steven

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

#109464

On 6/3/2016 7:31 PM, Steven D'Aprano wrote:

> On Sat, 4 Jun 2016 09:06 am, Sayth Renshaw wrote:
>
>> I cant create a list with an append method pf.append(thing) in one go .
> Correct. You cannot append to a list until the list exists.
>
> Nor can you uppercase a string until the string exists:
>
> s = "hello world"
> s = s.uppercase()

 >>> s = "hello world".upper()
 >>> print(s)
HELLO WORLD

This works in Python 3. Not sure if s.uppercase() was meant as an 
example for a different language.

Chris R.

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

#109471

On Sat, 4 Jun 2016 12:50 pm, Christopher Reimer wrote:

>> Nor can you uppercase a string until the string exists:
>>
>> s = "hello world"
>> s = s.uppercase()
> 
>  >>> s = "hello world".upper()
>  >>> print(s)
> HELLO WORLD


"hello world" creates a string. Then you call .upper() on that string.

Perhaps a better example (demonstrating the impossibility) would be:

s = .upper()

but I thought that would not be clear.


> This works in Python 3. Not sure if s.uppercase() was meant as an
> example for a different language.

Nope, just not the clearest example.



-- 
Steven

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

#109424

Hi,

On Fri, 3 Jun 2016, 16:04 Sayth Renshaw, <flebber.crue@gmail.com> wrote:

>
> So at the point I create the variable it refers to an object.
>

It's best to think of them as names, rather than variables, as names in
python don't behave quite how you'll expect variables to if you're coming
from some other languages.

More correctly when I create the variable and assign a list action to the
> variable I believe I should be creating a reference to a list object in one
> motion; however python would like me to create the object first before
> creating a reference to it, is that the catch?
>

I'm not 100% sure what you mean by "assign a list action to the variable".

`[]` is an empty list literal. Putting that in your code will create a new
empty list object every time it's reached.
`name =` assigns a new name which refers to the thing to the right of it.

My best guess as to the source of your confusion is that you're not seeing
the list as an object (let me know if I'm wrong).
A list is an object just the same as the items you want to put in it, it's
just a different type, it's not special syntax built into the language.
That means you need to create one if you want it to be there.

I am not allowed to create references to an object at the same time I
> create the object is that correct?
>

That's exactly what `name = []` is doing (see above).

> Assuming the answer is going to be that some methods apply to multiple
types if not then what is happening?
[from your first email]

If you want to see it like this that might help. Any number of classes and
not just the builtin list is likely to have an append method.
Even if that were not true, expecting name.append() in a context where name
doesn't exist to somehow magically create a list object for you, assign a
name to it and then call the method you asked for would involve quite a few
leaps of logic, faith or something.

Consider a situation where you actually intended to create an instance of a
different type which also has an `.append()` method, but somehow that went
wrong (you spelt the name incorrectly, perhaps), which is preferable:

Magic list creation mode:
>>> name = OtherClassWithAppendMethod()
>>> naem.append('this')
Great. Now we have our desired OtherClassWithAppendMethod instance, which
is empty, and a useless list which contains the stuff that should have been
given to `name`.
No errors, just a bug that's really really fun to track down.

Regular boring Python:
>>> name = OtherClassWithAppendMethod()
>>> naem.append('this')
NameError: name 'naem' is not defined

>

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

#109490

On Saturday, June 4, 2016 at 3:55:12 AM UTC+12, Matt Wheeler wrote:
> It's best to think of them as names, rather than variables, as names in
> python don't behave quite how you'll expect variables to if you're coming
> from some other languages.

I have made heavy use of Python as well as many other languages, and I don’t know what you mean. What “other languages” are you thinking of?

Are variables like little boxes? Yes they are. But they are all the same size, while objects may be large (even very large) or small. That is why variables hold, not objects, but references to objects.

(This makes no difference for immutable objects, only mutable ones.)

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

#109496

On Sun, 5 Jun 2016 01:17 pm, Lawrence D’Oliveiro wrote:

> On Saturday, June 4, 2016 at 3:55:12 AM UTC+12, Matt Wheeler wrote:
>> It's best to think of them as names, rather than variables, as names in
>> python don't behave quite how you'll expect variables to if you're coming
>> from some other languages.
> 
> I have made heavy use of Python as well as many other languages, and I
> don’t know what you mean. What “other languages” are you thinking of?
> 
> Are variables like little boxes? Yes they are. 

That's *exactly* what variables in Python are not like.


> But they are all the same 
> size, while objects may be large (even very large) or small. That is why
> variables hold, not objects, but references to objects.

No they don't. You are confusing the implementation with the programming
model.

Following the assignment:

x = 99

if you print(x), do you see something like "reference 0x12345"? No.

Do you have to dereference that reference to get the value of x? No.

At the Python level, the value of x is 99, not some invisible, untouchable
reference to 99.

There is no analog to dereferencing in Python, nothing like print(x^). You
bind values (that is, objects) directly to names, and names (variables)
hold their value, not a reference to their value.

The fact that for some implementations that is implemented using references
of some sort or another (e.g. pointers in CPython) is an implementation
detail which is irrelevant to the language and its execution model.



-- 
Steven

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

#109504

Steven D'Aprano <steve@pearwood.info>:

> On Sun, 5 Jun 2016 01:17 pm, Lawrence D’Oliveiro wrote:
>> Are variables like little boxes? Yes they are. 
>
> That's *exactly* what variables in Python are not like.

Of course they are.

Or, rather, the little-box mental model is no worse than any other.

You could also think of variables as pegs, references as leashes, and
objects as cute puppies. One puppy could be held with multiple leashes
hung on separate pegs. Some puppies hold leashes in their mouths. Every
leash is tied to a puppy or a special wooden post called None.

>> But they are all the same size, while objects may be large (even very
>> large) or small. That is why variables hold, not objects, but
>> references to objects.
>
> No they don't. You are confusing the implementation with the
> programming model.

The easiest way to understand the references of Java, Python, Lisp and
others is through an underlying implementation. I really haven't seen a
better abstract model presented.

(An alternate model could be the semantics of lambda calculus, which
doesn't have a data model at all! Instead, the semantics are given
through the execution model: a form is repeatedly transformed to new
forms until no transformation is allowed by the rules. That kind of
model would not suit Python, though, because Python's little boxes can
be assigned to.)

> Following the assignment:
>
> x = 99
>
> if you print(x), do you see something like "reference 0x12345"? No.

Irrelevant. The statement "print(x)" does not print a variable but the
result of the evaluation of the given expression.

> There is no analog to dereferencing in Python, nothing like print(x^).

True, variables are not first-class objects in Python.

(However, Guido could add first-class status to variables to Python with
the snap of his fingers in a 100%-backwards-compatible manner.)

> You bind values (that is, objects) directly to names, and names
> (variables) hold their value, not a reference to their value.

That mental model seems more confusing than the little-box one.

> The fact that for some implementations that is implemented using
> references of some sort or another (e.g. pointers in CPython) is an
> implementation detail which is irrelevant to the language and its
> execution model.

The references cannot be removed from Python's data model. In fact, they
haven't been:

   The value of an immutable container object that contains a REFERENCE
   to a mutable object can change when the latter’s value is changed;

   [...]

   Some objects contain REFERENCES to other objects; these are called
   containers. Examples of containers are tuples, lists and
   dictionaries. The REFERENCES are part of a container’s value. In most
   cases, when we talk about the value of a container, we imply the
   values, not the identities of the contained objects; however, when we
   talk about the mutability of a container, only the identities of the
   immediately contained objects are implied. So, if an immutable
   container (like a tuple) contains a REFERENCE to a mutable object,
   its value changes if that mutable object is changed.

   Types affect almost all aspects of object behavior. Even the
   importance of object identity is affected in some sense: for
   immutable types, operations that compute new values may actually
   return a REFERENCE to any existing object with the same type and
   value, while for mutable objects this is not allowed. E.g., after a =
   1; b = 1, a and b may or may not REFER to the same object with the
   value one, depending on the implementation, but after c = []; d = [],
   c and d are guaranteed to REFER to two different, unique, newly
   created empty lists. (Note that c = d = [] assigns the same object to
   both c and d.)

   [etc etc]

   <URL: https://docs.python.org/3/reference/datamodel.html>
   (capitalization is mine)


Marko

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

#109521

On Sun, Jun 5, 2016, at 04:01, Marko Rauhamaa wrote:
> You could also think of variables as pegs, references as leashes, and
> objects as cute puppies. One puppy could be held with multiple leashes
> hung on separate pegs. Some puppies hold leashes in their mouths. Every
> leash is tied to a puppy or a special wooden post called None.

You've got it all wrong about what's special about None.  The object is
just another puppy. There *is* a variable called None
[getattr(__builtins__, 'None')] which holds a leash tied to that puppy,
but it's rarely used, since everyone knows how to find that puppy
directly [None is a keyword]. But nothing's special about the object
itself, no more than any other object.

Of course, as the fact that I had to use __builtins__ shows, the "pegs"
are a fiction. At least, as long as we consider that frames and modules
are just another kind of puppy. Though I suppose technically frames are
an implementation detail.

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

#109523

Random832 <random832@fastmail.com>:

> On Sun, Jun 5, 2016, at 04:01, Marko Rauhamaa wrote:
>> You could also think of variables as pegs, references as leashes, and
>> objects as cute puppies. One puppy could be held with multiple
>> leashes hung on separate pegs. Some puppies hold leashes in their
>> mouths. Every leash is tied to a puppy or a special wooden post
>> called None.
>
> You've got it all wrong about what's special about None. The object is
> just another puppy. There *is* a variable called None
> [getattr(__builtins__, 'None')] which holds a leash tied to that
> puppy, but it's rarely used, since everyone knows how to find that
> puppy directly [None is a keyword]. But nothing's special about the
> object itself, no more than any other object.

I say None is a wooden post, you say None is a puppy.

What piece of Python code could put our dispute to rest?


Marko

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

#109526

On Sun, Jun 5, 2016, at 15:20, Marko Rauhamaa wrote:
> I say None is a wooden post, you say None is a puppy.
> 
> What piece of Python code could put our dispute to rest?

isinstance(None, object)

Anyway, I read the "wooden post" claim as suggesting that a reference to
None is somehow different from other references, as null in C# or Java
is different from an object reference in those languages.

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

#109549

Random832 <random832@fastmail.com>:

> On Sun, Jun 5, 2016, at 15:20, Marko Rauhamaa wrote:
>> I say None is a wooden post, you say None is a puppy.
>> 
>> What piece of Python code could put our dispute to rest?
>
> isinstance(None, object)

Well, the wooden post is an object as are all puppies.

It's bad enough to objectify sentient beings; I just don't have the
heart to put a cute, fluffy puppy in the role of None. The fact that
CPython does that could be considered animal cruelty.


Marko

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

#109530

Random832 wrote:
> There *is* a variable called None
> [getattr(__builtins__, 'None')] which holds a leash tied to that puppy
> ... But nothing's special about the object
> itself, no more than any other object.

The only special-ish thing about it is that it's unique --
there will never be another one like it, no matter how
much dog breeding you do. Fortunately, it's also immortal.

It's not the only puppy with that property, though.
For instance, there's the pair True and False, born
of the same litter but of quite opposite temperaments.
And type, the ancient mother of all canines.

-- 
Greg

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

#109532

On Monday, June 6, 2016 at 1:08:21 PM UTC+12, Gregory Ewing wrote:
> The only special-ish thing about [None] is that it's unique --
> there will never be another one like it, no matter how
> much dog breeding you do. Fortunately, it's also immortal.

Maybe not immortal, but it seems to have 533 lives.

Anybody who writes a C extension module for Python knows that Py_None is an object just like any other, and has to be treated the same in terms of managing its reference counts.

(That’s how many unbalanced calls I had to make to Py_DECREF(Py_None) before it crashed Python.)

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

Page 1 of 6  [1] 2 3 4 5 6  Next page →

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

csiph-web