Current Syntax:

     with res << func(arg1) << 'x, y':
         print(x, y)

     with res << func(arg1) << block_name << 'x, y':
         print(x, y)

New Syntax:

     with res == func(arg1) .taking_block (x, y):
         print(x, y)

     with res == func(arg1) .taking_block (x, y) as block_name:
         print(x, y)

The full form is equivalent to

     def anon_func(x, y):
         print(x, y)
     res = func(arg1, block_name = anon_func)

Suggestions?

    The full form is equivalent to
         def anon_func(x, y):
             print(x, y)
         res = func(arg1, block_name = anon_func)

but this doesn't mean anything to me. What's func? Where does it come
from? What's arg1? Why does something called block_NAME have a default
value of a function instead of a NAME?

How about you give an actual working example of what you mean by a code
block and how you use it?

1)
  with res << func(args) << 'x, y':
      <code>

  --->

  def anon_func(x, y):
      <code>
  res = func(args, anon_func)

2)
  with res << func(args) << block_name << 'x, y':
      <code>

  --->

  def anon_func(x, y):
      <code>
  res = func(args, block_name = anon_func)

That's all.
func is some function which takes a function as a positional argument or as a keyword parameter neamed block_name.

Some examples:

1)
  text = "Anyone should be able to read this message!"
  with ris << re.sub(r'(\w)(\w+)(\w)', string = text) << repl << 'm':
      inner_word = list(m.group(2))
      random.shuffle(inner_word)
      _return (m.group(1) + "".join(inner_word) + m.group(3))
  print(ris)

which prints (something like):

  Aynnoe shluod be albe to read tihs msgseae!

2)
  numbers = [random.randint(1, 100) for i in range(30)]

  with sorted1 << sorted(numbers) << key << 'x':
      if x <= 50:
          _return(-x)
      else:
          _return(x)

  print(sorted1)

which prints (something like):
  [50, 47, 46, 28, 28, 25, 24, 23, 21, 19, 16, 15, 14, 3, 52, 52, 53, 54, 58, 62,
63, 69, 70, 72, 74, 78, 84, 86, 90, 97]

Hey, guys, am I the only one here who can't even guess what
this code does?  When did Python become so obscure?

Far from Pythonic, this seems to be an attempt to write some other
language in Python code.

AFAICT the above code is a proposal. I don't know who (other than the
original poster) thinks it's any good.

    libbnem. BN_add .argtypes = [ctypes.POINTER (BignumType), ctypes.POINTER (BignumType),
ctypes.POINTER (BignumType)]
    libbnem. BN_add .restype = ctypes.c_int
    libbnem. BN_add_word .argtypes = [ctypes.POINTER (BignumType), ctypes.c_ulong]
    libbnem. BN_add_word .restype = ctypes.c_int

    libbnem. BN_sub .argtypes = [ctypes.POINTER (BignumType), ctypes.POINTER (BignumType),
ctypes.POINTER (BignumType)]
    libbnem. BN_sub .restype = ctypes.c_int
    libbnem. BN_sub_word .argtypes = [ctypes.POINTER (BignumType), ctypes.c_ulong]
    libbnem. BN_sub_word .restype = ctypes.c_int

(there were a lot more in the original program where those came from.)  Another take-away
might be don't use boilerplate, but in the situation I didn't see a simple way to avoid it.

for op, op_word in ((libbnem.BN_add, libbnem.BN_add_word),
                     (libbnem.BN_sub, libbnem.BN_sub_word)):
     op.argtypes = [BignumTypePtr] * 3
     op_word.argtypes = [BignumTypePtr, ctypes.c_ulong]
     op.restype = op_word.restype = ctypes.c_int

Regarding ctypes, try this to convince yourself that there's no problem
in reusing BignumPtrType:
     from ctypes import POINTER, c_int
     assert POINTER(c_int) is POINTER(c_int)

For instance, assume that you want to write a function that accepts a
dictionary of callbacks:
   func(some_args, callbacks)

Pythonic way
------------

def when_odd(n):
     pass

