mutable default parameter problem [Prothon]

Dave Brueck dave at pythonapocrypha.com
Fri Jun 25 16:32:56 CEST 2004


Mark wrote:
> > Wait, so is the exclamation point required or not? IOW, say you have a
> class
> > like this:
> >
> > class List(list):
> >   def append(self, what):
> >     list.append(self, what)
> >     return self
> >
> > a = List()
> > b = a.append(5)
> >
> > So in the call to append, is it a.append!(5) or just a.append(5) ? If
it's
> > the former, then does the compiler detect that it's required because the
> > function returns 'self' or is the determining factor something else?
> >
> > Or, does the append method not really return anything, and the language
> > takes care of substituting in the object? (in which case, does that mean
> you
> > can override the return value by adding '!' - such that z=foo.bar!()
> ignores
> > the return value of bar and z references foo?)
>
> As I said above:  It's not that the exclamation mark that causes append to
> return the sequence.  The exclamation mark is always there and the
sequence
> is always returned. In Prothon (and Ruby and other languages before) the
> exclamation mark is just part of the method name and is there to warn you
> that in-place modification is happening.

Ahh...so the method name is just _spelled_ with an exclamation point? IOW,
the ! is a token you can use at the end of an identifier, but it is not
actually used by the language itself - it's some sort of pseudo-syntax? I
think I understand now. But is it truly part of the name in that you are
required to include the ! when calling the method? (I'm still thinking of
the confusion I'd experience with something like w = x.y.z!() )

So if I want a reference to one of those methods I could end up doing

ref = obj.method! or  ref! = obj.method!

and the program runs the same either way, it's just that in one case the
code is misleading?

If it's up to the programmer to remember to add it (meaning that it doesn't
cause an error to forget to use it), and if is really just part of the name,
then it's just a naming convention, right? Wouldn't you get the same result
by establishing the convention that e.g. method names ending in a single
underscore signify in-place modification (foo.append_() ) ? Seems like a
waste to reserve a symbol for something so rarely needed.

> > Personally, I don't like the modify-in-place-and-return-the-object
> > 'feature' - it's not needed _that_ often, but more importantly, it makes
> the
> > code harder to read (to me at least).
>
> If you use the Prothon append!() exactly as you use the Python append()
you
> will get the exact same results.  This is just an extra feature for those
> that want it.
>
> Guido avoided returning values from in-place modification functions
because
> of the confusion as to whether in-place mods were happening or not.  We
have
> solved that confusion with the exclamation mark.  Our code is very
readable
> because of this.

Clearly, readability is in the eye of the beholder. :)

-Dave





More information about the Python-list mailing list