Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Some language proposals.

Reply
Thread Tools

Some language proposals.

 
 
Antoon Pardon
Guest
Posts: n/a
 
      02-24-2004
I'm rather new at this, so I don't know how I should
introduce this, nor whether these ideas are worth much
but here goes.

What I would like to change is access to variables on
an intermediate scope. Given the following example

def fun_1()

a = some_value

def fun_2()

# a is never the one above.
# on the left side of a statement.


The solution that I heard proposed was to use
a mutable variable. Something like


def fun_1():

a = [some_value]

def fun_2();

a[0] = new_value



And of course if you had a number of such variables
you could group then in an object


def fun_1():

class var_1:
pass

var_1.a = some_value
var_1.b = a_value_too

def fun_2():

var_1.a = new_value
var_1.b = next_value


Now my idea would be to look at the local variables in
a function like member variables of an object so that
you could write


def fun_1():

a = some_value
b = a_value_too

def fun_2():

fun_1.a = new_value
fun_1.b = next_value


This could maybe even extended further is seeing functions
like some kind of module which would allow something like
the following


def fun_1():

a = some_value
b = a_value_too

def fun_2():

from fun_1 import a, b

a = new_value
b = next_value


What do people think about this?
As far as I know the proposal doesn't break existing
code and seems in the spirit of python.


On a side note, what would people think about the idea of
a from ... import ... statement usable on any object? So
that we could do:

class A:
pass

A.a = ...
A.b = ...

from A import a, b

# from here a and be refer to A.a and A.b

--
Antoon Pardon
 
Reply With Quote
 
 
 
 
Jeff Epler
Guest
Posts: n/a
 
      02-24-2004
On Tue, Feb 24, 2004 at 03:53:42PM +0000, Antoon Pardon wrote:
> Now my idea would be to look at the local variables in
> a function like member variables of an object so that
> you could write
>
>
> def fun_1():
>
> a = some_value
> b = a_value_too
>
> def fun_2():
>
> fun_1.a = new_value
> fun_1.b = next_value


This is not compatible with existing code. 'fun_1.a = new_value'
already has a meaning (it creates or modifies an attribute on the
function object), so it can't be used to modify the locals() of a
particular invocation of fun_1.

> def fun_1():
>
> a = some_value
> b = a_value_too
>
> def fun_2():
>
> from fun_1 import a, b
>
> a = new_value
> b = next_value
>
>
> What do people think about this?
> As far as I know the proposal doesn't break existing
> code and seems in the spirit of python.


This is not in the sprit of Python.

