[Python-Dev] Re: Extended Function syntax

Samuele Pedroni pedronis@bluewin.ch
Fri, 31 Jan 2003 04:05:08 +0100


This is a multi-part message in MIME format.

------=_NextPart_000_1291_01C2C8DD.F168CCA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

From: "Guido van Rossum" <guido@python.org>
> > 2) a statement that captures and extends what class does now ("my"
proposal)
>
> Can you remind me of this?

just

kind  name [ '(' expr,... ')' ]  [ maybe [] extended syntax ]:
  suite

but introduced by a new keyword

KEYW-TO-BE kind  name [ '(' expr,... ')' ]  [ maybe [] extended syntax ]:
  suite

I think the first approach - if possible - is better because so the syntax does
not get 2nd-class status wrt 'class' .

> > 3) a 'with' statement for semantics like those of CL with- macros
> > (Michael Hudson has some ideas on this)
>
> I'd like to hear more about this.

I have attached his post on this to comp.lang.python.  [Google groups seem not
to have it, very strange]

> > more pythonic.
>
> Pythonic is as pythonic does.  Or, as was said in another thread, talk
> is cheap. :-)

Indeed <wink>, I could say the same about your up in the air description of
thunk semantics and implementation. At least my cheap talk try to minimize work
and disruption :-). [sorry I couldn't resist]

Seriously IMO 'with' is analogous to 'for' plus generators and iterators.
Generalized thunks are a very different beast, see below.

> > General syntax extensibility is another level of identity crisis for
> > the language <wink>.
>
> Agreed.  We're not going there.  But I admit I'm inspired by Ruby's
> blocks (poorly explained though their exact semantics are in the Ruby
> literature I've come across).

Ouch! Ruby-envy <wink>.

Much of what they offer is covered in python by 'for' plus iterators and
generators.  So they seem to me a somehow redundant addition.

Thunks really are a lot of work plus they would have confusing
variable-geometry scoping rules, would need rules/support for return/break,
would be easely abusable and cannot in the straightforward implemenantion case
perform speed-wise like usual inline suites. So I sense there should be a very
compelling case for them, which I don't see.

IMHO  (yes I'm repeating my self)

*) a generalizion of what 'class' does

[NEW-KEYW?] kind  name [ '(' expr,... ')' ]  [ maybe [] extended syntax ]:
  suite

*) a 'with' statement  (mesh conceptually well with the 'for' plus generators
and interators approach)

*)  generators and iterators plus 'for'

offer more or less the same functionality at a minor cost, with less conceptual
confusion and disruption, have minor implemention cost and avoid adding some
redundant functionaly (apart from 'class' generalization wrt to 'class').

regards.

------=_NextPart_000_1291_01C2C8DD.F168CCA0
Content-Type: message/rfc822;
	name="Re_ No macros in Python.nws"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Re_ No macros in Python.nws"

Newsgroups: comp.lang.python
From: Michael Hudson <mwh@python.net>
Subject: Re: No macros in Python
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Sender: unknown@pc150.maths.bris.ac.uk (Address not verified)
Organization: University of Bristol, UK
Lines: 61
Message-ID: <7h33coweo86.fsf@pc150.maths.bris.ac.uk>
References: <3DFCDAB5.5FBA7730@engcorp.com> <x78yyqiwle.fsf@guru.mired.org> <mailman.1040009301.27914.python-list@python.org> <x74r9eil56.fsf@guru.mired.org> <mailman.1040020314.12450.python-list@python.org> <x7isxthgxh.fsf@guru.mired.org> <mailman.1040072065.14055.python-list@python.org> <x7vg1tfwvo.fsf@guru.mired.org> <mailman.1040077707.23487.python-list@python.org> <x7isxtfq1n.fsf@guru.mired.org> <mailman.1040088443.5525.python-list@python.org>
Mime-Version: 1.0
Date: Tue, 17 Dec 2002 14:04:10 GMT
Path: news.bluewin.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!news.tu-darmstadt.de!newsfeed.freenet.de!213.253.16.105.MISMATCH!mephistopheles.news.clara.net!news.clara.net!server3.netnews.ja.net!bath.ac.uk!unknown
Xref: news.bluewin.ch comp.lang.python:213835

jepler@unpythonic.net writes:

> I'd rather just write 'with lock: suite'.

Right.  Here's a proposal:

with <exp>:
  <suite>

is equivalent to

_x = <exp>
_x.__enter__()
try:
  <suite>
finally:
  _x.__exit__()

Method names can be argued about.  I think they should be __special__
names because they are called by the interpreter, not the
programmer[*].

threading.RLock, for example, gets:

    __enter__ = acquire
    __exit__ = release

added to it's definition.

Everyone in the world writes something like:

class output_to(object):
    def __init__(self, f):
        self.file = f
    def __enter__(self):
        self.saved = sys.stdout
        sys.stdout = self.file
    def __exit__(self):
        sys.stdout = self.saved

so you can do

with output_to(open("/tmp/log", "w")):
    print "hello!"

'with' would have to become a keyword, so that implies a __future__
statement, even though it's kind of hard to see how you would use it
as a name.

I don't think this would be hard to implement.  I'll do a prototype
and a proper PEP after 2.3 is out.

Cheers,
M.
[*] this is a nice just-so story for why .next() is not called
    .__next__().

-- 
7. It is easier to write an incorrect program than understand a
   correct one.
  -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
------=_NextPart_000_1291_01C2C8DD.F168CCA0--