Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #89831 > unrolled thread

code blocks

Back to article view | Back to comp.lang.python

Contents

  code blocks "Dr. John Q. Hacker" <zondervanz@gmail.com> - 2015-05-02 13:30 -0500
    Re: code blocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-03 11:56 +0100
    Re: code blocks zipher <dreamingforward@gmail.com> - 2015-05-10 18:39 -0700
      Re: code blocks Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-10 21:31 -0600
        Re: code blocks Rustom Mody <rustompmody@gmail.com> - 2015-05-10 20:40 -0700
        Re: code blocks zipher <dreamingforward@gmail.com> - 2015-05-11 08:22 -0700
          Re: code blocks zipher <dreamingforward@gmail.com> - 2015-05-11 08:23 -0700
          Re: code blocks Chris Angelico <rosuav@gmail.com> - 2015-05-12 01:40 +1000
          Re: code blocks Peter Otten <__peter__@web.de> - 2015-05-11 18:01 +0200
          Re: code blocks Chris Angelico <rosuav@gmail.com> - 2015-05-12 02:07 +1000
            Re: code blocks zipher <dreamingforward@gmail.com> - 2015-05-11 09:51 -0700
          Re: code blocks Peter Otten <__peter__@web.de> - 2015-05-11 18:59 +0200
      Re: code blocks Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-10 21:36 -0600

#89831 — code blocks

[Multipart message — attachments visible in raw view] — view raw

Hello,

I'm thinking how interesting it would be to add code blocks to Python, so
that arbitrary strings of code can be passed around.   It would open up
some interesting possibilities for self-modifying code and generic
programming.

Since Python has already a plethora of ambiguous string designations, one
of them could be set aside specificially for code blocks:

"""for i in n: print i"""

For any variables, like "n", it would access the scope in which it was
running.  When you tried to print a triple-double-quoted code block,
perhaps it could invoke the code.

My suggestion would be to use triple double-quoted strings.

You probably already know that Ruby has code blocks.

zipher

[toc] | [next] | [standalone]

#89853

"Dr. John Q. Hacker" <zondervanz@gmail.com> writes:

> I'm thinking how interesting it would be to add code blocks to Python,
> so that arbitrary strings of code can be passed around. It would open
> up some interesting possibilities for self-modifying code and generic
> programming.
>
> Since Python has already a plethora of ambiguous string designations,
> one of them could be set aside specificially for code blocks:
>
> """for i in n: print i"""
>
> For any variables, like "n", it would access the scope in which it was
> running. When you tried to print a triple-double-quoted code block,
> perhaps it could invoke the code.
>
> My suggestion would be to use triple double-quoted strings. 
>
> You probably already know that Ruby has code blocks.

What Ruby calls code blocks, Python calls lambdas:

  Ruby:  [1,2,3].map { |x| x*x }
  Python: map(lambda x: x*x, [1,2,3])

In some cases, the lambda is implicit.  For example, the above can be
written as

  [x*x for x in [1,2,3]]

You can use strings (if you really must), using eval() at the
appropriate place eval() but that opens up all sorts of cans of worms.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#90325

 > I'm thinking how interesting it would be to add code blocks to Python, so that arbitrary strings of code can be passed around.   It would open up some interesting possibilities for self-modifying code and generic programming.
>
> My suggestion would be to use triple double-quoted strings.  

Hmmm.  Would be interesting to do this:

>>> codestr = decode(SomeClass)

...and have it return a triple-quoted string of the perhaps-reduced source for the class.  It's like serialization of code objects, but the serialization is just the source string w/LFs that would re-make the object.

Similarly, you'd want:

>>> encode(codestr)

to instantiate all objects in the codestr.  You can't do this with eval, because it doesn't allow assignment (eval(n=2) returns "InvalidSyntax").

mark

[toc] | [prev] | [next] | [standalone]

#90339

On Sun, May 10, 2015 at 7:39 PM, zipher <dreamingforward@gmail.com> wrote:
> Similarly, you'd want:
>
>>>> encode(codestr)
>
> to instantiate all objects in the codestr.  You can't do this with eval, because it doesn't allow assignment (eval(n=2) returns "InvalidSyntax").

