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 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

#109612

Gregory Ewing <greg.ewing@canterbury.ac.nz>:

> Marko Rauhamaa wrote:
>> Seriously, though, it is notable that the high-level programming
>> languages pretty unanimously refuse to make variables first-class
>> objects. I wonder why.
>
> That's an interesting question. One reason might be
> that in the absence of static type analysis, assigning
> to a variable holding a reference to another variable
> would be ambiguous. For example, suppose Python had
> an & operator that gives you an object referring to
> a variable somehow. Then, after
>
> a = 42
> b = 17
> c = &a
> c = &b
>
> does 'c' now hold a reference to the variable 'b', or
> does it still hold a reference to 'a' and 'a' now
> holds a reference to 'b'?

If variables were ordinary mutable objects, you'd need a syntax of
dereferencing, just like in C. Variable objects would be highly
analogous to single-element arrays, little boxes if you will.

> Somehow these two operations would have to be spelled different ways,
> which means you would need to know whether you were dealing with a
> variable reference or not. So they wouldn't really be first-class, in
> the sense of being treated on an equal footing with ordinary
> variables.

It's not that ambiguous.

   >>> a = 3
   >>> c = &a
   >>> c
   <global variable a>
   >>> *c
   3
   >>> c is a
   False
   >>> *c is a
   True
   >>> c is &a
   True
   >>> a = 4
   >>> *c
   4
   >>> *c is a
   True
   >>> c = &c
   >>> c
   <global variable c>
   >>> *c
   <global variable c>
   >>> **c
   <global variable c>


Marko

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

#109615

Marko Rauhamaa <marko@pacujo.net> writes:

> Gregory Ewing <greg.ewing@canterbury.ac.nz>:
>
>> Marko Rauhamaa wrote:
>>> Seriously, though, it is notable that the high-level programming
>>> languages pretty unanimously refuse to make variables first-class
>>> objects. I wonder why.
>>
>> That's an interesting question. One reason might be
>> that in the absence of static type analysis, assigning
>> to a variable holding a reference to another variable
>> would be ambiguous. For example, suppose Python had
>> an & operator that gives you an object referring to
>> a variable somehow. Then, after
>>
>> a = 42
>> b = 17
>> c = &a
>> c = &b
>>
>> does 'c' now hold a reference to the variable 'b', or
>> does it still hold a reference to 'a' and 'a' now
>> holds a reference to 'b'?
>
> If variables were ordinary mutable objects, you'd need a syntax of
> dereferencing, just like in C. Variable objects would be highly
> analogous to single-element arrays, little boxes if you will.

I've had this little piece lying around ever since there last was a
discussion about assignments as expressions. It abuses the ** operator
to store values in boxes; the value of 'expression ** x' is the value of
'expression', with the side effect that afterwards the value of x.it
(the dereferencing!) is also whatever the value of 'expression' was.

class Box(object):
    '''Read ** as as and x.it as whatever was saved as x.'''
    def __init__(self, init = None):
        self.it = init
    def __rpow__(self, it): # f() ** self
        self.it = it
        return self.it

data = iter('piäsiäntösesti ee näen')
from string import ascii_letters as ascii

x, y = Box(), Box()
while (next(data) ** x in ascii and
       next(data) ** y in ascii):
    print(x.it, y.it)
# Prints one line: p i

There's a further test case in that file, saving the regex match object
during the expression that tests whether there was a match object. Not
entirely satisfactory, but perhaps mildly interesting.

import re
beg = re.compile(r'start=(\w+)')
end = re.compile(r'finis=(\w+)')

b, e = Box(), Box()
for k, line in enumerate(('xxx',
                          '# start=eka rivi',
                          'ween',
                          'ween',
                          '# finis=vika rivi',
                          'xxx')):
    if not b.it and beg.search(line) ** b:
        print(k, b.it.group(1))
    elif b.it and end.search(line) ** e:
        print(k, e.it.group(1))
        break
    elif b.it:
        print(k, line)
# Prints four lines:
# 1 eka 
# 2 ween
# 3 ween
# 4 vika

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

#109619

On 07/06/2016 08:56, Marko Rauhamaa wrote:
> Gregory Ewing <greg.ewing@canterbury.ac.nz>:
>
>> Marko Rauhamaa wrote:
>>> Seriously, though, it is notable that the high-level programming
>>> languages pretty unanimously refuse to make variables first-class
>>> objects. I wonder why.
>>
>> That's an interesting question. One reason might be
>> that in the absence of static type analysis, assigning
>> to a variable holding a reference to another variable
>> would be ambiguous. For example, suppose Python had
>> an & operator that gives you an object referring to
>> a variable somehow. Then, after
>>
>> a = 42
>> b = 17
>> c = &a
>> c = &b
>>
>> does 'c' now hold a reference to the variable 'b', or
>> does it still hold a reference to 'a' and 'a' now
>> holds a reference to 'b'?