def when_prime(n):
     pass

def before_check():
     pass

def after_check():
     pass

func(some_args, {'when_odd' : when_odd,
                  'when_prime' : when_prime,
                  'before_check' : before_check,
                  'after_check' : after_check})

def when_prime(n):
     pass

def when_perfect(n):
     pass

def before_reduction()
     pass

def after_reduction():
     pass

func(some_args, {'when_prime' : when_prime,
                  'when_perfect' : when_perfect,
                  'before_reduction' : before_reduction,
                  'after_reduction' : after_reduction})

My way
------

with func(some_args) << ':dict':
     with when_odd as 'n':
         pass
     with when_prime as 'n':
         pass
     with before_check as '':
         pass
     with after_check as '':
         pass

with func(some_args) << ':dict':
     with when_prime as 'n':
         pass
     with when_perfect as 'n':
         pass
     with before_reduction as '':
         pass
     with after_reduction as '':
         pass

SyntaxError: can't assign to literal

Have you actually tried to use these code blocks of yours? I asked you
for a *working* example earlier, and you replied with examples that
failed with multiple NameErrors and no hint as to how to fix them. And
now you give an example that fails with SyntaxError. I'm reluctantly
coming to the conclusion that these "code blocks" of yours simply do not
work.

Of course you do -- all non-trivial software has bugs. The question is,
how are you going to find it? You can't unit-test the individual
callbacks, because they don't exist in a form that can be tested.

So in this case, even though Python is slightly more verbose, and forces
you to have the discipline of writing named functions ahead of time, this
is actually a *good* thing because it encourages you to test them.

If the callbacks are trivial functions, the Pythonic way is to use
lambdas:

func(some_args, {'when_odd': lambda n: n-1,
                 'when_prime': lambda n: n**2 - 1,
                 ...})

although I would discourage that unless they are *really* trivial. But
for callbacks of any complexity, they will need to be tested, otherwise
how do you know they do what you want them to do?

Your code blocks make unit testing of the callbacks impossible, and for
that reason the Pythonic way is better.

Look, this isn't difficult. I asked for *working* examples, you gave
examples that give NameError. Some of those errors are easy to fix, e.g.
by importing the random and re modules. Some of them aren't. What are
"ris", "repl", "_return", "sorted1", "key"? Where do they come from? What
value should I give them to make your code work?

Code doesn't magically start to work because you declare that it does.
Anyone who takes the time to copy and paste your examples into a fresh
Python interactive session will see that they don't.

Here's one of your earlier examples. I've removed the unnecessary
indentation and made the obvious import, so all it takes to run it is to
copy it and paste into the Python prompt:

import random
numbers = [random.randint(1, 100) for i in range(30)]
with sorted1 << sorted(numbers) << key << 'x':
    if x <= 50:
        _return(-x)
    else:
        _return(x)

print(sorted1)

If you try it, you get

NameError: name 'sorted1' is not defined

Fix that (how?) and you'll get another NameError, for 'key', and then a
third, for '_return'.

The syntax isn't very clear. If I had to guess what it does, I'd predict
that maybe it sorts the random list and negates everything <= 50, e.g.
given input [5, 99, 34, 88, 70, 2] it returns [-2, -5, -34, 70, 88, 99].
Obviously that's wrong. You say it should return [34, 5, 2, 70, 88, 99].

The Pythonic way to get that result is:

import random
numbers = [random.randint(1, 100) for i in range(30)]
sorted(numbers, key=lambda x: -x if x <= 50 else x)

which is much more straightforward and obvious than yours, and presumably
much faster. So even if I could get your example working, it would not be
very persuasive.

Believe it or not, the world does not revolve around you. We cannot see
what is in your head. If we ask for a WORKING EXAMPLE, you need to give
an example that includes EVERYTHING necessary to make it work.

[...]

This is comedy gold.

The term missing from Steven's request is “minimal”. When presenting
code for examination by others, we request that you present a complete,
minimal, working example.

Complete, so that we can take what you present and use it without
guessing (likely incorrect guesses) what extra bits you did.

