In article <536decca$0$29980$c3e8da3$54964...@news.astraweb.com>,
>Personally, I don't imagine that there ever could be a language where
>variables were first class values *exactly* the same as ints, strings,
>floats etc. Otherwise, how could you tell the difference between a
>function which opera
On 11/05/2014 19:40, Ned Batchelder wrote:
On 5/11/14 9:46 AM, Rotwang wrote:
On 11/05/2014 04:11, Steven D'Aprano wrote:
[...]
And try running
this function in both 2.7 and 3.3 and see if you can explain the
difference:
def test():
if False: x = None
exec("x = 1")
return x
I
Marko Rauhamaa :
> I don't see any practical reason for that limitation. If you allow
> setq/setf/set!, you have no reason to disallow symbol-value on a local
> variable.
In fact, the reason probably is practical and analogous to the locals()
caveat in Python. If the language made local variables
On 5/11/14 9:46 AM, Rotwang wrote:
On 11/05/2014 04:11, Steven D'Aprano wrote:
[...]
And try running
this function in both 2.7 and 3.3 and see if you can explain the
difference:
def test():
if False: x = None
exec("x = 1")
return x
I must confess to being baffled by what happe
Jussi Piitulainen :
> The claim was that Lisp variables are symbols. What do you write in
> Common Lisp in place of the "..." to have the following evaluate to
> the the value of the variable x?
>
> (let ((x (f)) (y 'x)) (... y ...))
>
> No, (eval y) is not an answer, and (symbol-value y) is n
Rustom Mody :
> On Sunday, May 11, 2014 11:51:59 AM UTC+5:30, Marko Rauhamaa wrote:
>> Lisp variables (symbols) are on an equal footing with other objects.
>> IOW, lisp variables are objects in the heap.
>
> But is a symbol a variable??
Yes. A classic lisp symbol is even more "variable" than most
On Sunday, May 11, 2014 6:21:08 PM UTC+5:30, Steven D'Aprano wrote:
> The point is, it is *logically impossible* for a language to use
> precisely the same syntax for value-assignment and variable-assignment.
> Consider the variable called "x", which is bound to the value 23. If the
> language
On 11/05/2014 04:11, Steven D'Aprano wrote:
[...]
And try running
this function in both 2.7 and 3.3 and see if you can explain the
difference:
def test():
if False: x = None
exec("x = 1")
return x
I must confess to being baffled by what happens in 3.3 with this
example. Neithe
On Sun, 11 May 2014 11:26:41 +0300, Jussi Piitulainen wrote:
> Marko Rauhamaa writes:
>> Rustom Mody:
>>
>> > On Saturday, May 10, 2014 2:39:31 PM UTC+5:30, Steven D'Aprano wrote:
>> >>
>> >> Personally, I don't imagine that there ever could be a language
>> >> where variables were first class v
Rustom Mody writes:
> On Sunday, May 11, 2014 1:56:41 PM UTC+5:30, Jussi Piitulainen wrote:
> > Marko Rauhamaa writes:
> > > Rustom Mody:
> > >
> > > > On Saturday, May 10, 2014 2:39:31 PM UTC+5:30, Steven D'Aprano wrote:
> > > >>
> > > >> Personally, I don't imagine that there ever could be a
>
On Sunday, May 11, 2014 1:56:41 PM UTC+5:30, Jussi Piitulainen wrote:
> Marko Rauhamaa writes:
> > Rustom Mody:
> >
> > > On Saturday, May 10, 2014 2:39:31 PM UTC+5:30, Steven D'Aprano wrote:
> > >>
> > >> Personally, I don't imagine that there ever could be a language
> > >> where variables were
Marko Rauhamaa writes:
> Rustom Mody:
>
> > On Saturday, May 10, 2014 2:39:31 PM UTC+5:30, Steven D'Aprano wrote:
> >>
> >> Personally, I don't imagine that there ever could be a language
> >> where variables were first class values *exactly* the same as
> >> ints, strings, floats etc.
> >
> > [.
On Sun, 11 May 2014 11:59:21 +1000, Chris Angelico wrote:
> On Sun, May 11, 2014 at 11:28 AM, Ethan Furman
> wrote:
>> Well, with function variables they have to exist *when you use them*.
>> ;)
>>
>> This seems like more of a scoping issue than a "can we create variables
>> in Python" issue.
>>
On Sat, 10 May 2014 18:28:43 -0700, Ethan Furman wrote:
> On 05/10/2014 04:18 PM, Chris Angelico wrote:
>> On Sun, May 11, 2014 at 5:10 AM, Ethan Furman
>> wrote:
>>> And if you don't like that argument (although it is a perfectly sound
>>> and correct argument), think of the module name space:
>
On Sunday, May 11, 2014 11:51:59 AM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody :
>
>
>
> > On Saturday, May 10, 2014 2:39:31 PM UTC+5:30, Steven D'Aprano wrote:
>
> >>
>
> >> Personally, I don't imagine that there ever could be a language where
> >> variables were first class values *exact
On Sat, 10 May 2014 22:42:13 -0700, Ethan Furman wrote:
> On 05/10/2014 10:22 PM, Chris Angelico wrote:
>> It's that declaration that creates the variable, not changing locals().
>
> A Python variable is a name bound to a value (and values, of course, are
> objects). If you don't have both piece
Rustom Mody :
> On Saturday, May 10, 2014 2:39:31 PM UTC+5:30, Steven D'Aprano wrote:
>>
>> Personally, I don't imagine that there ever could be a language where
>> variables were first class values *exactly* the same as ints,
>> strings, floats etc.
>
> [...]
>
> What you mean by *exactly* the s
On 05/10/2014 10:22 PM, Chris Angelico wrote:
It's that declaration that creates the variable, not
changing locals().
A Python variable is a name bound to a value (and values, of course, are objects). If you don't have both pieces, you
don't have a Python variable.
--
~Ethan~
--
https://mai
[accidentally went off-list; sorry]
On 05/10/2014 02:03 PM, Devin Jeanpierre wrote:
spam is referring to a local variable that has not been bound. This is
not an implementation detail.
The implementation detail is that in cpython there is a spot already reserved for what will be the 'spam' va
On Saturday, May 10, 2014 2:39:31 PM UTC+5:30, Steven D'Aprano wrote:
>
> Personally, I don't imagine that there ever could be a language where
> variables were first class values *exactly* the same as ints, strings,
> floats etc. Otherwise, how could you tell the difference between a
> functio
On Sun, May 11, 2014 at 3:11 PM, Steven D'Aprano
wrote:
> Nonsense. Look at the original examples again, more closely. Here they
> are again, this time with comments:
>
> def test():
> if False: spam = None # Dead code, never executed.
> d = locals()
> d['spam'] = 23 # Not a normal a
On Sun, 11 May 2014 13:30:03 +1000, Chris Angelico wrote:
> On Sun, May 11, 2014 at 1:17 PM, Steven D'Aprano
> wrote:
>> But that is an implementation detail. IronPython and Jython use an
>> ordinary dict for local variable namespaces, just like globals.
>> Consider this example from Jython:
>>
>
On Sun, May 11, 2014 at 1:17 PM, Steven D'Aprano
wrote:
> But that is an implementation detail. IronPython and Jython use an
> ordinary dict for local variable namespaces, just like globals. Consider
> this example from Jython:
>
spam =
def modify(namespace):
> ... namespace['sp
On Sat, 10 May 2014 14:03:11 -0700, Devin Jeanpierre wrote:
> On Sat, May 10, 2014 at 12:10 PM, Ethan Furman
> wrote:
>> On 05/10/2014 02:32 AM, Chris Angelico wrote:
>>>
>>>
>>> Tell me, what may this function do in a compliant Python?
>>>
>>> def demo():
>>> ret = spam
>>> spam = 23
>
On Sun, 11 May 2014 09:18:34 +1000, Chris Angelico wrote:
> On Sun, May 11, 2014 at 5:10 AM, Ethan Furman
> wrote:
>> And if you don't like that argument (although it is a perfectly sound
>> and correct argument), think of the module name space:
>>
>>
>> ret = spam
>> spam = 23
>>
>> will net you
On Sun, May 11, 2014 at 11:28 AM, Ethan Furman wrote:
> Well, with function variables they have to exist *when you use them*. ;)
>
> This seems like more of a scoping issue than a "can we create variables in
> Python" issue.
>
> I am curious, though, what other python's do with respect to function
On 05/10/2014 04:18 PM, Chris Angelico wrote:
On Sun, May 11, 2014 at 5:10 AM, Ethan Furman wrote:
And if you don't like that argument (although it is a perfectly sound and
correct argument), think of the module name space:
ret = spam
spam = 23
will net you a simple NameError, because spam h
On Sun, May 11, 2014 at 5:10 AM, Ethan Furman wrote:
> And if you don't like that argument (although it is a perfectly sound and
> correct argument), think of the module name space:
>
>
> ret = spam
> spam = 23
>
> will net you a simple NameError, because spam has not yet been created.
What about
On Sat, May 10, 2014 at 12:10 PM, Ethan Furman wrote:
> On 05/10/2014 02:32 AM, Chris Angelico wrote:
>>
>>
>> Tell me, what may this function do in a compliant Python?
>>
>> def demo():
>> ret = spam
>> spam = 23
>> return ret
>>
>> In CPython, that'll raise UnboundLocalError, beca
On 5/10/2014 3:22 PM, MRAB wrote:
UnboundLocalError is like NameError,
More specifically,
>>> isinstance(UnboundLocalError(), NameError)
True
This means that 'except NameError:' clauses written before the
UnboundLocalError subclass was added still work and do not necessarily
need to be modi
On 5/10/2014 3:10 PM, Ethan Furman wrote:
On 05/10/2014 02:32 AM, Chris Angelico wrote:
Tell me, what may this function do in a compliant Python?
def demo():
ret = spam
spam = 23
return ret
In CPython, that'll raise UnboundLocalError,
Note:
>>> issubclass(UnboundLocalError, N
On 05/10/2014 12:22 PM, MRAB wrote:
UnboundLocalError is like NameError, except that Python knows that the
name is local because somewhere in the function you're binding to that
name and you haven't said that it's global or nonlocal. Having a
different exception for that case makes it clearer to
On 2014-05-10 20:10, Ethan Furman wrote:
On 05/10/2014 02:32 AM, Chris Angelico wrote:
Tell me, what may this function do in a compliant Python?
def demo():
ret = spam
spam = 23
return ret
In CPython, that'll raise UnboundLocalError, because the local
variable 'spam' does alrea
On 05/10/2014 02:32 AM, Chris Angelico wrote:
Tell me, what may this function do in a compliant Python?
def demo():
ret = spam
spam = 23
return ret
In CPython, that'll raise UnboundLocalError, because the local
variable 'spam' does already exist, and currently has no value (no
o
On Sat, May 10, 2014 at 7:09 PM, Steven D'Aprano
wrote:
> On Sat, 10 May 2014 17:21:56 +1000, Chris Angelico wrote:
>
> No offence Chris, but I think this demonstrates that learning C causes
> brain damage and prevents clear logical thinking :-P
>
> You're not passing a variable to a function. You
On Sat, 10 May 2014 17:21:56 +1000, Chris Angelico wrote:
> On Sat, May 10, 2014 at 4:15 PM, Steven D'Aprano
> wrote:
>> On Sat, 10 May 2014 12:33:28 +1000, Chris Angelico wrote:
>>> 1) Passing them as parameters. You can pass a pointer to a variable,
>>> which is effectively the same as passing
Marko Rauhamaa writes:
> To me, a variable is a variable is a variable.
That works only in Python.
Elsewhere, the sentence would be interpreted either as "a variable is
True" or as "a variable is False" depending on whether a distinction
without a difference is deemed helpful.
--
https://mail.p
Chris Angelico :
> On Sat, May 10, 2014 at 8:34 AM, Marko Rauhamaa wrote:
>> Right, Python's variables aren't like variables in C. Rather,
>> Python's variables are like CPU registers. They cannot hold typed or
>> structured objects and you can't pass references to them.
>
> Are you thinking that
On Sat, May 10, 2014 at 4:15 PM, Steven D'Aprano
wrote:
> On Sat, 10 May 2014 12:33:28 +1000, Chris Angelico wrote:
>> 1) Passing them as parameters. You can pass a pointer to a variable,
>> which is effectively the same as passing a variable to a function.
>
> No it is not. It is nothing like pas
On Sat, 10 May 2014 12:33:28 +1000, Chris Angelico wrote:
> On Sat, May 10, 2014 at 12:19 PM, Rustom Mody
> wrote:
>> For me, Marko's comment that variables in python are not first-class
>> whereas in C they are is for me the most important distinction Ive seen
>> (in a long time of seeing these
On 5/9/14 10:05 PM, Rustom Mody wrote:
Likewise python's name-spaces go almost all the way to first-classing variables
but not quite as Marko discovered when locals() looks like a dict, waddles like
a dict but does not quack like a dict.
QOTWeekEnd
--
https://mail.python.org/mailman/listinfo/p
On Saturday, May 10, 2014 8:03:28 AM UTC+5:30, Chris Angelico wrote:
>
> 2) Returning them. This is a lot more dodgy, owing to the
> dangling-pointer issue, but as long as you accept that the reference
> to a variable doesn't ensure its continued life, I suppose this might
> be acceptable. Maybe.
On Sat, May 10, 2014 at 12:19 PM, Rustom Mody wrote:
> For me, Marko's comment that variables in python are not first-class
> whereas in C they are is for me the most important distinction Ive seen
> (in a long time of seeing these discussions).
>
https://en.wikipedia.org/wiki/First-class_citizen
On Saturday, May 10, 2014 6:31:49 AM UTC+5:30, Steven D'Aprano wrote:
> On Sat, 10 May 2014 01:34:58 +0300, Marko Rauhamaa wrote:
>
> > and you can't pass references to them.
>
>
> That at least you have got right.
>
And that's Marko's main point
>
>
> > Right, Python's variables aren't li
On Sat, May 10, 2014 at 8:34 AM, Marko Rauhamaa wrote:
> Right, Python's variables aren't like variables in C. Rather, Python's
> variables are like CPU registers. They cannot hold typed or structured
> objects and you can't pass references to them.
Are you thinking that a Python variable is neit
On Sat, 10 May 2014 01:34:58 +0300, Marko Rauhamaa wrote:
> Right, Python's variables aren't like variables in C. Rather, Python's
> variables are like CPU registers. They cannot hold typed or structured
> objects
Surely you cannot mean that? It is *trivially simple* to disprove that
statement:
Marko Rauhamaa writes:
> Right, Python's variables aren't like variables in C. Rather, Python's
> variables are like CPU registers.
What is the salient difference between those two? I don't see the point
of the distinction.
Why have you chosen an analogy – CPU registers – that still uses the
mi
Mark H Harris :
> Typically when I think about variables (particularly from the
> past, say Pascal, Basic, C, Fortran, Cobol &c) I am thinking about
> modeling memory is some way where the variable (some naming
> convention) is a value handle or value pointer of some chunk of memory
> (by type
On 5/7/14 8:08 PM, Steven D'Aprano wrote:
In Python, all values *are* objects. It isn't a matter of choosing one or
the other. The value 1 is an object, not a native (low-level, unboxed) 32
or 64 bit int.
Unlike C# or Java, there is no direct language facility to box native
values into objects o
49 matches
Mail list logo
