Fredrik Lundh wrote:
> And frankly, it would be *wonderful* if someone could come up with a
> new proposal that actually enabled Python programmers to do things they
> *cannot* do today, instead of just rehashing old "let's move the sofa
> over there" threads.
Hear, hear.
> I want to get *ne
Ivan Krstić wrote:
>> Let's do some *hard* stuff, for a change.
>
> I couldn't agree more. The fundamental problem that I see, though, is
> that Guido seems strongly opposed to adding any additional
> metaprogramming features to the language [0], and solving much of the
> hard stuff elegantly and
Fredrik Lundh wrote:
> Talin wrote:
>
>> Javascript, for example, doesn't need special syntactical sugar for
>> generator expressions:
>>
>> /* Return a list of the square of numbers.
>> ('map' appears courtesy of Mochikit.js) */
>>
>> result = map( [1, 2, 3, 4], function (a) {
>>
Fredrik Lundh wrote:
> I'm not convinced that they do -- you can emulate LINQ today with
> generators and iterator tools and good old for-in statements:
No, you can't. You can emulate a tiny subset of it, as you yourself
note. For people following from home: when you query a database with
LINQ, C
Talin wrote:
> The problem with providing use cases is that each one individually
> doesn't carry much weight. When I do Javascript/AJAX programming, I use
> anonymous functions quite a bit, as in the following example:
>
> do_command( 'get_synset_links', {}, function( response_data ) {
>
Ivan Krstić wrote:
>> I'm not convinced that they do -- you can emulate LINQ today with
>> generators and iterator tools and good old for-in statements:
>
> No, you can't.
my sentence didn't end at that colon, though.
> For people following from home: when you query a database with
> LINQ, C#
Fredrik Lundh wrote:
> for record in (select table: ):
> process record
This is precisely what I had in mind when I referred to "special-cased,
one-off solutions" two posts back.
> if you read my post again, you'll find that I said pretty much the same
> thing as you're saying, min
Ivan Krstić wrote:
> That's not what I'm saying. What I'm saying is "we absolutely must have
> full support for anonblocks to be able to do this *elegantly*", i.e.
> while avoiding special-cased solutions.
As I've tried to say several times in my other posts in this thread,
from a theoretical co
Fredrik Lundh wrote:
> Talin wrote:
>
>> The problem with providing use cases is that each one individually
>> doesn't carry much weight. When I do Javascript/AJAX programming, I use
>> anonymous functions quite a bit, as in the following example:
>>
>> do_command( 'get_synset_links', {}, fu
Talin wrote:
> Since I haven't actually proposed what it would look like in Python, I'm
> not sure that it makes sense to argue that it doesn't "look like"
> Python. That remains to be seen.
wow.
___
Python-3000 mailing list
[email protected]
several things:
[Josiah]
> I believe that Tomer just wanted to remind people that class decorators
> are slated for 2.6 and 3.0 if there was a PEP, and perhaps that he is
> encouraging someone to write one.
yeah, i just wanted to bring it up again. however, i do have some
spare time at the moment
tomer filiba wrote:
>> Did I mention I care about this feature and don't want
>> a raft of crazies screwing it up with their own vices?
>
> i don't get your point.
maybe your news server is dropping posts ?
___
Python-3000 mailing list
Python-3000@p
On 11/16/06, tomer filiba <[EMAIL PROTECTED]> wrote:
we should find some more/better use-cases than what i came
up with, and show why class decorators are the right solution,
and compare with function decorators.
A while ago I was trying to implement the Singleton or Borg design pattern
and
since it seems to be impossible to bring up new ideas in subthreads, I
though I'd give this one its own thread:
- has there been any discussions on making RuleDispatch-type mechanisms
available on a more fundamental level?
could someone perhaps come up with a list of real-life uses for PJE's
Hi,
> Well, if you find that easy to read and clear, I suspect you're more of
> a JavaScript programmer than a Python programmer. Here's how a more
> general form of the above would look in Python:
>
> response = (yield server.get_synset_links())
> format_expanded(li.content, response.
> The problem is not merely related to the number of lines of code. It is a
> readibility problem. Having the callback enclosed in a the function call
> which registers it makes the code more readable than defining the callback
> beforehand.
And, unless I'm missing something, much harder to unit t
Antoine wrote:
> > response = (yield server.get_synset_links())
> > format_expanded(li.content, response.related)
>
> This assumes there is an underlying event loop of some sort that accepts
> and is able to schedule generators.
no, it only assumes that whoever called your code is set u
On 11/16/06, Talin <[EMAIL PROTECTED]> wrote:
> From my point of view, both 'with' and generator expressions are
> limited, special-case solutions to a general problem - the desire to be
> able to use and manipulate unnamed blocks of code as first-class
> objects.
Other than your callback of a cu
[Talin:]
> > With multiple dispatch, its easy to spell out what will happen in each
> > possible permutation of arguments - and if you get an ambiguity, the
> > dispatcher will let you know about it, instead of simply choosing an
> > implementation arbitrarily.
[George Sakkis:]
> Interesting idea,
>> The problem is not merely related to the number of lines of code. It is
>> a
>> readibility problem. Having the callback enclosed in a the function call
>> which registers it makes the code more readable than defining the
>> callback
>> beforehand.
>
> And, unless I'm missing something, much ha
>> How is this one supposed to work ? What is "with async blah()" ?
>
> a magic thing that runs the code block behind the covers, of course.
> requires a
> non-released version of the from __future__ statement, at the time.
;-))
> unlike the
> following syntax:
>
> @server.get_synset_link()
> def
On Thu, 16 Nov 2006 18:24:38 +0100 (CET), Antoine <[EMAIL PROTECTED]> wrote:
> [snip]
>
>Ok, that's nearly perfect!
>Only "nearly" because:
>1. There are cases where you want the return value of the
>"get_synset_link". 2. You sometimes need more than one callback, and you
>cannot decorate two funct
On 11/15/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> George Sakkis wrote:
> > The ending sentences though are more convincing: "...but it's a part
> > of Python, and it's too late to make such fundamental changes now.
> > The functions have to remain to avoid massive code breakage". That
> > I c
At 12:44 PM 11/16/2006 +0100, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>since it seems to be impossible to bring up new ideas in subthreads, I
>though I'd give this one its own thread:
>
>- has there been any discussions on making RuleDispatch-type mechanisms
>available on a more fundamental le
On 11/16/06, Antoine <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> > Well, if you find that easy to read and clear, I suspect you're more of
> > a JavaScript programmer than a Python programmer. Here's how a more
> > general form of the above would look in Python:
> >
> > response = (yield server.ge
On 11/16/06, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> (Actually, even if you *can* say something nice, this conversation
> might be worth dropping. Just a thought.)
I agree. For me, the bottom line and the main argument for dropping
the proposal is "itertools is not as big as you think it is
"Antoine" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> def handle_response(record):
>> format_expanded(li.content, response.related)
>> server.get_synset_link(handle_response)
>
> As already mentioned, the problem with this idiom is that code that is
> execute
On 11/16/06, George Sakkis <[EMAIL PROTECTED]> wrote:
>
> I agree. For me, the bottom line and the main argument for dropping
> the proposal is "itertools is not as big as you think it is to
> introduce a builtin rich-iterator object".
<>
You should also consider that some people see that as a fal
Talin wrote:
> One unresolved issue is what exactly gets assigned to 'x' and 'y' at the
> time the class definition is evaluated.
Seems to me it ought to be some kind of descriptor.
It might be possible to do this reasonably without
any new syntax, e.g.
@cstruct
class MyStruct:
x = c
tomer filiba wrote:
> we should also note that it's possible to replace "__metaclass__"
> by a @metaclass decorator.
I don't think so. Your proposed technique for that seems to
involve creating an ordinary class first, then taking it
apart and recreating it using the specified metaclass.
That sme
George Sakkis wrote:
> And for two, not everyone feels comfortable with duck typing. People
> who consider (for better or for worse) isinstance() safer than
> hasattr()/getattr() would be accomodated too.
The trouble is that building things into the core to
"accommodate" these people ends up maki
Talin wrote:
> From my point of view, both 'with' and generator expressions are
> limited, special-case solutions to a general problem - the desire to be
> able to use and manipulate unnamed blocks of code as first-class
> objects.
I don't think it's as simple as that. Back when the with
state
If you want anonymous blocks, by all means use Ruby. Python has
first-class callables, Ruby has anonymous blocks. Pick your favorite,
but don't whine that neither language has both. It ain't gonna happen.
On 11/16/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Talin wrote:
>
> > From my point of view
On 11/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> If you want anonymous blocks, by all means use Ruby. Python has
> first-class callables, Ruby has anonymous blocks. Pick your favorite,
> but don't whine that neither language has both. It ain't gonna happen.
Should there be a new additio
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> tomer filiba wrote:
>
> > we should also note that it's possible to replace "__metaclass__"
> > by a @metaclass decorator.
>
> I don't think so. Your proposed technique for that seems to
> involve creating an ordinary class first, then taking it
> apart
35 matches
Mail list logo