c points to b. For the latter part of your statement to be true, the 
last line might have to be something like:

  *c = &b

>> Somehow these two operations would have to be spelled different ways,
>> which means you would need to know whether you were dealing with a
>> variable reference or not. So they wouldn't really be first-class, in
>> the sense of being treated on an equal footing with ordinary
>> variables.
>
> It's not that ambiguous.
>
>    >>> a = 3
>    >>> c = &a
>    >>> c
>    <global variable a>
>    >>> *c
>    3
>    >>> c is a
>    False
>    >>> *c is a
>    True
>    >>> c is &a
>    True
>    >>> a = 4
>    >>> *c
>    4
>    >>> *c is a
>    True
>    >>> c = &c
>    >>> c
>    <global variable c>
>    >>> *c
>    <global variable c>
>    >>> **c
>    <global variable c>


Here are some results in another, non-Python language. While the object 
reference module is similar to Python's, the language retains explicit 
pointers which can be used for variable references.

In this code, ^x means pointer to x, x^ means dereference c, while := is 
assignment and = means equality:

a := 3
c := ^a

println c               # refvar: 02176228

println c = a           # error (compare pointer to int)
println c = ^a          # True

a := 4
println c^              # 4

c^ := 12
println a               # 12

c := ^c
println c               # refvar: 02176248
println c^              # refvar: 02176248
println c^^             # refvar: 02176248

Associating a pointer value to a variable symbol table entry is a 
separate step. But a pointer needn't point at just a named variable:

a := (10,20,30,40,50)
c := ^a[3]

println c^              # 30 (was 1-based)

c^ := 77
println a               # (10,20,77,40,50)


And here is the above example:

a := 42
b := 17
c := ^a
c^ := ^b

println a               # refvar: 21A16F0
println a^              # 17

-- 
Bartc

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

#109628

On Tue, Jun 7, 2016, at 03:03, Gregory Ewing wrote:
> a = 42
> b = 17
> c = &a
> c = &b
> 
> does 'c' now hold a reference to the variable 'b', or
> does it still hold a reference to 'a' and 'a' now
> holds a reference to 'b'?

It'd have to be spelled *c = &b, or c.value = &b or c.setvalue(&b), or
something like that, to mean the latter.

> Somehow these two operations would have to be spelled
> different ways, which means you would need to know
> whether you were dealing with a variable reference or
> not. So they wouldn't really be first-class, in the
> sense of being treated on an equal footing with
> ordinary variables.

Er, how would that make them not first class? Lots of operations need to
be spelled differently, that's why we have so many operators, attribute
lookup syntax, etc. "Assign to the variable object that is in this
variable" would be a distinct operation from "Assign to this variable",
just like "add one to this value" or "call this function" etc.

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

#109657

Random832 wrote:
> Er, how would that make them not first class?

They wouldn't be as transparent as references in C++,
which you just assign to like any other variable.

That works because C++ makes a distinction between
initialisation and assignment. It's not so easy to
separate those in Python.

> "Assign to the variable object that is in this
> variable" would be a distinct operation from "Assign to this variable",
> just like "add one to this value" or "call this function" etc.

That would be like pointers in C that you have
to explicitly dereference. I'm not sure whether
C could be described as having "first class
variables", though.

If transparency is not required, you can easily
create wrapper objects in Python that refer
to an attribute or element of an object.

-- 
Greg

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

#109606

Steven D'Aprano wrote:
> I think I'm on
> fairly solid ground to say that a language that is just like C except that
> it allocates variables in a hash table at runtime, using runtime lookups
> for variable access, would not satisfy the C89 or C99 standards.

I wouldn't be so sure about that. Modern C standards are
pretty careful to avoid making any promises about how
things are laid out in memory, etc.

It wouldn't surprise me much if you could come up with
such an implementation that adheres to the strict letter
of the standard. It also wouldn't surprise me if that
implementation failed to run a large proportion of
real C code out there, though...

-- 
Greg

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

#109607

On Tue, Jun 7, 2016 at 4:33 PM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> Steven D'Aprano wrote:
>>
>> I think I'm on
>> fairly solid ground to say that a language that is just like C except that
>> it allocates variables in a hash table at runtime, using runtime lookups
>> for variable access, would not satisfy the C89 or C99 standards.
>
>
> I wouldn't be so sure about that. Modern C standards are
> pretty careful to avoid making any promises about how
> things are laid out in memory, etc.
>
> It wouldn't surprise me much if you could come up with
> such an implementation that adheres to the strict letter
> of the standard. It also wouldn't surprise me if that
> implementation failed to run a large proportion of
> real C code out there, though...