Is exec what you're looking for?

>>> exec('n = 2')
>>> print(n)
2

[toc] | [prev] | [next] | [standalone]

#90341

On Monday, May 11, 2015 at 9:02:07 AM UTC+5:30, Ian wrote:
> Is exec what you're looking for?

Now Now Ian!

In classical times, corrupting the youth would fetch you a cup of hemlock.

Community service it is nowadays.

[toc] | [prev] | [next] | [standalone]

#90395

On Sunday, May 10, 2015 at 10:32:07 PM UTC-5, Ian wrote:
> On Sun, May 10, 2015 at 7:39 PM, zipher <dreamingforward@gmail.com> wrote:
> > Similarly, you'd want:
> >
> >>>> encode(codestr)
> >
> > to instantiate all objects in the codestr.  You can't do this with eval, because it doesn't allow assignment (eval(n=2) returns "InvalidSyntax").
> 
> Is exec what you're looking for?
> 
> >>> exec('n = 2')
> >>> print(n)
> 2

Ah, yeah, I guess that does it.  But (shame) it looks like you've gone past the BDFL.  Try:

>>> help(exec)
            ^
SyntaxError: invalid syntax 

Better

Mark

[toc] | [prev] | [next] | [standalone]

#90397

On Monday, May 11, 2015 at 10:22:15 AM UTC-5, zipher wrote:
> Ah, yeah, I guess that does it.  But (shame) it looks like you've gone past the BDFL.  Try:
> [...]
> Better

Oops, omit word "better".  Sent before reading over it again...

m

[toc] | [prev] | [next] | [standalone]

#90402

On Tue, May 12, 2015 at 1:22 AM, zipher <dreamingforward@gmail.com> wrote:
> Ah, yeah, I guess that does it.  But (shame) it looks like you've gone past the BDFL.  Try:
>
>>>> help(exec)
>             ^
> SyntaxError: invalid syntax
>

That's because, in the version of Python you're using, exec is a
keyword. You could switch to Python 3, where it's a function, or
request it by name. Though interestingly, my Py2 doesn't have any help
on exec:

>>> help('exec')
no documentation found for 'exec'

Not sure why that is.

ChrisA

[toc] | [prev] | [next] | [standalone]

#90406

Chris Angelico wrote:

> On Tue, May 12, 2015 at 1:22 AM, zipher <dreamingforward@gmail.com> wrote:
>> Ah, yeah, I guess that does it.  But (shame) it looks like you've gone
>> past the BDFL.  Try:
>>
>>>>> help(exec)
>>             ^
>> SyntaxError: invalid syntax
>>
> 
> That's because, in the version of Python you're using, exec is a
> keyword. You could switch to Python 3, where it's a function, or
> request it by name. Though interestingly, my Py2 doesn't have any help
> on exec:
> 
>>>> help('exec')
> no documentation found for 'exec'
> 
> Not sure why that is.

Path confusion? You may accidentally be importing Python 3's topics. 
Try

>>> from pydoc_data import topics
>>> topics.__file__
'/usr/lib/python2.7/pydoc_data/topics.pyc'
>>> "exec" in topics.topics
True
>>> help("exec")
The ``exec`` statement
[...]

>>> import sys
>>> sys.path.insert(0,  "/usr/lib/python3.4")
>>> del sys.modules["pydoc_data"]
>>> del sys.modules["pydoc_data.topics"]
>>> help("exec")
no documentation found for 'exec'

[toc] | [prev] | [next] | [standalone]

#90407

On Tue, May 12, 2015 at 2:01 AM, Peter Otten <__peter__@web.de> wrote:
> Though interestingly, my Py2 doesn't have any help
>> on exec:
>>
>>>>> help('exec')
>> no documentation found for 'exec'
>>
>> Not sure why that is.
>
> Path confusion? You may accidentally be importing Python 3's topics.
> Try
>
>>>> from pydoc_data import topics
>>>> topics.__file__
> '/usr/lib/python2.7/pydoc_data/topics.pyc'
>>>> "exec" in topics.topics
> True

