Invoking return through a function?

[Rick Johnson]

Alberto Riva wrote:
> Rick Johnson wrote:
> > Alberto Riva wrote:
> >> Rick Johnson wrote:
> >>> Alberto Riva wrote:
> > [...]
> > > > >     
> > > > > In a language like Lisp
> > > >
> > > > Python is nothing like Lisp, and for good reason!
> > >
> > > I would disagree with this. Actually, it's the most Lisp-
> > > like language I've encountered in my 25 years of writing
> > > software.
> > 
> > Really? I'm sorry that you have only encountered a few
> > "academic languages". Do some googling, there are
> > literally thousands of them in the wilds.
> 
> I'm sorry, I'm not sure I understand what you mean. I've
> been exposed to quite a few programming languages over the
> years, and my personal assessment (based on the features I
> consider important from my own personal point of view) is
> that Python is the closest to Lisp of the ones that I would
> consider using. It's definitely closer to Lisp than C, or
> Java, wouldn't you agree?

It depends on what metrics you use. Once you remove all the
type declarations from C and Java source, all three look very
similar, with Python being the "cleanest" syntax of all.
OTOH, when i look at Lisp, all i see is a language that was
designed for easy machine parsing, not for the human. But
that's just a syntactical comparison. Digging deeper, Python
and Java are both strongly typed. And with Python's
multi-paradigm nature, it is both equally useful in OOP (aka: Java)
or imperative (aka: C) style. Aside from static type checking and
some low level distractions, Python is very much like both of
these languages. In fact, i was familiar with both Java and
C before i ever became aware of Python. And the transition
felt very natural to me.

> I don't see where you get the idea that I was only exposed
> to "academic languages".

Just a lucky guess, i suppose.

> > > It has closures, functions are first-class objects, it's
> > > interactive, highly reflective, variables are not
> > > strongly typed...
> > 
> > Congratulations. You've just described Ruby. And an apple-
> > cart full of other languages as well.
> 
> OK, so? Does that invalidate my statement? And even if it
> did, that has almost nothing to do with my original
> question. 

But since your assertion of: "Python, like Lisp, has X,Y and
Z features in common" and furthermore that: "I cannot find
another language that has exactly these X, Y and Z
features", was used by you as a justification for this
feature request. That's why i had to attack it. Because it
was false.

> > > I don't consider myself a fanboy - I've used Lisp for
> > > most of my career, and now I happily use Python for 80%
> > > of what I do, even if it means putting up with the
> > > occasional limitation, as in this case.
> > 
> > (not that i'm defending Python here...) but how do you
> > know that this so-called missing "feature" is a
> > limitation?
> 
> Because (again in my own personal opinion) Lisp macros are
> wonderful, they increase programmer productivity
> enormously, and not having them when I'm programming in
> other languages is a limitation from my point of view,
> since I enjoy using them so much.

Well, i can understand your enthusiasm, i myself become
highly animated about certain topics (just ask my CO-EDs!).
But you also need to understand that i am person of
_reasoned_ principles. And i try not to violate my
principles just because some random peddler shows-up one day
on my front porch with a slick sales pitch for the next
generation of vacuum cleaners. My vacuum cleaner works just
fine, thank you very much, and until it stops working, or
until you convince me that purchasing a new vacuum will
bring me a good return on my investment, and, furthermore,
will not violate my beloved principles, then i will consider
your product. However, so far, your sales pitch and
demonstrasion have left much to be desired. And i i'm not
mistaken, i believe you machine missed a few Doritos crumbs
under that coffee table over there. Hmm...

> > How many other languages use this "feature"?
> 
> Almost none, unfortunately. So?

Which raises a red flag for me. If this feature is as great
as you say, then why has no other language adopted it? Are
macros a recent addition to Lisp? As in: "Yesterday"?

> > And how many programmers swear they could not live without
> > it? We need stats; hyperlinks; and eye witness
> > testimonials. Heck, even a random YouTube vid would be
> > helpful.
> 
> I don't see why. I'm just talking about something that I
> personally feel the need for, I'm not trying to convert
> anyone.

It would help us decide if the feature is worth adding. If
only one person, or a handful of people use a feature, then
what is the benefit of spending multiple hours writing,
debugging and maintaining it? Adding feature to a language
is a very risky process that should never be done
hastefully. Only after careful consideration, and majority
support from the community, should new feature be added.
Would you agree?

> > > Why "thankfully"? Having macros in Python would be great.
> > > Of course it's not possible because of the syntax, but it
> > > would be great nevertheless :)
> > 
> > To me, macros would seem to violate Python's "explicit is
> > better than implicit" philosophy.
> 
> But that's exactly why I would like to be able to use
> macros. I think that being able to write "return if this
> happens" is much more explicit than having to write the
> full if statement, every time. The idea is that you
> abstract a pattern giving it a name, so every time you see
> that name you know immediately what's going to happen,
> without having to decode the conditional in your mind.

