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--
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4