Peculiar.

$ python
Python 2.7.3 (default, Mar 13 2014, 11:03:55)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pydoc_data import topics
>>> topics.__file__
'/usr/lib/python2.7/pydoc_data/topics.pyc'
>>> "exec" in topics.topics
False
>>> topics.topics.keys()
['conversions', 'debugger', 'attribute-access', 'augassign',
'numeric-types', 'context-managers', 'bitwise', 'global', 'numbers',
'customization', 'in', 'floating', 'integers', 'naming', 'if',
'binary', 'raise', 'for', 'typesmapping', 'subscriptions',
'specialnames', 'typesseq', 'dynamic-features', 'bltin-code-objects',
'continue', 'dict', 'bltin-type-objects', 'import', 'typesmethods',
'pass', 'atom-literals', 'slicings', 'function', 'typesseq-mutable',
'bltin-ellipsis-object', 'execmodel', 'return', 'exprlists', 'power',
'booleans', 'string-methods', 'assignment', 'callable-types', 'yield',
'lists', 'else', 'assert', 'formatstrings', 'objects', 'shifting',
'unary', 'compound', 'typesfunctions', 'imaginary', 'specialattrs',
'with', 'class', 'types', 'break', 'calls', 'try', 'identifiers',
'atom-identifiers', 'id-classes', 'bltin-null-object', 'while',
'attribute-references', 'del', 'truth', 'sequence-types',
'exceptions', 'comparisons', 'operator-summary', 'typesmodules',
'strings', 'lambda']

Whatever. I've made a few messes on this system, maybe I broke
something somewhere. In any case, help('exec') is what's needed for
help on keywords, even if one particular installation doesn't have one
particular keyword-help.

ChrisA

[toc] | [prev] | [next] | [standalone]

#90413

