syntax for code blocks

[Kiuhnm]

I'd like to change the syntax of my module 'codeblocks' to make it more
pythonic.

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?

Kiuhnm
--
http://mail.python.org/mailman/listinfo/python-list

[Steven D'Aprano-11]

On Fri, 27 Apr 2012 13:24:35 +0200, Kiuhnm wrote:

> I'd like to change the syntax of my module 'codeblocks' to make it more
> pythonic.
>
> Current Syntax:
>
>      with res << func(arg1) << 'x, y':
>          print(x, y)
>
>      with res << func(arg1) << block_name << 'x, y':
>          print(x, y)

I'm sorry, I don't see how this is a code block. Where is the code in the
block, and how can you pass it to another object to execute it?



--
Steven
--
http://mail.python.org/mailman/listinfo/python-list

[Kiuhnm]

On 4/27/2012 16:09, Steven D'Aprano wrote:

> On Fri, 27 Apr 2012 13:24:35 +0200, Kiuhnm wrote:
>
>> I'd like to change the syntax of my module 'codeblocks' to make it more
>> pythonic.
>>
>> Current Syntax:
>>
>>       with res << func(arg1) << 'x, y':
>>           print(x, y)
>>
>>       with res << func(arg1) << block_name << 'x, y':
>>           print(x, y)
>
>
> I'm sorry, I don't see how this is a code block. Where is the code in the
> block, and how can you pass it to another object to execute it?

Maybe if you read the entire post...

Kiuhnm
--
http://mail.python.org/mailman/listinfo/python-list

[Steven D'Aprano-11]

On Fri, 27 Apr 2012 17:03:19 +0200, Kiuhnm wrote:

> On 4/27/2012 16:09, Steven D'Aprano wrote:
>> On Fri, 27 Apr 2012 13:24:35 +0200, Kiuhnm wrote:
>>
>>> I'd like to change the syntax of my module 'codeblocks' to make it
>>> more pythonic.
>>>
>>> Current Syntax:
>>>
>>>       with res << func(arg1) << 'x, y':
>>>           print(x, y)
>>>
>>>       with res << func(arg1) << block_name << 'x, y':
>>>           print(x, y)
>>
>>
>> I'm sorry, I don't see how this is a code block. Where is the code in
>> the block, and how can you pass it to another object to execute it?
>
> Maybe if you read the entire post...

No, I read the entire post. It made no sense to me. Let me give one
example. You state:

    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?


--
Steven
--
http://mail.python.org/mailman/listinfo/python-list

[Ian Kelly-2]

On Fri, Apr 27, 2012 at 10:07 AM, Steven D'Aprano
<[hidden email]> wrote:
> How about you give an actual working example of what you mean by a code
> block and how you use it?

He wrote a full blog post about it last week:

http://mtomassoli.wordpress.com/2012/04/20/code-blocks-in-python/
--
http://mail.python.org/mailman/listinfo/python-list

[Kiuhnm]

On 4/27/2012 18:07, Steven D'Aprano wrote:

> On Fri, 27 Apr 2012 17:03:19 +0200, Kiuhnm wrote:
>
>> On 4/27/2012 16:09, Steven D'Aprano wrote:
>>> On Fri, 27 Apr 2012 13:24:35 +0200, Kiuhnm wrote:
>>>
>>>> I'd like to change the syntax of my module 'codeblocks' to make it
>>>> more pythonic.
>>>>
>>>> Current Syntax:
>>>>
>>>>        with res<<  func(arg1)<<  'x, y':
>>>>            print(x, y)
>>>>
>>>>        with res<<  func(arg1)<<  block_name<<  'x, y':
>>>>            print(x, y)
>>>
>>>
>>> I'm sorry, I don't see how this is a code block. Where is the code in
>>> the block, and how can you pass it to another object to execute it?
>>
>> Maybe if you read the entire post...
>
> No, I read the entire post. It made no sense to me. Let me give one
> example. You state:
>
>      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?

The rewriting rules are the following, where X ---> Y means that X is rewritten as Y on the fly:

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]

Kiuhnm
--
http://mail.python.org/mailman/listinfo/python-list

[Ethan Furman-2]

Kiuhnm wrote:

> I'd like to change the syntax of my module 'codeblocks' to make it more
> pythonic.
>
> 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?

I don't find either the current syntax nor the new syntax pythonic.

~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

[Peter Pearson-3]

On Fri, 27 Apr 2012 13:24:35 +0200, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:

> I'd like to change the syntax of my module 'codeblocks' to make it more
> pythonic.
>
> 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)

[snip]

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

--
To email me, substitute nowhere->spamcop, invalid->net.
--
http://mail.python.org/mailman/listinfo/python-list

[Temia Eszteri]

>> 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)
>[snip]
>
>Hey, guys, am I the only one here who can't even guess what
>this code does?  When did Python become so obscure?
>
>--
>To email me, substitute nowhere->spamcop, invalid->net.

No, it's pretty impenetratable to me at a passing glance too. Not sure
if I'd get anywhere handtracing it, though.

~Temia
--
When on earth, do as the earthlings do.
--
http://mail.python.org/mailman/listinfo/python-list

[Ben Finney-10]

Peter Pearson <[hidden email]> writes:

> On Fri, 27 Apr 2012 13:24:35 +0200, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:

> > I'd like to change the syntax of my module 'codeblocks' to make it
> > more pythonic.

The “chained callable” style isn't very Pythonic, IMO. Even worse is the
penchant for ‘foo .bar()’, the space obscures the fact that this is
attribute access.

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

> > 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)
> [snip]
>
> Hey, guys, am I the only one here who can't even guess what
> this code does?  When did Python become so obscure?

No, you're not alone; I think that code is pretty poor at communicating
the intent.

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

--
 \       “I cannot be angry at God, in whom I do not believe.” —Simone |
  `\                                                       De Beauvoir |
_o__)                                                                  |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list

[Serhiy Storchaka-2]

29.04.12 19:05, Peter Pearson написав(ла):
> Hey, guys, am I the only one here who can't even guess what
> this code does?  When did Python become so obscure?

This isn't Python at all. It's Ruby.

--
http://mail.python.org/mailman/listinfo/python-list

[mwilson]

Ben Finney wrote:

> [ ... ] Even worse is the
> penchant for ‘foo .bar()’, the space obscures the fact that this is
> attribute access.

I like the style sometimes when it helps to break the significantly different parts out of
boilerplate:

    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.

        Mel.
--
http://mail.python.org/mailman/listinfo/python-list

[Kiuhnm]

On 4/30/2012 16:17, [hidden email] wrote:

> Ben Finney wrote:
>
>> [ ... ] Even worse is the
>> penchant for ‘foo .bar()’, the space obscures the fact that this is
>> attribute access.
>
> I like the style sometimes when it helps to break the significantly different parts out of
> boilerplate:
>
>      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.
>
> Mel.

BignumTypePtr = ctypes.POINTER(BignumType)

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

Kiuhnm
--
http://mail.python.org/mailman/listinfo/python-list

[Kiuhnm]

On 4/30/2012 17:02, Kiuhnm wrote:

> On 4/30/2012 16:17, [hidden email] wrote:
>> Ben Finney wrote:
>>
>>> [ ... ] Even worse is the
>>> penchant for ‘foo .bar()’, the space obscures the fact that this is
>>> attribute access.
>>
>> I like the style sometimes when it helps to break the significantly
>> different parts out of
>> boilerplate:
>>
>> 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.
>>
>> Mel.
>
> BignumTypePtr = ctypes.POINTER(BignumType)
>
> 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

On second thought, BignumPtrType is probably the right name.

Kiuhnm
--
http://mail.python.org/mailman/listinfo/python-list

[mwilson]

> On 4/30/2012 17:02, Kiuhnm wrote:
>> BignumTypePtr = ctypes.POINTER(BignumType)
>>
>> 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
>
> On second thought, BignumPtrType is probably the right name.

(Way off the original topic, aren't we?)  I haven't looked inside ctypes,
and don't know what kind of thing ctypes.POINTER actually constructs.  I was
worried about falling into a [[a]]*3 kind of error -- unwittingly sharing a
mutable object.  I guess I really should look.

        Mel.

--
http://mail.python.org/mailman/listinfo/python-list

[Kiuhnm]

On 4/30/2012 17:42, [hidden email] wrote:

>> On 4/30/2012 17:02, Kiuhnm wrote:
>>> BignumTypePtr = ctypes.POINTER(BignumType)
>>>
>>> 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
>>
>> On second thought, BignumPtrType is probably the right name.
>
> (Way off the original topic, aren't we?)  I haven't looked inside ctypes,
> and don't know what kind of thing ctypes.POINTER actually constructs.  I was
> worried about falling into a [[a]]*3 kind of error -- unwittingly sharing a
> mutable object.  I guess I really should look.

Better off topic than uninterestingly in topic, IMHO.

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)

Kiuhnm
--
http://mail.python.org/mailman/listinfo/python-list

[mwilson]

Kiuhnm wrote:
> 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)

print ('POINTERs are shareable:', ctypes.POINTER (BignumType) is ctypes.POINTER
(BignumType))
[ ... ]
('POINTERs are shareable:', True)

Thanks.
        Mel.

--
http://mail.python.org/mailman/listinfo/python-list

[Ben Finney-10]

[hidden email] writes:

> Another take-away might be don't use boilerplate, but in the situation
> I didn't see a simple way to avoid it.

It seems we agree, then, that avoiding boilerplate code is preferable to
writing bad boilerplate code.

--
 \          “Computer perspective on Moore's Law: Human effort becomes |
  `\           twice as expensive roughly every two years.” —anonymous |
_o__)                                                                  |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list

[alex23]

On Apr 30, 2:05 am, Peter Pearson <[hidden email]> wrote:
> Hey, guys, am I the only one here who can't even guess what
> this code does?  When did Python become so obscure?

Thankfully it hasn't. The most Pythonic way to pass around a code
block is still to use a function.

--
http://mail.python.org/mailman/listinfo/python-list

[Kiuhnm]

On 5/1/2012 5:27, alex23 wrote:
> On Apr 30, 2:05 am, Peter Pearson<[hidden email]>  wrote:
>> Hey, guys, am I the only one here who can't even guess what
>> this code does?  When did Python become so obscure?
>
> Thankfully it hasn't. The most Pythonic way to pass around a code
> block is still to use a function.

"Most Pythonic" doesn't mean better, unfortunately.

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

Kiuhnm
--
http://mail.python.org/mailman/listinfo/python-list