This already has a meaning:
from m import a
a = 3
.... it almost is the same as
import m as _m
a = m.a
del _m
a = 3
.... which basically just sets a to 3 (it doesn't modify the module m)

> On a side note, what would people think about the idea of
> a from ... import ... statement usable on any object? So
> that we could do:


No, that won't do. Consider the following Python program:
sys = 64738
from sys import exit
exit()
The module name in 'import' and 'from ... import' doesn't refer to
objects in the current module's namespace, but in the namespace of
modules.

Anyway, because 'from .. import' is not magic, but just assignment,
there's no reason to prefer your proposed
from A import a, b
to
a, b = A.a, A.b
... for instance, it can't make 'a = 3' change A. It has a small
advantage that you don't need to type 'a' once on the left and once on
the right of '=', but that's about it.

Jeff

 
Reply With Quote
 
 
 
 
Anton Vredegoor
Guest
Posts: n/a
 
      02-24-2004
Antoon Pardon <(E-Mail Removed)> wrote:

>I'm rather new at this, so I don't know how I should
>introduce this, nor whether these ideas are worth much
>but here goes.


I'm rather new at criticizing new language proposals so forgive me for
not fighting new ideas ferociously enough But seriously, I think
it's better to keep an eye open to new proposals. Even if things have
been discussed before, the fact that the same ideas come up again and
again should mean something in itself. Also a lot of proposals come in
the company of new ideas that have not yet been evaluated.

>Now my idea would be to look at the local variables in
>a function like member variables of an object so that
>you could write
>
>
>def fun_1():
>
> a = some_value
> b = a_value_too
>
> def fun_2():
>
> fun_1.a = new_value
> fun_1.b = next_value
>
>
>This could maybe even extended further is seeing functions
>like some kind of module which would allow something like
>the following
>
>
>def fun_1():
>
> a = some_value
> b = a_value_too
>
> def fun_2():
>
> from fun_1 import a, b
>
> a = new_value
> b = next_value
>
>
>What do people think about this?
>As far as I know the proposal doesn't break existing
>code and seems in the spirit of python.


I don't see much merit in this, since functions are designed to go out
of scope once they are executed. Having sub-scopes change names higher
up is considered a no-no in Python, although new developments like
"properties" are already nibbling little chunks away from this
concept.

However, in the case of *generator functions* this situation changes
dramatically, so you might score some points there. The road to take
would be something along the lines of "practicality beats purity".

>On a side note, what would people think about the idea of
>a from ... import ... statement usable on any object? So
>that we could do:
>
>class A:
> pass
>
>A.a = ...
>A.b = ...
>
>from A import a, b
>
># from here a and be refer to A.a and A.b


This raises the question of why not to use a class to begin with even
for your earlier proposals. Anyway, this can be accomplished easily
with:

a,b = A.a,A.b

If you still want to go through with this, have a look at this link:

http://us.st5.yimg.com/store4.yimg.c...s_1780_2263455

Anton



 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      02-24-2004

"Antoon Pardon" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> What I would like to change is access to variables on
> an intermediate scope.


As I understand, you want write (rebind) access in addition to read
access -- without having to wrap the variable in a mutable, which one can
do at present. Some proposals to do this have been discussed on the PyDev
list. They should be listed in Brett Cannon's summaries, which are
archived on Python.org.

Bottom line so far: given that write access is only clumsy (sometimes,
through wrapping) rather than impossible, no proposal struck enough people
as worth the bother of a syntax change. Nested functions are much rarer
than unnested. Needing to rebind an outer local, rather than merely read
or mutate, is rarer still.

Terry J. Reedy




 
Reply With Quote
 
Jacek Generowicz
Guest
Posts: n/a
 
      02-25-2004
Antoon Pardon <(E-Mail Removed)> writes:

> The solution that I heard proposed was to use
> a mutable variable. Something like
>
>
> def fun_1():
>
> a = [some_value]
>
> def fun_2();
>
> a[0] = new_value


Could somebody point me to an explanation of why closures are broken
in this way in the first place, please ?
 
Reply With Quote
 
Jacek Generowicz
Guest
Posts: n/a
 
      02-25-2004
"Terry Reedy" <(E-Mail Removed)> writes:

> Nested functions are much rarer than unnested. Needing to rebind an
> outer local, rather than merely read or mutate, is rarer still.


Chicken and Egg.

Sapir-Whorf.

I sumbit to you that read-only closures are rare in Python because
they are a recent addition to the language.

I sumbit to you that read-write closures are so much rarer still,
because they require an ugly hack to work.
 
Reply With Quote
 
Antoon Pardon
Guest
Posts: n/a
 
      02-25-2004
Op 2004-02-24, Anton Vredegoor schreef <(E-Mail Removed)>:
> Antoon Pardon <(E-Mail Removed)> wrote:
>
>> [ ... ]

>


>>What do people think about this?
>>As far as I know the proposal doesn't break existing
>>code and seems in the spirit of python.

>
> I don't see much merit in this, since functions are designed to go out
> of scope once they are executed. Having sub-scopes change names higher
> up is considered a no-no in Python,


I don't understand why. It already is possible with global variables.
I don't see much difference between a function changing a higher up
variable that is global or just in between.

>>On a side note, what would people think about the idea of
>>a from ... import ... statement usable on any object? So
>>that we could do:
>>
>>class A:
>> pass
>>
>>A.a = ...
>>A.b = ...
>>
>>from A import a, b
>>
>># from here a and be refer to A.a and A.b

>
> This raises the question of why not to use a class to begin with even
> for your earlier proposals. Anyway, this can be accomplished easily
> with:
>
> a,b = A.a,A.b


Well maybe my wording was off, but this doesn't accomplisch what I
want since after your statement followed by: a = new_value; A.a will
not be changed.

--
Antoon Pardon
 
Reply With Quote
 
Paul Prescod
Guest
Posts: n/a
 
      02-25-2004
Jacek Generowicz wrote:

>...
>
> Chicken and Egg.
>
> Sapir-Whorf.
>
> I sumbit to you that read-only closures are rare in Python because
> they are a recent addition to the language.
>
> I sumbit to you that read-write closures are so much rarer still,
> because they require an ugly hack to work.


I disagree. Closures are rare in Python because Python is primarily an
OOP language.

http://www.kimbly.com/blog/000063.html

"""The venerable master Qc Na was walking with his student, Anton.
Hoping to prompt the master into a discussion, Anton said "Master, I
have heard that objects are a very good thing - is this true?" Qc Na
looked pityingly at his student and replied, "Foolish pupil - objects
are merely a poor man's closures."

Chastised, Anton took his leave from his master and returned to his
cell, intent on studying closures. He carefully read the entire
"Lambda: The Ultimate..." series of papers and its cousins, and
implemented a small Scheme interpreter with a closure-based object
system. He learned much, and looked forward to informing his master of
his progress.

On his next walk with Qc Na, Anton attempted to impress his master by
saying "Master, I have diligently studied the matter, and now understand
that objects are truly a poor man's closures." Qc Na responded by
hitting Anton with his stick, saying "When will you learn? Closures are
a poor man's object." At that moment, Anton became enlightened. """

Paul Prescod



 
Reply With Quote
 
Paul Prescod
Guest
Posts: n/a
 
      02-25-2004
Jacek Generowicz wrote:

>
> Could somebody point me to an explanation of why closures are broken
> in this way in the first place, please ?


a = 5
def b():
a = 6
print a
b()
print a

What will this print?

5
6

Okay, then.

a = 5
def b():
a = 6
def c():
a = 7
print a
print a
c()

print b()()
print a

What does this print?

7
6
5

Python uses a single syntax for declarating a variable and assigning to
it. This causes a problem for Lisp purists but is otherwise helpful.

Paul Prescod



 
Reply With Quote
 
Jacek Generowicz
Guest
Posts: n/a
 
      02-25-2004
Paul Prescod <(E-Mail Removed)> writes:

> Jacek Generowicz wrote:
>
> > Could somebody point me to an explanation of why closures are broken
> > in this way in the first place, please ?

>
> a = 5
> def b():
> a = 6
> def c():
> a = 7
> print a
> print a
> c()
>
> print b()()


Methinks you forgot to return something somewhere.

> Python uses a single syntax for declarating a variable and assigning
> to it.


Ah, thank you, _this_ is the salient point ( ... though I'm not sure
what "declarating" means, but I'm pretty sure that Python does not do
it to variables .

But what happens in other languages which support closures, but have
no syntactic distinction between binding and re-binding ?

> This causes a problem for Lisp purists but is otherwise helpful.


Lisp causes problems for the simple-minded, but is otherwise helpful.

(Infer as many winks/smileys as you implied in your original.)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Some people tell that at present, most web hosting servers supportall kinds of programming language, some people tell me that many web hostingserver don't support Java, What is the truth? Erwin Moller Java 3 05-07-2008 05:09 PM
A language-agnostic language Ed Java 24 03-27-2006 08:19 PM
c is a low-level language or neither low level nor high level language pabbu C Programming 8 11-07-2005 03:05 PM
Using a Scripting Language as Your Scripting Language DaveInSidney Python 0 05-09-2005 03:13 AM
Python is the best and most popular general purpose scripting language; the universal scripting language Ron Stephens Python 23 04-12-2004 05:32 PM



Advertisments