Without having read any of the specs, my guess is you could be C89/C99
compliant putting all your "simple variables" into the hash table -
int, char, float, double, etc - but keep all your arrays and structs
in "real memory". There's no reason a CPU couldn't be built with fifty
million registers available, and the compiler could just put all those
scalars into registers (assuming you never take their addresses, in
which case they then need to have them).

ChrisA

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

#109595

On 06/06/2016 17:19, Steven D'Aprano wrote:

> (2) The "variables are like boxes" metaphor applies to static languages like
> C and Pascal, where the compiler has knowledge of what variables will
> exist. Such languages allocate space for the variables at compile time,
> usually using fixed memory locations on the stack, or in registers, but
> rarely dynamically in the heap. That's exactly what Python doesn't do.

With sane programs of the kind I would write, variables appear in the 
source code:

  a = b

Thus they are known to the compiler and can be given special treatment 
compared to any that there might be in an exec() string.

That the language allows the internal entries required for such names to 
be 'deleted', or not to create them at all in code such as:

    if cond:
       b = 10

(when cond is false) is another matter. A disassembly will clearly show 
the name "b". And it would be ludicrous to suggest that here:

  pass    # 1
  a = 0   # 2
  pass    # 3

"a" doesn't exist at all at line 1 or at the start of line 2, and only 
comes fully into existence by line 3. "a" exists by name in the 
byte-code as well as the source code from the start.

a is a variable.

-- 
Bartc

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

#109605

Steven D'Aprano wrote:

> I never said that the string "x" is the same thing as the variable x.

Maybe you didn't, but some people insist we shouldn't use
the term "variable" when talking about python, but use
"name" instead. I was pointing out that those two words
don't have the same connotations.

-- 
Greg

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

#109551

Op 06-06-16 om 05:52 schreef Steven D'Aprano:
> On Mon, 6 Jun 2016 03:42 am, Random832 wrote:
>
>> On Sun, Jun 5, 2016, at 02:37, Steven D'Aprano wrote:
>>> 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.
>> Sure, but that is the value of the object referenced by x, it is not a
>> property of x itself.
> You need to be clear about what you are referring to.
>
> x itself is the object 99. When we say "x + 1", we expect to get 100. x is
> not some reference to 99, it is 99, just like Barrack Obama is not a
> reference to the President of the United States, he is the POTUS.

x is not the object 99. x is a variable that refers to an object that
has the value 99. That python starts looking for that object and
uses its value when your do arithmatics doesn't contradict that variables
refer to objects.

A reference is not pointer. When you use a reference parameter in Pascal,
it behave like an ordinary parameter within the procedure block, you don't
have to treat it like a pointer.

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

#109553

Antoon Pardon <antoon.pardon@rece.vub.ac.be>:

> A reference is not pointer. When you use a reference parameter in
> Pascal, it behave like an ordinary parameter within the procedure
> block, you don't have to treat it like a pointer.

The word "reference" as used in the Python standards documentation is
not the same as "reference parameter in Pascal." Even more confusing, we
have "The Python Language Reference," which uses the word in yet a third
meaning!

Python's reference *is* indeed a pointer, even though there's usually no
need to bring the word "pointer" in the discussion. A "reference",
"pointer", "arrow", "leash", "morphism" etc are abstract thingies that
connect a starting point to an endpoint. (No wonder Java, whose
terminology involves references as well, sports a NullPointerException.)


Marko

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

#109554

On Mon, Jun 6, 2016 at 2:08 PM, Random832 <random832@fastmail.com> wrote:
> My statement was that if two variables can be bound to the same object,
> then variables *cannot* contain objects. The object has to exist
> somewhere, and this requirement means that the variables cannot be where
> the objects live.

Then the problem is with your notion of containment. Have a think
about TARDISes, and the place the Narnians got to after the Last
Battle, and Bags of Holding, and various other related concepts. It's
perfectly possible for something to be 'inside' more than one thing at
once.

ChrisA

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

#109556

On 05/06/2016 07:37, Steven D'Aprano wrote:
> 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.

People can imagine a box around a variable name if they like.

The confusion might arise when they think the value attached to the name 
is in the same box. But often, for variables holding or referring to 
simple scalar values, it doesn't matter.

>
>> 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.

Nearly every high level language will perform an automatic dereference 
in such cases, between the written name of the variable (that sometimes 
corresponds to its /address/), and its value (for example, the contents 
of that address).

In Python there might well be a double dereference, from name to 
location, which contains an object reference, and from the object 
reference to the value that is printed.