Minimal, so that it contains *only* what is needed to demonstrate what
you're trying to communicate. Yes, this probably means writing an
example specifically to present to us; tough, the job falls to you if
you want us to spend time on your issue.

Working example: so that it actually does what you say it does, and we
can verify that directly instead of speculating.

You have entered may people's kill files, including mine, because of
this inability to take criticism and this tendency to insult others
baselessly.

On May 2, 12:18 am, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:

At the very _least_, you could change the function call to:

    func(some_args, locals())

But as you're _passing them in by name_ why not just make it
func(some_args) and pick them up out of the scope.

_No one_ writes Python code like this. Presenting bad code as
"pythonic" is a bit of a straw man.

More importantly, _you're naming your "anonymous" code blocks_, I'm
guessing so that func() can choose which ones to use. But if you're
naming them, why not just use a function?

I'm not entirely sure what your 'solution' offers over something like:

class FOO(object):
    def __init__(self, fn):
        self.fn = fn

    def __enter__(self):
        return self.fn

    def __exit__(self, exc_type, exc_value, traceback):
        pass

def func(x, before_check=None, after_check=None, when_odd=None,
when_prime=None):
    pass

with FOO(func) as f:
    def before_check(x):
        pass
    def after_check(x):
        pass
    def when_odd(x):
        pass
    def when_prime(x):
        pass

    f(1)

I called the context manager FOO because I couldn't think of a more
appropriate name (contextscope?)...which is fair, as I can't think of
a use for it either. If you want to automate the function call at the
context manager exit, use something like this instead:

class FOO(object):
    def __init__(self, fn, *args, **kwargs):
        self.fn = fn
        self.args = args
        self.kwargs = kwargs

    def __enter__(self):
        f = inspect.currentframe(1)
        self.scope_before = dict(f.f_locals)

    def __exit__(self, exc_type, exc_value, traceback):
        f = inspect.currentframe(1)
        scope_after = dict(f.f_locals)
        scope_context = set(scope_after) - set(self.scope_before)
        clocals = dict(
            [(k, scope_after[k]) for k in scope_context]
        )
        self.kwargs.update(clocals)
        self.fn(*self.args, **self.kwargs)

Presenting bad examples as the Pythonic approach is a bit of a straw
man.

1. You're effectively making "with when_odd as 'n'" mean "def
when_odd(n)"
2. The 'with code_block_name as arguments' syntax is unintuitive, to
say the least.

Personally, I don't see what value it provides over something more
explicit and standard:

def func(x, before_check=None, after_check=None, when_odd=None,
when_prime=None):
    pass

with FOO(func, arg):
    def before_check(x):
        pass
    def after_check(x):
        pass
    def when_odd(x):
        pass
    def when_prime(x):
        pass

I couldn't think of a name for the context manager...but I can't
really think of a use for it either, so that seems fair.

Actually, here's an even simpler example. In this case, the context
manager doesn't have to interrogate the surrounding stack, but the
function call itself is then explicit.

class FOO(object):
    def __init__(self, fn):
        self.fn = fn

    def __enter__(self):
        return self.fn

    def __exit__(self, exc_type, exc_value, traceback):
        pass

def func(x, before_check=None, after_check=None, when_odd=None,
when_prime=None):
    pass

with FOO(func) as f:
    def before_check(x):
        pass
    def after_check(x):
        pass
    def when_odd(x):
        pass
    def when_prime(x):
        pass

    f(1)

I remember a post on this ng when one would create a list of commands
and then use that list as a switch table. My module let you do that very
easily. The syntax is:

     with func() << ':list':
         with 'arg':
             cmd_code
         with 'arg':
             cmd_code
         with '':
             cmd_code

This is very common in Python:

    from module1 import func1

    def func2(args): pass

    def main():
        # do something with func1 and func2

And I've never had problems maintaining code like this. I know
_exactly_ the scope that the functions exist within because I added
them to it. They're not _global_ because they're restricted to that
specific scope.

Then again, it's _really difficult_ to tell if something named
'func()' could have a real use like this.