On Monday, May 11, 2015 at 11:08:14 AM UTC-5, Chris Angelico wrote:
> On Tue, May 12, 2015 at 2:01 AM, Peter Otten <__peter__@web.de> wrote:
> > Though interestingly, my Py2 doesn't have any help
> >> on exec:
> >>
> >>>>> help('exec')
> >> no documentation found for 'exec'
> >>
> >> Not sure why that is.
> >
> > Path confusion? You may accidentally be importing Python 3's topics.
> > Try
> >
> >>>> from pydoc_data import topics
> >>>> topics.__file__
> > '/usr/lib/python2.7/pydoc_data/topics.pyc'
> >>>> "exec" in topics.topics
> > True
> 
> Peculiar.
> 
> $ python
> Python 2.7.3 (default, Mar 13 2014, 11:03:55)
> [GCC 4.7.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from pydoc_data import topics
> >>> topics.__file__
> '/usr/lib/python2.7/pydoc_data/topics.pyc'
> >>> "exec" in topics.topics
> False
> >>> topics.topics.keys()
> ['conversions', 'debugger', 'attribute-access', 'augassign',
> 'numeric-types', 'context-managers', 'bitwise', 'global', 'numbers',
> 'customization', 'in', 'floating', 'integers', 'naming', 'if',
> 'binary', 'raise', 'for', 'typesmapping', 'subscriptions',
> 'specialnames', 'typesseq', 'dynamic-features', 'bltin-code-objects',
> 'continue', 'dict', 'bltin-type-objects', 'import', 'typesmethods',
> 'pass', 'atom-literals', 'slicings', 'function', 'typesseq-mutable',
> 'bltin-ellipsis-object', 'execmodel', 'return', 'exprlists', 'power',
> 'booleans', 'string-methods', 'assignment', 'callable-types', 'yield',
> 'lists', 'else', 'assert', 'formatstrings', 'objects', 'shifting',
> 'unary', 'compound', 'typesfunctions', 'imaginary', 'specialattrs',
> 'with', 'class', 'types', 'break', 'calls', 'try', 'identifiers',
> 'atom-identifiers', 'id-classes', 'bltin-null-object', 'while',
> 'attribute-references', 'del', 'truth', 'sequence-types',
> 'exceptions', 'comparisons', 'operator-summary', 'typesmodules',
> 'strings', 'lambda']
> 
> Whatever. I've made a few messes on this system, maybe I broke
> something somewhere. In any case, help('exec') is what's needed for
> help on keywords, even if one particular installation doesn't have one
> particular keyword-help.
> 
> ChrisA

It's strange, help(eval) works but help(exec) creates a SyntaxError, even though they would seem to be the same semantically -- both imperative verbs.  You nailed it by calling "exec" a keyword, but still it's a strange distinction.

Mark

[toc] | [prev] | [next] | [standalone]

#90414

Chris Angelico wrote:

> On Tue, May 12, 2015 at 2:01 AM, Peter Otten <__peter__@web.de> wrote:
>> Though interestingly, my Py2 doesn't have any help
>>> on exec:
>>>
>>>>>> help('exec')
>>> no documentation found for 'exec'
>>>
>>> Not sure why that is.
>>
>> Path confusion? You may accidentally be importing Python 3's topics.
>> Try
>>
>>>>> from pydoc_data import topics
>>>>> topics.__file__
>> '/usr/lib/python2.7/pydoc_data/topics.pyc'
>>>>> "exec" in topics.topics
>> True
> 
> Peculiar.
> 
> $ python
> Python 2.7.3 (default, Mar 13 2014, 11:03:55)
> [GCC 4.7.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> from pydoc_data import topics
>>>> topics.__file__
> '/usr/lib/python2.7/pydoc_data/topics.pyc'
>>>> "exec" in topics.topics
> False
>>>> topics.topics.keys()
> ['conversions', 'debugger', 'attribute-access', 'augassign',
> 'numeric-types', 'context-managers', 'bitwise', 'global', 'numbers',
> 'customization', 'in', 'floating', 'integers', 'naming', 'if',
> 'binary', 'raise', 'for', 'typesmapping', 'subscriptions',
> 'specialnames', 'typesseq', 'dynamic-features', 'bltin-code-objects',
> 'continue', 'dict', 'bltin-type-objects', 'import', 'typesmethods',
> 'pass', 'atom-literals', 'slicings', 'function', 'typesseq-mutable',
> 'bltin-ellipsis-object', 'execmodel', 'return', 'exprlists', 'power',
> 'booleans', 'string-methods', 'assignment', 'callable-types', 'yield',
> 'lists', 'else', 'assert', 'formatstrings', 'objects', 'shifting',
> 'unary', 'compound', 'typesfunctions', 'imaginary', 'specialattrs',
> 'with', 'class', 'types', 'break', 'calls', 'try', 'identifiers',
> 'atom-identifiers', 'id-classes', 'bltin-null-object', 'while',
> 'attribute-references', 'del', 'truth', 'sequence-types',
> 'exceptions', 'comparisons', 'operator-summary', 'typesmodules',
> 'strings', 'lambda']

Note that "print" is missing, too.

> Whatever. I've made a few messes on this system, maybe I broke
> something somewhere. 

Probably.

> In any case, help('exec') is what's needed for
> help on keywords, even if one particular installation doesn't have one
> particular keyword-help.

[toc] | [prev] | [next] | [standalone]

#90340

On Sun, May 10, 2015 at 9:31 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Sun, May 10, 2015 at 7:39 PM, zipher <dreamingforward@gmail.com> wrote:
>> Similarly, you'd want:
>>
>>>>> encode(codestr)
>>
>> to instantiate all objects in the codestr.  You can't do this with eval, because it doesn't allow assignment (eval(n=2) returns "InvalidSyntax").
>
> Is exec what you're looking for?
>
>>>> exec('n = 2')
>>>> print(n)
> 2

I just found that eval can be used to evaluate a code object compiled
in the 'exec' mode:

>>> eval(compile('n = 42', '', 'exec'))
>>> n
42

Interesting. But I suppose that the mode is really just a compilation
option and there's not really much distinction as far as eval is
concerned once they've been compiled.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web