"Steven Bethard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The make statement was mostly syntactic sugar for::
>
>class :
>__metaclass__ =
>
>
> So was technically unnecessary from the beginning. ;) Here's the one
> post where he presented a few reasons
Tim Roberts wrote:
> Steven Bethard <[EMAIL PROTECTED]> wrote:
>
>> Steven Bethard wrote:
>>> I've updated PEP 359 with a bunch of the recent suggestions. ...
>> Guido has pronounced on this PEP:
>>http://mail.python.org/pipermail/python-3000/2006-April/000936.html
>> Consider it dead. =)
>
>
Steven Bethard <[EMAIL PROTECTED]> wrote:
>Steven Bethard wrote:
>> I've updated PEP 359 with a bunch of the recent suggestions. ...
>
>Guido has pronounced on this PEP:
>http://mail.python.org/pipermail/python-3000/2006-April/000936.html
>Consider it dead. =)
I tried to follow the thread bac
Steven Bethard wrote:
> Guido has pronounced on this PEP:
> http://mail.python.org/pipermail/python-3000/2006-April/000936.h
> tml
> Consider it dead. =)
This is the most frustrating pronouncement ever.
--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may
Steven Bethard wrote:
> Guido has pronounced on this PEP:
> http://mail.python.org/pipermail/python-3000/2006-April/000936.html
> Consider it dead. =)
Well, Guido is known for having changed his mind before (the ternary
operator,
lambda functions, try..except..finally, etc) so this is not nece
Steven Bethard wrote:
(snip)
> Guido has pronounced on this PEP:
>http://mail.python.org/pipermail/python-3000/2006-April/000936.html
> Consider it dead. =)
:(
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@'
Steven Bethard wrote:
> I've updated PEP 359 with a bunch of the recent suggestions. The
> patch is available at:
> http://bugs.python.org/1472459
> and I've pasted the full text below.
>
> I've tried to be more explicit about the goals -- the make statement
> is mostly syntactic sugar for::
Carl> class some_attribute:
Carl> __metaclass__ = PropertyMaker
Carl> def get(self):
Carl> whatever
Carl> def set(self,value):
Carl> whatever
Carl> But the thing is, if I did that, I'd be lying bastard With
Carl> the make statement,
I've updated PEP 359 with a bunch of the recent suggestions. The
patch is available at:
http://bugs.python.org/1472459
and I've pasted the full text below.
I've tried to be more explicit about the goals -- the make statement
is mostly syntactic sugar for::
class :
__metaclass__
Carl Banks wrote:
> Tim Hochberg wrote:
>
>>Carl Banks wrote:
>>
>>>Mike Orr wrote:
>>>
>>>
>I think this PEP is going off the rails. It's primary virtue was that it
was a simpler, clearer way to write:
class Foo(args):
__metaclass__ = some_metaclass
Tim Hochberg wrote:
> Carl Banks wrote:
> > Mike Orr wrote:
> >
> >>>I think this PEP is going off the rails. It's primary virtue was that it
> >>
> >>was a simpler, clearer way to write:
> >>
> >> class Foo(args):
> >>__metaclass__ = some_metaclass
> >>#...
> >>
> >>And it doe
Carl Banks wrote:
> Mike Orr wrote:
>
>>>I think this PEP is going off the rails. It's primary virtue was that it
>>
>>was a simpler, clearer way to write:
>>
>> class Foo(args):
>>__metaclass__ = some_metaclass
>>#...
>>
>>And it doesn't even do that. What's wrong with "class
Mike Orr wrote:
> > I think this PEP is going off the rails. It's primary virtue was that it
> was a simpler, clearer way to write:
>
> class Foo(args):
> __metaclass__ = some_metaclass
> #...
>
> And it doesn't even do that. What's wrong with "class Foo:
> __metaclass__ = bla
> I think this PEP is going off the rails. It's primary virtue was that it
was a simpler, clearer way to write:
class Foo(args):
__metaclass__ = some_metaclass
#...
And it doesn't even do that. What's wrong with "class Foo:
__metaclass__ = blah"? Two lines of code, and the
Tim Hochberg wrote:
> Tim Hochberg wrote:
>> I don't think that's correct. I think that with a suitably designed
>> HtmlDocument object, the following should be possible:
>>
>> with HtmlDocument("Title") as doc:
>> with doc.element("body"):
>>doc.text("before first h1")
>>with
?
i really liked it
-tomer
--
http://mail.python.org/mailman/listinfo/python-list
Steven Bethard wrote:
> Rob Williscroft wrote:
>> I don't know wether this has been suggested or not, but what about def:
>>
>> def namespace ns:
>> x = 1
>>
>> def type blah(object):
>> pass
>>
>> def property x:
>> def get():
>> return ns.x
>
> I think that's probably a bad idea
Tim Hochberg wrote:
> Steven Bethard wrote:
>
>> Steven Bethard wrote:
>>
>>> Tim Hochberg wrote:
>>>
Steven Bethard wrote:
> Steven Bethard wrote:
>
>> Duncan Booth wrote:
>>
>>> make Element html:
>>> make Element body:
>>> make Element p:
>>>
Tim Hochberg ha scritto:
> I think this PEP is going off the rails. It's primary virtue was that it
> was a simpler, clearer way to write:
>
> class Foo(args):
> __metaclass__ = some_metaclass
> #...
>
> Once it starts calling secret magic methods behind the scenes it's
> losi
Steven Bethard wrote:
> Steven Bethard wrote:
>
>>Tim Hochberg wrote:
>>
>>>Steven Bethard wrote:
>>>
Steven Bethard wrote:
>Duncan Booth wrote:
>
>>make Element html:
>> make Element body:
>> make Element p:
>> text('But this ')
>>
Steven Bethard wrote:
> Tim Hochberg wrote:
>> Steven Bethard wrote:
>>> Steven Bethard wrote:
Duncan Booth wrote:
> make Element html:
>make Element body:
>make Element p:
>text('But this ')
>make Element strong:
> te
Tim Hochberg wrote:
> Steven Bethard wrote:
>> Steven Bethard wrote:
>>> Duncan Booth wrote:
make Element html:
make Element body:
make Element p:
text('But this ')
make Element strong:
text('could')
text(
Steven Bethard wrote:
> Steven Bethard wrote:
>
>>Duncan Booth wrote:
>>
>>>Steven Bethard wrote:
>>>
>>>
Should users of the make statement be able to determine in which dict
object the code is executed? The make statement could look for a
``__make_dict__`` attribute and call it to a
Rob Williscroft wrote:
> Steven Bethard wrote in news:[EMAIL PROTECTED]
> in comp.lang.python:
>
>> Open Issues
>> ===
>>
>> Does the ``make`` keyword break too much code? Originally, the make
>> statement used the keyword ``create`` (a suggestion due to Nick
>> Coghlan). However, inves
Felipe Almeida Lessa wrote:
> Em Sex, 2006-04-14 às 09:31 -0600, Steven Bethard escreveu:
>> [1] Here's the code I used to test it.
>>
>> >>> def make(callable, name, args, block_string):
>> ... try:
>> ... make_dict = callable.__make_dict__
>> ... except AttributeError:
>> ...
Steven Bethard wrote in news:[EMAIL PROTECTED]
in comp.lang.python:
> Open Issues
> ===
>
> Does the ``make`` keyword break too much code? Originally, the make
> statement used the keyword ``create`` (a suggestion due to Nick
> Coghlan). However, investigations into the standard librar
Felipe Almeida Lessa wrote:
> Em Sex, 2006-04-14 às 09:31 -0600, Steven Bethard escreveu:
>> [1] Here's the code I used to test it.
>>
>> >>> def make(callable, name, args, block_string):
>> ... try:
>> ... make_dict = callable.__make_dict__
>> ... except AttributeError:
>>
Em Sex, 2006-04-14 às 09:31 -0600, Steven Bethard escreveu:
> [1] Here's the code I used to test it.
>
> >>> def make(callable, name, args, block_string):
> ... try:
> ... make_dict = callable.__make_dict__
> ... except AttributeError:
> ... make_dict = dict
> ... bloc
Steven Bethard wrote:
> Duncan Booth wrote:
>> Steven Bethard wrote:
>>
>>> Should users of the make statement be able to determine in which dict
>>> object the code is executed? The make statement could look for a
>>> ``__make_dict__`` attribute and call it to allow things like::
>>>
>>> mak
Duncan Booth wrote:
> Steven Bethard wrote:
>
>> Should users of the make statement be able to determine in which dict
>> object the code is executed? The make statement could look for a
>> ``__make_dict__`` attribute and call it to allow things like::
>>
>> make Element html:
>> ma
Steven Bethard wrote:
> Should users of the make statement be able to determine in which dict
> object the code is executed? The make statement could look for a
> ``__make_dict__`` attribute and call it to allow things like::
>
> make Element html:
> make Element body:
>
Nicolas Fleury wrote:
> Steven Bethard wrote:
>> Ok, I finally have a PEP number. Here's the most updated version of
>> the "make" statement PEP. I'll be posting it shortly to python-dev.
>>
>> Thanks again for the previous discussion and suggestions!
>
> I find it very interesting.
>
> My onl
Nicolas Fleury wrote:
> I have no idea of the
> implementation implications, but it would be nice to have the
> capability to override the namespace type to use something else
> than dict, so that it can be filled with symbols one statement at a
> time.
I agree. I have sometimes wante
Em Qui, 2006-04-13 às 23:17 -0400, Nicolas Fleury escreveu:
> The callable could have something like a __namespacetype__ that could be
> use instead of dict. That type would have to implement __setitem__.
Or the namespace variable could be a list of tuples.
--
Felipe.
--
http://mail.python.o
Steven Bethard wrote:
> Ok, I finally have a PEP number. Here's the most updated version of the
> "make" statement PEP. I'll be posting it shortly to python-dev.
>
> Thanks again for the previous discussion and suggestions!
I find it very interesting.
My only complaint is that it is limited t
On Thu, 13 Apr 2006 13:39:14 -0700, gangesmaster wrote:
> "make type" is uber leet
So you're against it then?
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
"make type" is uber leet
--
http://mail.python.org/mailman/listinfo/python-list
Ok, I finally have a PEP number. Here's the most updated version of the
"make" statement PEP. I'll be posting it shortly to python-dev.
Thanks again for the previous discussion and suggestions!
PEP: 359
Title: The "make" Statement
Version: $Revision: 45366 $
Last-Modified: $Date: 2006-04-13 0
38 matches
Mail list logo
