Invoking return through a function?

[Alberto Riva]

As suggested by Ned I'm going to stop replying after pointing out just a 
couple of things. The most important one is the following:

 > 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.

I was not requesting any feature. I was just asking this group (that I 
assume includes people who are more experienced in Python than I am) if 
there was a way of doing something using the tools currently provided by 
Python. That was all.

Then I mentioned the fact that I'm used to a language in which this 
"something" is not necessary because you can get the same effect in a 
cleaner and more readable way using macros, but I was absolutely NOT 
advocating for the addition of Lisp-like macros to Lisp. I know 
perfectly well that it would be impossible, because they can only work 
in a language that has Lisp-like syntax (which, incidentally, I find 
much easier to read than Java syntax, for example; these things are 
highly subjective). And indeed, the fact that you thought I was asking 
for this shows that you don't really know what Lisp macros are, 
otherwise you would know that they're impossible to reproduce in Python.

So I apologize for any misunderstandings; I was not trying to sell 
anything to anyone, least of all vacuum cleaners. I was just asking for 
information.

Thanks,

Alberto

On 10/29/2017 04:35 PM, Rick Johnson wrote:
> 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.
> 


-- 
                 E-mail address:
((lambda (s a b c) (map 'string #'code-char (mapcar (lambda (v)
(setq s (+ a (mod (+ s v (- a)) b)))) (map 'list (lambda (v)
(- (char-code v) c)) " 1`-THUZ&+Wh1")))) 97 46 73 32)