Overloadable Assignment PEP
Drew Moore
I submitted a pre-PEP on overloadable assignment.
The idea is:
In situations where the assignment token "=" appears, and an augmented
assignment symbol (such as +=, -=, *=, etc..) would also be
syntactically correct, the assigned-to object would be checked for an
__assign__(self, other) method. If this __assign__ method existed, it
would be called, and the reference that it returned would be used for
the assignment.. otherwise, assignment would proceed as it currently
does now.
Thus, a few simple cases:
# do-nothing assign method...
def __assign__(self,other) :
return other # same as current implementation.
# "un-writeable" object.. kinda 'const-ish'
def __assign__(self,other) :
return self # ignore attempt at assignment..
and a slightly more complex one:
def __assign__(self,other) :
self.value = int(other)
self.notify() # do the other things needed when value changes
return self # and of course, don't lose identity.
David Goodger suggested I search on "__assign__", as this topic has
been discussed before. Well, I did the search, but I did not find a
thread that had quite the same slant on this topic as I have. In any
event, I want to champion this PEP, either to bring it to fruition, or
definitively explain why it won't work.
Most people who proposed this before had the "__assign__" operator as
a method of the "assigned-from" object, not the "assigned-to" object.
I agree.. that does not make sense.. but in the context of augmented
assignment, it seems sensible. (one person did briefly propose
something akin to this approach, but nobody seemed to take notice..)
The situations I can think of where an = assignment is syntactically
correct, but the augmented assignments are not:
1:
multiple assignment..
a = b = 4 # a = b += 4 does not work...
2:
tuple unpacking
a,b,c = 1,2,3 # a,b,c += 1,2,3 does not either.
Why the augmented assingment operators are syntactically incorrect in
these cases is another issue that I'd rather defer discussion on.. I
think probably it is simpler to consider allowing overloading the
assignment operator in the same situations that the augmented
assignment operators allow overloading.. Just more consistent..
Anyway, That's the gist of it.
(Any insights into how to hack the "ceval" source to implement this
would be appreciated. Insights into why the idea won't work are
equally welcome; I figured I gain that insight by trying to implement
it, too..)
Drew
Anders J. Munch
> Howdy!
>
> I submitted a pre-PEP on overloadable assignment.
>
> The idea is:
>
> In situations where the assignment token "=" appears, and an augmented
> assignment symbol (such as +=, -=, *=, etc..) would also be
> syntactically correct, the assigned-to object would be checked for an
> __assign__(self, other) method.
You terminology is off. There is no such thing as an "assigned-to"
object in Python. Assignments change bindings, not objects.
Take a step back and tell us what problem you are trying to solve.
Whatever it is, I'm sure we can think of a better solution than having
assignment depend on whatever object, if any, happened to be
previously bound to the same name.
python-is-not-c++-ly y'rs, Anders
Richie Hindle
[Drew]
> I submitted a pre-PEP on overloadable assignment.
[Anders]
> Take a step back and tell us what problem you are trying to solve.
> Whatever it is, I'm sure we can think of a better solution than having
> assignment depend on whatever object, if any, happened to be
> previously bound to the same name.
I have a use case for this. My PyMeld library lets you manipulate HTML as
though it were a collection of Python objects, like this:
>>> from PyMeld import Meld
>>> page = Meld('''<html><body>
... <textarea id="message">Type a message.</textarea>
... </body></html>
... ''')
>>> page.message = "New content." # Change the content of an element.
>>> print page
<html><body>
<textarea id="message">New content.</textarea>
</body></html>
So the line `page.message = "New message"` changes the content of the tag
with id 'message'. In this context, it makes sense that assigning to an
object *changes* that object, rather than *replacing* it with another.
What you can't do with PyMeld is this:
>>> message = page.message
>>> message = "Another new message"
>>> print page
<html><body>
<textarea id="message">Another new message.</textarea>
</body></html>
There are workarounds, but over loadable assignment would make this much
neater.
Disclaimer: I don't think this is sufficient reason for adding over
loadable assignment to Python (especially if it would slow down every
assignment of anything to anything, which seems likely), but you asked for
a use case and I believe this is one. 8-)
--
Richie Hindle
ric...@entrian.com
Jack Diederich
> So the line `page.message = "New message"` changes the content of the tag
> with id 'message'. In this context, it makes sense that assigning to an
> object *changes* that object, rather than *replacing* it with another.
>
> What you can't do with PyMeld is this:
>
> >>> message = page.message
> >>> message = "Another new message"
> >>> print page
> <html><body>
> <textarea id="message">Another new message.</textarea>
> </body></html>
>
As others have pointed out, this isn't pythonic, but you could make a string
wrapper class so you could do:
messgae = page.message
message.txt = "Another New Message"
you still couldn't do
foo = message.txt
foo = "another new message"
You might want to rethink using the magic of page.message finding the element
in page with the 'id' attribute equal to 'message'. People will undoubtably
start naming their element 'id' attributes to '__init__' or something else
to make your life difficult.
(psuedo python debugging below)
>>> msg = page.byId('message')
>>> print msg['id']
message
>>> print msg.txt
another new message
>>> print page.elements
[<class textarea>,]
I'm not sure what happens when two elements at the same level have the same
'id' attribute (that applies to any way you do it).
-jackdied
Drew Moore
> "Drew Moore" <dr...@astro.pas.rochester.edu> wrote:
> > Howdy!
> >
> > I submitted a pre-PEP on overloadable assignment.
> >
> > The idea is:
> >
> > In situations where the assignment token "=" appears, and an augmented
> > assignment symbol (such as +=, -=, *=, etc..) would also be
> > syntactically correct, the assigned-to object would be checked for an
> > __assign__(self, other) method.
>
> You terminology is off. There is no such thing as an "assigned-to"
> object in Python. Assignments change bindings, not objects.
Right, the binding of the name always changes. When an augmented
assignment operator is overloaded, the method must return a
reference to an object, and this returned reference is bound to the
name on the left hand side. Typical code inspects the "other" object,
modifies self appropriately, and returns a reference to self.
Regular assignment is just the trivial case of augmented assignment.
Seems to me a += b -> __iadd__(a,b)
is very similar a = b -> __assign__(a,b)
the __assign__ method returns a reference, just like __iadd__
this reference will be bound to the name on the left hand side.
> Take a step back and tell us what problem you are trying to solve.
> Whatever it is, I'm sure we can think of a better solution than having
> assignment depend on whatever object, if any, happened to be
> previously bound to the same name.
>
> python-is-not-c++-ly y'rs, Anders
my original need?
I wanted to create an object that controls a voltage and
use it at the python command line.
by overloading operators, I can do:
voltage += 5 # (raise the voltage by 5 volts)
voltage *= 2 # (double the current voltage)
but when I do
voltage = 3 # (set the voltage to 3 volts)
my voltage object is clobbered with an integer object.
I don't want to require the user to type any more than
name = value # no name.val = newval, no name.setval(value)
Overloadable augmented assignment provides a nice framework that
always rebinds the name, but gives the "about to be rebound" name
some say in how this takes place. I'm at a loss to explain why
the "most trivial case of augmented assignment" was denied this power.
Thanks for responding.. Maybe posting on April 1st was a mistake,
people might have thought I was joking around!!
Daniel Dittmar
> some say in how this takes place. I'm at a loss to explain why
> the "most trivial case of augmented assignment" was denied this power.
Performance comes to mind. Assignment is a frequent statement and having to
search for an __assign__ method will slow things down a lot.
And if an object has an __assign__ method, how do you perform a real rebind?
Do we add a 'becomes' operator (similar to the ==/is operators)?
Daniel
Michael Hudson
> Thanks for responding.. Maybe posting on April 1st was a mistake,
> people might have thought I was joking around!!
I certainly did.
Cheers,
M.
--
same software, different verbosity settings (this one goes to
eleven) -- the effbot on the martellibot
Ken Seehof
You are thinking like a C programmer. Python assignment is fundamentally
different from C assignment. You probably know this.
In the statement a = b, the python interpreter simply does not look at the
previous value associated with `a' (except to decrement the reference count).
Therefore, it is not possible for the interpreter to check to see if `a' has an
__assign__ attribute. In order for this to change, pythons concept of name
binding
would have to completely change, and I doubt Guido would be up for that.
One effect would be to make python significantly slower (since all assignment
operations would have to be preceded by an extra method search for __assign__).
Historically, the addition of augmented assignment to python was controversial
because of the belief that it tends to confuse people by making assignment seem
to be more like other languages such as C.
Also, the notion of hiding information in order to simply reduce the amount of
typing is a dubious (though attractive) programming technique. It is better to
have more typing if it means that the code is easier to read and debug. I
recommend that you make voltage an property of a class. This way you can
overload assignment any way you like.
- Ken
Jp Calderone
> "Anders J. Munch" <ande...@dancontrol.dk> wrote in message news:<3e8c083b$0$10386$edfa...@dread11.news.tele.dk>...
>
> > Take a step back and tell us what problem you are trying to solve.
> > Whatever it is, I'm sure we can think of a better solution than having
> > assignment depend on whatever object, if any, happened to be
> > previously bound to the same name.
> >
> > python-is-not-c++-ly y'rs, Anders
>
> my original need?
> I wanted to create an object that controls a voltage and
> use it at the python command line.
> by overloading operators, I can do:
>
> voltage += 5 # (raise the voltage by 5 volts)
> voltage *= 2 # (double the current voltage)
>
> but when I do
>
> voltage = 3 # (set the voltage to 3 volts)
>
> my voltage object is clobbered with an integer object.
> I don't want to require the user to type any more than
> name = value # no name.val = newval, no name.setval(value)
>
class Conductor(object):
def set_voltage(self, value):
# Twiddle whatever needs to be twiddled
def get_voltage(self):
# Lookup whatever the voltage is
return it
voltage = property(get_voltage, set_voltage)
c = Conductor()
c.voltage = 3
This is more along the lines of what you'd really do, anyway, right?
After all, if "voltage" is simply a global, then your program or library
will be forever tied to controlling a single item across which an emf can
be put. Not very scalable, right?
Jp
--
Lowery's Law:
If it jams -- force it. If it breaks, it needed replacing anyway.
--
up 14 days, 12:00, 4 users, load average: 0.00, 0.03, 0.00
Drew Moore
Good points! (and ones I considered)
If the interpreter could tell quickly that the __assign__ method
was in the dictionary (ie, a cached bool flag) the performance
hit would be pretty insignificant, I suspect..
I considered ":=" for the "force name rebind" operator, but don't think
there would be a pressing need for this, would there?
You could always delete the name and reassign it if that is
what you really needed. The code doing the assign in most
cases would not care about what the assignment did, as
long as the result acted sensibly. Adding a "force rebind" operator
would cause paranoid programmers to use it all the time..
and I don't like the sounds of that. Too messy.
polite __assign__ methods might return the reference to other
rather than self, if they "detected" the need..
Drew
Ben Hutchings
<snip>
> with id 'message'. In this context, it makes sense that assigning to an
> object *changes* that object, rather than *replacing* it with another.
That's assigning to an attribute, not to an object.
> What you can't do with PyMeld is this:
>
>>>> message = page.message
>>>> message = "Another new message"
>>>> print page
><html><body>
><textarea id="message">Another new message.</textarea>
></body></html>
>
> There are workarounds, but over loadable assignment would make this much
> neater.
<snip>
No, it would make it very weird, and massively incompatible with existing
code. Binding and mutating are fundamentally different and shouldn't be
combined in one operator. (Look at the confusion people sometimes have with
initialisation and assignment in C++.) Python's augmented assignment
operators already have this horrible behaviour, and I stay clear of them
because of this.
Anders J. Munch
[...]
> voltage += 5 # (raise the voltage by 5 volts)
> voltage *= 2 # (double the current voltage)
>
> but when I do
>
> voltage = 3 # (set the voltage to 3 volts)
>
> my voltage object is clobbered with an integer object.
> I don't want to require the user to type any more than
> name = value # no name.val = newval, no name.setval(value)
How about
name(value)
- Anders
Lulu of the Lotus-Eaters
|voltage += 5 # (raise the voltage by 5 volts)
|voltage *= 2 # (double the current voltage)
|my voltage object is clobbered with an integer object.
The case makes sense... but IMO, not nearly enough to change the
behavior of assignment.
For this particular case, you could simply coopt the meaning of some
other augmented operator to set voltage. For example:
voltage |= 3
The need to bitwise-and on voltage seems unlikely, so you should not
step on anything important. Of course, experienced Python programmers
might do a little double take on the meaning, but documentation can
explain it.
Then again, I wouldn't mind adding the new operator ":=" which was
"generic augmentation"... the operator could do -absolutely nothing- for
standard types, but could be available for custom meaning in custom
types.
Yours, Lulu...
--
_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY: Postmodern Enterprises _/_/_/
_/_/ ~~~~~~~~~~~~~~~~~~~~[me...@gnosis.cx]~~~~~~~~~~~~~~~~~~~~~ _/_/
_/_/ The opinions expressed here must be those of my employer... _/_/
_/_/_/_/_/_/_/_/_/_/ Surely you don't think that *I* believe them! _/_/
A. Lloyd Flanagan
> dr...@astro.pas.rochester.edu (Drew Moore) writes:
>
> > Thanks for responding.. Maybe posting on April 1st was a mistake,
> > people might have thought I was joking around!!
>
> I certainly did.
>
> Cheers,
> M.
Oh, good, if this had turned out to be a joke, I'd be afraid I won't
get my Roman numeral literals after all.
MMCCXXXLIII forever!!!
Erik Max Francis
> I certainly did.
Me too. I don't have any huge opinion on the proposition one way or
another, but I must say I do find it reassuring in Python to know that
(at present, without the proposal) whenever I see an assignment, I
always know that there's going to be a rebinding/attribute assignment
taking place. Assignment seems so fundamental an operation that I'm not
sure whether it would be net good or net bad to have it overridable.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ The decree is the Sultan's, the mountains are ours.
\__/ Dadaloglu
Official Omega page / http://www.alcyone.com/max/projects/omega/
The official distribution page for the popular Roguelike, Omega.
Erik Max Francis
> Then again, I wouldn't mind adding the new operator ":=" which was
> "generic augmentation"... the operator could do -absolutely nothing-
> for
> standard types, but could be available for custom meaning in custom
> types.
That strikes me as a better approach; having a special "augmentation"
operator which has no predefined meaning but can be overridden as
desired, and thereby leaving usual assignment alone.
The only reservation I might have is whether or not := is a good choice,
simply because of the :=/= and =/== language differences out there.
Bengt Richter
>Michael Hudson wrote:
>
>> I certainly did.
>
>Me too. I don't have any huge opinion on the proposition one way or
>another, but I must say I do find it reassuring in Python to know that
>(at present, without the proposal) whenever I see an assignment, I
>always know that there's going to be a rebinding/attribute assignment
>taking place. Assignment seems so fundamental an operation that I'm not
>sure whether it would be net good or net bad to have it overridable.
>
So how do you feel about properties? Seems like the OP's proposal would
open up another way to implement at least the assignment part. Perhaps
there should be an analogous __getvalue__ method for the right hand side.
(Already ducking ;-)
Regards,
Bengt Richter
Bengt Richter
>Lulu of the Lotus-Eaters wrote:
>
>> Then again, I wouldn't mind adding the new operator ":=" which was
>> "generic augmentation"... the operator could do -absolutely nothing-
>> for
>> standard types, but could be available for custom meaning in custom
>> types.
>
>That strikes me as a better approach; having a special "augmentation"
>operator which has no predefined meaning but can be overridden as
>desired, and thereby leaving usual assignment alone.
>
>The only reservation I might have is whether or not := is a good choice,
>simply because of the :=/= and =/== language differences out there.
>
I feel a bit reserved re the name "generic augmentation" -- how 'bout
something with "update" or "mutate" in it, so x:=y reads "update/mutate x with y"
or "x updated/mutated with y". The latter would read better if x:=y were
an _expression_ whose value was x after the side effect.
Regards,
Bengt Richter
Greg Ewing (using news.cis.dfn.de)
> Oh, good, if this had turned out to be a joke, I'd be afraid I won't
> get my Roman numeral literals after all.
The Roman numerals PEP seems unlikely to get passed
in any case, but perhaps we can rescue something from
it to help with this problem: we could apply
augmented assignment semantics when and only when
the name being assigned to resembles a Roman numeral.
This very neatly solves the "voltage" problem,
because then
V = 3
would be an augmented assignment, whereas
Voltaire = 3
would just be an ordinary assignment.
--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg
Erik Max Francis
> So how do you feel about properties? Seems like the OP's proposal
> would
> open up another way to implement at least the assignment part. Perhaps
> there should be an analogous __getvalue__ method for the right hand
> side.
> (Already ducking ;-)
I really should have said "rebinding" instead of "rebinding/attribute
assignment." I misspoke, sorry.
I know
something = somethingElse
is always going to mean rebinding, and I like that. I don't mind if
something.subSomething = somethingElse
can mean different things; that seems very reasonable, in fact.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Listen to my song
\__/ Chante Moore
Lsystem / http://www.alcyone.com/pyos/lsystem/
A Lindenmayer systems explorer in Python.
Drew Moore
>
> class Conductor(object):
> def set_voltage(self, value):
> # Twiddle whatever needs to be twiddled
> def get_voltage(self):
> # Lookup whatever the voltage is
> return it
> voltage = property(get_voltage, set_voltage)
>
> c = Conductor()
> c.voltage = 3
>
> This is more along the lines of what you'd really do, anyway, right?
> After all, if "voltage" is simply a global, then your program or library
> will be forever tied to controlling a single item across which an emf can
> be put. Not very scalable, right?
>
> Jp
>
> --
> Lowery's Law:
> If it jams -- force it. If it breaks, it needed replacing anyway.
Well, not exactly what I had in mind.. how bout this?
class dacvoltage() :
def __init__(self,dacnum,volt=0.0,dacfunc=maindac) :
self.dacnum = dacnum
self.volt = volt
self.writedac=dacfunc
self.writedac(self.dacnum,self.volt)
def __assign__(self,other) :
# todo: add code to check type of other..
# if it is another dacvoltage object,
# return other, not self...
# this will rebind the name!
try:
self.writedac(self.dacnum,other) # might barf.
self.volt=other # didn't barf? remember what was assigned.
except:
# complain bitterly here if writedac barfs.
return self # retain identity..
# instantiate some dac voltage objects for the first time..
# (or re-instantiate old ones, if above todo gets done..)
vdduc = dacvoltage(1, -4.0)
vreset = dacvoltage(2, -3.0)
vbias = dacvoltage(0,dacfunc=auxdac) # bias dac uses special converter..
vbias = 2.5
# etc etc...
# do some stuff at these voltages..
# modify the voltages, in a very simple, readable syntax.
vdduc = -3.8 # try a reduced supply
vreset = -3.2 # and increased reset drive...
vbias = 2.3 # and decreas the bias a little..
# do some more stuff with new voltages, etc etc...
Drew
Drew Moore
> dr...@astro.pas.rochester.edu (Drew Moore) wrote previously:
> |voltage += 5 # (raise the voltage by 5 volts)
> |voltage *= 2 # (double the current voltage)
> |voltage = 3 # (set the voltage to 3 volts)
> |my voltage object is clobbered with an integer object.
>
> The case makes sense... but IMO, not nearly enough to change the
> behavior of assignment.
>
> For this particular case, you could simply coopt the meaning of some
> other augmented operator to set voltage. For example:
>
> voltage |= 3
>
> The need to bitwise-and on voltage seems unlikely, so you should not
> step on anything important. Of course, experienced Python programmers
> might do a little double take on the meaning, but documentation can
> explain it.
>
> Then again, I wouldn't mind adding the new operator ":=" which was
> "generic augmentation"... the operator could do -absolutely nothing- for
> standard types, but could be available for custom meaning in custom
> types.
>
> Yours, Lulu...
Use a different operator? not a bad idea..
I been there.. kinda. I used
voltage << 3
which was a little more intuitive to me syntactically..
However I still found myself accidentally typing
voltage = 3 every once in a while, as that makes the most "sense."
Drew
Aahz
Greg Ewing (using news.cis.dfn.de) <ckea...@sneakemail.com> wrote:
>A. Lloyd Flanagan wrote:
>>
>> Oh, good, if this had turned out to be a joke, I'd be afraid I won't
>> get my Roman numeral literals after all.
>
>The Roman numerals PEP seems unlikely to get passed
>in any case, but perhaps we can rescue something from
>it to help with this problem: we could apply
>augmented assignment semantics when and only when
>the name being assigned to resembles a Roman numeral.
>
>This very neatly solves the "voltage" problem,
>because then
>
> V = 3
>
>would be an augmented assignment, whereas
>
> Voltaire = 3
>
>would just be an ordinary assignment.
...and if we add a
from __past__ import FORTRAN
it only applies when the names are I, J, K, L, M, or N.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
This is Python. We don't care much about theory, except where it intersects
with useful practice. --Aahz, c.l.py, 2/4/2002
Greg Ewing (using news.cis.dfn.de)
> # modify the voltages, in a very simple, readable syntax.
> vdduc = -3.8 # try a reduced supply
> vreset = -3.2 # and increased reset drive...
> vbias = 2.3 # and decreas the bias a little..
Maybe our brains work differently, but I'd find it
FAR less confusing if the dac were an object and
one did
dac.vdduc = -3.8
dac.vreset = -3.2
dac.vbias = 2.3
Jp Calderone
> Jp Calderone <exa...@intarweb.us> wrote in message news:<mailman.1049388384...@python.org>...
>
> >
>
> Well, not exactly what I had in mind.. how bout this?
I know exactly what you meant. I was proposing an alternative solution
that actually works given the current form of the language, and which
requires no gut wrenching disfigurement of the current language semantics.
> [snip - example of gut wrenching disfigurement of the current language
> semantics]
>
> Drew
Jp
--
"There is no reason for any individual to have a computer in their
home."
-- Ken Olson, President of DEC, World Future Society
Convention, 1977
--
up 15 days, 2:00, 2 users, load average: 0.07, 0.04, 0.01
Drew Moore
> Bengt Richter wrote:
>
> > So how do you feel about properties? Seems like the OP's proposal
> > would
> > open up another way to implement at least the assignment part. Perhaps
> > there should be an analogous __getvalue__ method for the right hand
> > side.
> > (Already ducking ;-)
I had the same thought..
>
> I really should have said "rebinding" instead of "rebinding/attribute
> assignment." I misspoke, sorry.
>
> I know
>
> something = somethingElse
>
> is always going to mean rebinding, and I like that..
Can we follow up on this a little?
I'm trying to understand this concern in more detail..
I'd like this PEP to go one of two ways..
either implementation,
or a good solid technical reason why its a bad idea.
so far, the response seems to be:
"it is technically possible, but my scripts might
run slower.. and it just makes me nervous."
I suspect there is some basis for this nervousness, but
I still haven't seen an example of how this proposed feature
would break things.
since no current code uses __assign__,
nothing would break immediately.
however, once it started to be used.. what would go wrong??
nothing? ## in your dreams, kiddo
all hell would break loose? ## far more likely.
What are use cases when
something = somethingElse
with overloadable assignment
will give real problems in a real-world code example?
would help() immediately break?
would inspect immediately break?
would pydoc immediately break?
I'm an electrical engineer..
I have never won any popularity
contests with my programming skills (or lack thereof)...
still,
I'd like to see this PEP die for a good technical reason.
help me out here!!
Drew
Michael Hudson
> I'd like this PEP to go one of two ways..
> either implementation,
> or a good solid technical reason why its a bad idea.
How about: it involves changing the language into something it's not.
For a more technical sounding reason, how do you cope with the fact
that `=' can both establish and change a binding?
Cheers,
M.
--
If you don't have friends with whom to share links and conversation,
you have social problems and you should confront them instead of
joining a cultlike pseudo-community. -- "Quit Slashdot.org Today!"
(http://www.cs.washington.edu/homes/klee/misc/slashdot.html#faq)
A. Lloyd Flanagan
...
> ...and if we add a
>
> from __past__ import FORTRAN
>
> it only applies when the names are I, J, K, L, M, or N.
This is brilliant!! But how are the implementors of the sets module
going to feel? They could have skipped all that work and just done
from __past__ import Pascal
Christopher A. Craig
> so far, the response seems to be:
> "it is technically possible, but my scripts might
> run slower.. and it just makes me nervous."
Not might run slower, would run not just slower but a ton slower.
You're basically replacing the C code
a=b
with at least one, and possibly several dict lookups. Your idea about
caching the value is a decent one, but you have the problem that class
dicts are mutable, so what if someone does
>>> class foo:
... pass
...
>>> t = foo()
>>> t.__dict__.__assign__ = lambda t, a: t.elem=a
If __assign__ is allowed, that will be expected to work.
A bigger problem to me is that '=' currently means rebinding names.
If I see 'a=b' in Python, I immediately presume that 'a' doesn't exist
after the assignment. If you change this then it will sometimes mean
rebinding and sometimes mean something else.
If you want a way to set something's value, I imagine you'll have a
lot more support for adding an operator rather than making '=' one.
I'm all for Lulu's suggestion of adding a ':=' operator for that sort
of situation.
--
Christopher A. Craig <list-...@ccraig.org>
"The world would be a better place if Larry Wall had been born in Iceland,
or any other country where the native language actually has syntax."
-- Peter da Silva (in alt.sysadmin.recovery)
Ben Hutchings
Greg Ewing (using news.cis.dfn.de) wrote:
> Drew Moore wrote:
>> # modify the voltages, in a very simple, readable syntax.
>> vdduc = -3.8 # try a reduced supply
>> vreset = -3.2 # and increased reset drive...
>> vbias = 2.3 # and decreas the bias a little..
>
> Maybe our brains work differently, but I'd find it
> FAR less confusing if the dac were an object and
> one did
>
> dac.vdduc = -3.8
> dac.vreset = -3.2
> dac.vbias = 2.3
I implemented a change to Python that would let you access
attributes of a 'default' object without naming it. The default
object would be a 'for' loop's iterator (if a simple variable)
or the function's first argument. This would let you (ab)use a
'for' statement as something like VB's 'with' statement:
for dac in [dac]:
.vdduc = -3.8
.vreset = -3.2
.vbias = 2.3
It would also let you omit many uses of 'self' in a method.
Whether that's desirable or whether I could release that, I do
not know.
Drew Moore
> dr...@astro.pas.rochester.edu (Drew Moore) writes:
>
> > I'd like this PEP to go one of two ways..
> > either implementation,
> > or a good solid technical reason why its a bad idea.
>
> How about: it involves changing the language into something it's not.
>
> For a more technical sounding reason, how do you cope with the fact
> that `=' can both establish and change a binding?
>
> Cheers,
> M.
I think I came up with a reason.
when the overloading object is always on the left side of the assign,
I think things stay pretty benign.
When they appear on the right side, however, you get trouble..
The overloading is sticky.. contagious.. eek!
for s in L : # loop thru list of things..
p = s # hey, what if an item in the list overloads assignment?
# it overloads it for the remainder of the loop!
Sounds like an easy way to shoot yourself in the foot.
I can't think of a sensible way around this.
Drew
Niki Spahiev
DM> # modify the voltages, in a very simple, readable syntax.
DM> vdduc = -3.8 # try a reduced supply
DM> vreset = -3.2 # and increased reset drive...
DM> vbias = 2.3 # and decreas the bias a little..
DM> # do some more stuff with new voltages, etc etc...
vdduc [:]= -3.8 is valid Python and can be made to work now. Maybe new
augmented assignment a := b to mean a[:] = b.
Niki Spahiev
christopher ariza
does anyone have some sample code of how to write a basic midi file with
python?
i dont need to deal with real-time communication, i just want to
take a few note-events (as a python data structure) and spit out a midi file.
i have been looking at Will Ware's midi.py:
http://www.python.or.kr/pykug/midi_2epy
but cant get it to do what i want. i cant find any more information about
this module, examples of it in use, or a way to contact the author. anyone
every use midi.py?
if anyone has some tips, many thanks in advance.
________________________________________
christopher ariza \ http://flexatone.net
Erik Max Francis
> Can we follow up on this a little?
> I'm trying to understand this concern in more detail..
>
> I'd like this PEP to go one of two ways..
> either implementation,
> or a good solid technical reason why its a bad idea.
>
> so far, the response seems to be:
> "it is technically possible, but my scripts might
> run slower.. and it just makes me nervous."
Well, your scripts would run slower, but I think the real concern is
about the readability problems this might cause.
> I suspect there is some basis for this nervousness, but
> I still haven't seen an example of how this proposed feature
> would break things.
>
> since no current code uses __assign__,
> nothing would break immediately.
>
> however, once it started to be used.. what would go wrong??
It isn't that it wouldn't break preexisting code, it's that after its
introduction, suddenly previously meaningful code can take on entirely
new meanings. And since Python is dynamic, there's no way to know in
other code how this change might affect it. Take for instance:
def f(x=0):
if not x:
x = 1
# ... do something with x
While at first this appears a contrived example, this kind of thing
happens all the time -- say, you're getting some input externally, and
you're clamping it to within bounds, for example. It is simple and safe
because you can trust in the "x = 1" statement rebinding the _local
name_ x and not having any effect outside the scope of the function call
f.
Now let's say your proposal is passed and implemented. Now this "x = 1"
statement might _not_ do the rebinding after all. One would hope that a
well-behaved __assign__ method would make this all okay, but then again
the point of an __assign__ method is that you can make it do whatever
you want.
The down side isn't that this will immediately break huge amounts of
code, it's that suddenly very simple, almost ubiquitous code can
suddenly take on a subtly different meaning, and because of Python's
dynamicism, it's hard to say when the effect will change the meaning.
I suspect this falls into the same class of "Okay this changes the
meaning of everything" like lazy evaluation or macros.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ If the sky should fall, hold up your hands.
\__/ (a Spanish proverb)
The laws list / http://www.alcyone.com/max/physics/laws/
Laws, rules, principles, effects, paradoxes, etc. in physics.
Drew Moore
> dr...@astro.pas.rochester.edu (Drew Moore) writes:
>
> > so far, the response seems to be:
> > "it is technically possible, but my scripts might
> > run slower.. and it just makes me nervous."
>
> Not might run slower, would run not just slower but a ton slower.
> You're basically replacing the C code
> a=b
>
> with at least one, and possibly several dict lookups. Your idea about
> caching the value is a decent one, but you have the problem that class
> dicts are mutable, so what if someone does
>
> >>> class foo:
> ... pass
> ...
> >>> t = foo()
> >>> t.__dict__.__assign__ = lambda t, a: t.elem=a
>
> If __assign__ is allowed, that will be expected to work.
>
> A bigger problem to me is that '=' currently means rebinding names.
> If I see 'a=b' in Python, I immediately presume that 'a' doesn't exist
> after the assignment. If you change this then it will sometimes mean
> rebinding and sometimes mean something else.
>
> If you want a way to set something's value, I imagine you'll have a
> lot more support for adding an operator rather than making '=' one.
> I'm all for Lulu's suggestion of adding a ':=' operator for that sort
> of situation.
Excellent observation about the multiple dict search, Christopher!
A cached bit would not work if you expected derived classes
to inherit the overload. A base class, if modified, would have
to go to all derived instances and set the bit.
That would definitely not fly!
The most sensible implementation I can think of:
The __assign__ method belongs to the object.
BUT---
The "use the __assign__ method if present" flag
belongs to the name, and is only set under certain
circumstances.. such as if the name
is bound to a freshly instantiated instance
that has __assign__ method defined.
(got to think about this one some more)
a = myOAclass() # a overloads assignment
b = a # b does not. it has the __assign__ method but..
# will not use it.
b = c # b has been reassigned!!
f(a) # reference passed to f does not overload assignment!
L[3] = a # list item does not overload assignment
### perhaps the := operator has a place here...
a = myOAclass() # a does not overload assignment..
b := a # but b does..??
# (set the AO flag in b if the := operator is used
# and a has __assign__ method.)
c := myOAclass() # c overloads assignment
d = c # d does not.
Hmm, I like this..
The OA flag sensibly belongs to the name, not the object.
(its really the name that wants this property, not the object.)
Now, performance hit is tiny, because it is just checking a bit.
reassignment does not propogate the bit in the name...
no ripples..
Drew
Greg Ewing (using news.cis.dfn.de)
>> still,
> I'd like to see this PEP die for a good technical reason.
> help me out here!!
PEPs don't need technical reasons to die; they only
need to fail to convince Guido that they're sufficiently
useful to be accepted.
And such a radical change as this has a VERY big threshold
of usefulness to reach before Guido will even start to
consider thinking about it...
Greg Ewing (using news.cis.dfn.de)
> This is brilliant!! But how are the implementors of the sets module
> going to feel? They could have skipped all that work and just done
>
> from __past__ import Pascal
No, we're not allowed to import from __past__, so
it would have to be
from __languages_named_after_famous_french_mathematicians__ \
import Pascal