While Python can give you access to the object reference rather than the 
object value, AFAIK you can't get the location where that object 
reference is stored for that variable. All you have is the name.

So for Python it makes more sense to have two boxes, one for the name, 
and another for the object value. With an arrow between the two. (Among 
other things, this allows same object to be shared between several 
variables: multiple boxed variable names all pointing to the same object 
box.)

But again, in the case of simple, immutable types, and where the 
variable always keeps the same type as is usually the case, there is no 
real problem in showing "x" and "99" in the same box, or "99" in the box 
and "x" immediately outside:

  x:[99]

instead of:

  x:[0x12345] -> 0x12345:[99]

-- 
Bartc

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

#109531

On Sunday, June 5, 2016 at 3:18:05 PM UTC+12, I wrote:

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

I retract this part.

Thanks, Marko, for showing me where I was wrong. :)

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

#109427

On Fri, 3 Jun 2016 07:20:24 -0700 (PDT), Sayth Renshaw wrote:
[snip]
>     pyqFiles = []
>     for filename in sorted(file_list):
>         pyqFiles = pyqFiles.append(pq(filename=my_dir + filename))
>
>     return pyqFiles

[snip]
> PS I am really having a lot of fun coding.

To have even more fun, note that the above can be replaced by [untested]:

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

(By the way, the "pf = pf.append(thing)" construction is weird.
All you need is pf.append(thing).)

-- 
To email me, substitute nowhere->runbox, invalid->com.

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

#109442

> >     pyqFiles = []
> >     for filename in sorted(file_list):
> >         pyqFiles = pyqFiles.append(pq(filename=my_dir + filename))
> >
> >     return pyqFiles
> 
> [snip]
> > PS I am really having a lot of fun coding.
> 
> To have even more fun, note that the above can be replaced by [untested]:
> 
>     return [pq(filename=my_dir + filename)
>             for filename in sorted(file_list)]
> 
> (By the way, the "pf = pf.append(thing)" construction is weird.
> All you need is pf.append(thing).)
> 
> -- 
>

I got the pf = pf.append(thing) from doing pandas because in pandas its not an inplace function.

Sayth

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

#109527

On 03Jun2016 16:09, Sayth Renshaw <flebber.crue@gmail.com> wrote:
>> (By the way, the "pf = pf.append(thing)" construction is weird.
>> All you need is pf.append(thing).)
>
>I got the pf = pf.append(thing) from doing pandas because in pandas its not an 
>inplace function.

In Python this doesn't do what you think. The convention with most Python 
methods is that methods which perform an in-place action return None, which 
means the above assignment will unbind "pf", binding it to None instead.

BTW, the short answer to why you can't just say pf.append(thing) and have "pf" 
be a list is that ".append" is not _inherently_ a list method i.e. the langauge 
does not specify that name as special. You can have another type where .append 
does somehing else. Therefore, the deduction that pf is uspposed to be a list 
may not be made.

Cheers,
Cameron Simpson <cs@zip.com.au>

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

#109428

> 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
This may not be the answer you are seeking, but how about:

def getsMeet(files=file_list):
     return [pq(filename=my_dir + filename) for filename in sorted(file_list)]

If you can use any iterable instead of a list, then you can also 
consider using a generator:

def getsMeet(files=file_list):
     for filename in sorted(file_list):
         yield pq(filename=my_dir + filename)

for pg_obj in getsMeet(my_file_list):
     process(pg_obj)

This way you do not need to construct a list at all, and it won't create all pq objects in advance.

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

#109443

> > 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
> This may not be the answer you are seeking, but how about:
> 
> def getsMeet(files=file_list):
>      return [pq(filename=my_dir + filename) for filename in sorted(file_list)]
> 
> If you can use any iterable instead of a list, then you can also 
> consider using a generator:
> 
> def getsMeet(files=file_list):
>      for filename in sorted(file_list):
>          yield pq(filename=my_dir + filename)
> 
> for pg_obj in getsMeet(my_file_list):
>      process(pg_obj)
> 
> This way you do not need to construct a list at all, and it won't create all pq objects in advance.

Ok now that is cool and definitely I need to play with that a little more.

Sayth

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

#109454

On 6/3/2016 10:20 AM, Sayth Renshaw wrote:
> 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):

The parameter name if files, not file_list.  The latter is just the default.

>         pyqFiles = pyqFiles.append(pq(filename=my_dir + filename))
>
>     return pyqFiles

You can replace the body with

     return [pq(filename=my_dir+filename) for filename in sorted(files)]

where files is any iterable of file names.

-- 
Terry Jan Reedy

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

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

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

csiph-web