Brett Cannon schrieb:
>
>
> On 12/12/06, *Kay Schluehr* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Dear Python developers,
>
> while the JVM is opened to support dynamically typed languages [1] I
> wonder if the CPyVM could not
Dear Python developers,
while the JVM is opened to support dynamically typed languages [1] I
wonder if the CPyVM could not show more openness to statically typed
languages? Hereby I don't think that much about arbitrary languages for
the CPyVM but sublanguages like RPython which are "static eno
Guido van Rossum wrote:
> On 1/6/06, Kay Schluehr <[EMAIL PROTECTED]> wrote:
>
>>Then simply reject the PEP and the discussion can be stopped on
>>comp.lang.python too.
>
>
> Only in the most severe cases does it make sense to create a PEP
> specifically to b
Guido van Rossum wrote:
>>Yuk! This has been discussed again and again already. *Please* move
>>this discussion to comp.lang.python.
>
>
> Yes please. This won't change.
Then simply reject the PEP and the discussion can be stopped on
comp.lang.python too. Or why do you think it should be dis
Just one short comment of your ( well written ) rationale and PEP. Ruby
might be hyped at the moment but at least in the german labour market
and the biggest german freelancer mediation Ruby is quite inexistent.
Even when the nerdish blogosphere is setting different priorities SAP
and Intel mad
Nick Coghlan wrote:
> Greg Ewing wrote:
>
>>Guido van Rossum wrote:
>>
>>
>>>So let's call it the "Swiss Army Knife
>>>(...Not)" API design pattern.
>>
>>
>>Aha! Maybe this is the long-lost 20th principle from
>>the Zen of Python?
>
>
> It also sounds like one of the reasons why the ultimates i
Guido van Rossum wrote:
> I see two different ways to support the two most-called-for additional
> requirements: (a) an option to avoid the trailing newline, (b) an
> option to avoid the space between items.
>
> One way would be to give the print() call additional keyword
> arguments. For example
Oren Tirosh wrote:
> Python 3 will most probably make big changes in the internal
> implementation and the C API. Perhaps it will even be generated from
> PyPy.
Don't you think the current Python 3 "visions" becomes rather pointless
with the raise of PyPy and interpreter extensions that are deve
Terry Reedy wrote:
>>I would object to the removal of str.find().
>
>
> So, I wonder, what is your favored alternative?
>
> A. Status quo: ignore the opportunity to streamline the language.
I actually don't see much benefits from the user perspective. The
discourse about Python3000 has shrunk
Skip Montanaro wrote:
> >> As I see it, a lambda is an anonymous function. An anonymous function
> >> is a function without a name. We already have a syntax for a
> >> function... why not use it. ie:
> >>
> >> f = filter(def (a): return a > 1, [1,2,3])
>
> Kay> You mix e
Reinhold Birkenfeld wrote:
>>
>>lambda x,y: x+y*y
>>lambda x,y: y**2+x
>>
>> are essentialy the same functions with different implementations [1].
>
>
> Except that they are not. Think of __pow__, think of __add__ and __radd__.
You know the difference between the
Donovan Baarda wrote:
> I don't get what the problem is with mixing statement and expression
> semantics... from a practial point of view, statements just offer a
> superset of expression functionality.
>
> If there really is a serious practical reason why they must be limited
> to expressions
Donovan Baarda wrote:
> I must admit I ended up deleting most of the "alternative to lambda"
> threads after they flooded my in box. So it is with some dread I post
> this, contributing to it...
I must admit you are right. And I will stop defending my proposal
because it seems to create nothin
Josiah Carlson wrote:
> Kay Schluehr <[EMAIL PROTECTED]> wrote:
>
>
>> Maybe anonymus function closures should be pushed forward right now
not only syntactically? Personally I could live with lambda or several
>> of the alternative syntaxes listed on the wiki pa
Nick Coghlan wrote:
> Guido van Rossum wrote:
>
>>>Recommend accepting just the basic PEP which only targets simple,
>>>obvious cases. The discussed extensions are unattractive and should be
>>>skipped.
>>
>>
>>-1. The "unary colon" looks unPythonic to me.
>>
>
>
> Step 1 would be to require pa
15 matches
Mail list logo
