from future import pass_function

[Joel Goldstick]

On Thu, Jul 26, 2012 at 11:21 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Thu, 26 Jul 2012 13:45:23 +0200, Ulrich Eckhardt wrote:
>
>> I didn't say "Pass should be a function!" but asked "What do you
>> think?". You are assuming lots of things about my goals and jumping to
>> conclusions like that I'm complaining about the stupid Python syntax,
>> that I'm a frustrated noob, that I want someone to fix that syntax, but
>> that is not the case! I'm engaging in a discussion here exactly in order
>> to test the idea I had.
>
> Fair point. I underestimated you. But go back and re-read your first
> post, and see if you can understand *why* I underestimated you. You
> really didn't give any sign that you had given this question much
> detailed thought.
>
> Perhaps if you had mentioned that you had not decided whether this was a
> good idea and was looking for arguments both for and against, this tone
> of this discussion would have been very different.
>
>
>
>>> It took me a long time to learn that, for an established language like
>>> Python, change is nearly always for the worse, and any change that
>>> requires changing existing code better have a very good excuse.
>>
>> ...so what do you do when you have an idea? You think about it on your
>> own, right? I do so, too, but I also engage in discussions with others.
>> See? BTW: I think you missed the implications of this thread's topic and
>> the snide remark about forcing people to change their code, i.e. that no
>> existing code has to change (apart from the Python implementation, of
>> course), even if pass was made a function!
>
> I think that you misunderstand the purpose of from __future__ import. It
> is a *temporary* measure, always. Features which are not backward
> compatible are FIRST introduced as __future__ features, and THEN a
> release or two later, they become mandatory. (Unless they are dropped,
> which has not happened yet.)
>
> There have been seven __future__ features as of Python 3.2:
>
> absolute_import (enabled in 2.5, mandatory in 2.7)
> division (enabled in 2.2, mandatory in 3.0)
> generators (enabled in 2.2, mandatory in 2.3)
> nested_scopes (enabled in 2.1, mandatory in 2.2)
> print_function (enabled in 2.6, mandatory in 3.0)
> unicode_literals (enabled in 2.6, mandatory in 3.0)
> with_statement (enabled in 2.5, mandatory in 2.6)
>
>
> In any case, I acknowledge that I was wrong about your motivation. I made
> a guess based on the limited information I had, and based on my own
> history, and you tell me my guess was wrong. I accept that.
>
>
>
> --
> Steven
> --
> http://mail.python.org/mailman/listinfo/python-list


This is the silliest thread I've ever seen in this group.  I should
abstain, but what the heck:

If you want a function that does nothing, write one.  Maybe like this:

def do_nothing():
    return

Then, where you previous wrote pass in your code you can replace it
with this thing.

But really, not being a language meta-maven myself, somewhere above in
this thread it was pointed out that pass is a syntax construction that
is necessary in the very seldom case where you create a block of code
that has no instructions.  Instead of braces for every block, you get
to skip that in python and just put pass in this extraordinary little
case.

While I've come to the point in my python coding knowledge to get my
day to day work done proficiently, I'm amazed each time I delve deeper
into how profoundly well this language was thought out.  No offence to
all the well meaning participants here, but this looks like trolling
-- 
Joel Goldstick