Oh, you mean something like this?

    # Python2.x (with print function enabled)
    >>> value = 5
    >>> isValueLessThanTenAndGreaterThanfour = (value < 10 and value > 4)
    >>> myList = range(10, 100, 10)
    >>> isValueInMyList = myList.count(value)>0
    >>> isValueAFloat = isinstance(value, float)
    >>> if isValueAFloat:
    ...     print('value is a float!')
    ... elif isValueInMyList:
    ...     print('value is in myList!')
    ... elif isValueLessThanTenAndGreaterThanfour:
    ...     print('value is less than 10 and greater than four!')
    ... else:
    ...     print('Where's a Dorito when you need one? o_O')
    ...     
    value is less than 10 and greater than four!


> > > > Possibly. But you've already poo-pooed the easy and
> > > > obvious solution of using conditional logic.
> > >
> > > Not really. It's obvious that I'm going to use a
> > > conditional, I was just asking for a way to avoid having
> > > to type the same conditional over and over. Computers are
> > > meant to do work for you, after all, aren't they? :)
> > 
> > A reasonable argument, i admit. But again, here in the
> > peaceful fields of "Pythonia", most of us feel that
> > "explicit is better than implicit". And why? Well, because
> > code is read more often than it is written, and as such,
> > explicit code will be of enormous help during the
> > debugging process. Sure, you may save yourself a few key-
> > strokes with features like macros, but at what cost? No
> > action is without consequences, dontchaknow?
> 
> I agree completely. Maybe we're using two different
> definitions of the word macro (I'm not sure how familiar
> you are with Lisp macros), but in my view their biggest
> advantage is that they make the code more readable and more
> explicit. 

I believe you have totally different definition of "explicit" than i
(and possibly most people). You use "explicit" to mean what
i understand as being "idiomatic". Or possibly, and more
accurately: "idiosyncratic". You have a particular way of
doing things. A way that is comfortable for _you_. And there
is nothing wrong with that. But one thing you must remember
is that Python is not Lisp. And if a feature is to be
borrowed from Lisp, then such feature should not be allowed
to violate certain principles of Python's core design
philosophy. These principles are:

    >>> import this
    The Zen of Python, by Tim Peters
    
    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    Readability counts.
    Special cases aren't special enough to break the rules.
    Although practicality beats purity.
    Errors should never pass silently.
    Unless explicitly silenced.
    In the face of ambiguity, refuse the temptation to guess.
    There should be one-- and preferably only one --obvious way to do it.
    Although that way may not be obvious at first unless you're Dutch.
    Now is better than never.
    Although never is often better than *right* now.
    If the implementation is hard to explain, it's a bad idea.
    If the implementation is easy to explain, it may be a good idea.
    Namespaces are one honking great idea -- let's do more of those!
    
And if we cannot find a way for your feature to _not_
violate these fine principles, then it shouldn't even be
considered.

> And the issue of debugging is an orthogonal one,
> good development environments allow you to work on the
> original and the macro-expanded code equally easily.

I think in many languages, especially Lisp (a language who's
syntax is not very human friendly), adding the old "a
developement environment cures all ills" to your argument in
an attempt to soften the blow created by the destructive
feature is reasonable. But again, and i hate to sound like a
broken record here, Python is not Lisp.