On 5/18/06, Kay Schluehr <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
>
> >> Another question: is there any intention to
> >> support ML style quards for pattern matching on algebraic /recursive
> >> types?
> >
> > Can you rephrase that without references to ML or quads?
>
> No, but the b
Guido van Rossum schrieb:
>> Another question: is there any intention to
>> support ML style quards for pattern matching on algebraic /recursive
>> types?
>
>
> Can you rephrase that without references to ML or quads?
No, but the basic idea is easily explained using ML syntax and semantics.
ML
On 5/13/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
>
> > Py3k's function overloading should fix this:
>
> People are starting to talk about "Py3k's function overloading"
> as though it were a done deal. Has anything actually been
> decided about it yet.
To the contrary. My own
On 5/18/06, Kay Schluehr <[EMAIL PROTECTED]> wrote:
> I have a question to the audience. How do you represent higher order
> functions using this syntax?
I think Collin and I both (independently) proposed the pragmatic
Function(, , ..., returns=) for this.
We also discussed forward references; my
Collin Winter schrieb:
>In working on notes for the type annotations PEP, I've hit some
>ambiguous/unresolved issues in the BDFL annotation syntax (drawing
>primarily from [1] and other blog posts):
>
>As a quick recap, the syntax looks something like this:
>
>"""def foo(a: int, b: float, c: int =
On 5/18/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 5/18/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > > I'd like to see the typechecking machinery ignore differences like
> > > "real type" v "pseudo type", looking only at whether
On 5/17/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Michael Chermside" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > However, this is more of a practice than a prohibition... it IS
> > possible to modify existing classes in Python.
>
> If the class is defined/written in Pyth
On 5/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/18/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > I'd like to see the typechecking machinery ignore differences like
> > "real type" v "pseudo type", looking only at whether, zB, a
> > __parameterize__ method is present. Using __param
Which slide in Norvig's presentation are you referring to?
Why would you have to pass token.type to convert()? I'd think that the
simplest API would be
convert(token, target).
What am I missing?
--Guido
On 5/18/06, Thomas Dunham <[EMAIL PROTECTED]> wrote:
> Talk on overloaded functions seems
On 5/18/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "tomer filiba" <[EMAIL PROTECTED]> wrote:
> > On 5/17/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > > And I brought this up with Guido once and he was not enthusiastic
> > > about it. Basically, keep exceptions simple. They are important
On 5/11/06, Boris Borcic <[EMAIL PROTECTED]> wrote:
> I am late on this subthread, but FWIW and FYI with Python 2.4.2 and Idle 1.1.2
> on WinXP I can use non-ascii identifiers transparently both in modules and at
> the prompt, for instance
>
> >>> grüzi = râle = niño = ça = True
> >>> grüzi
> Tru
On 5/18/06, Collin Winter <[EMAIL PROTECTED]> wrote:
[...]
> BDFL syntax has generally used "Sometype[parameterizer]" to indicate
> type parameterization. With this Generator example, you've gone ahead
> and implicitly addressed several of the more general questions I had
> about parameterization (
On 5/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/18/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > In looking through all of Guido's blog posts on the subject -- and all
> > the comments on them -- I haven't seen anyone consider the case of
> > generators. Assuming that "->" makes a
On 5/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/18/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > In looking through all of Guido's blog posts on the subject -- and all
> > the comments on them -- I haven't seen anyone consider the case of
> > generators. Assuming that "->" makes a
On 5/18/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> In working on notes for the type annotations PEP, I've hit some
> ambiguous/unresolved issues in the BDFL annotation syntax (drawing
> primarily from [1] and other blog posts):
>
> As a quick recap, the syntax looks something like this:
>
> """
Thomas Heller <[EMAIL PROTECTED]> writes:
>> >>> grüzi = râle = niño = ça = True
>> >>> grüzi
>> True
>>
>> I thought it was a provided feature, but scanning the subthread gave the
>> contrary impression. Should we expect disappearance of the property ?
>
> This looks like an IDLE bug to me.
Boris Borcic wrote:
> Martin v. Löwis wrote:
> > Guido van Rossum wrote:
> >> I want good Unicode support for string literals and comments.
> >> Everything else in the language ought to be ASCII.
> >
> > Does that include restricting identifiers to ASCII as well?
>
> I am late on this subthre
"tomer filiba" <[EMAIL PROTECTED]> wrote:
> On 5/17/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > And I brought this up with Guido once and he was not enthusiastic
> > about it. Basically, keep exceptions simple. They are important
> > and basic enough to keep it simple. If you want fancier s
On 5/18/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> Positional support is deprecated; there will only be support for a> single argument. Read> PEP 352 to see how BaseException will end up in Python 3000.i don't see how BaseException addresses issues like accessing
attributes rather than positiona
> Positional support is deprecated; there will only be support for a
> single argument. Read
> PEP 352 to see how BaseException will end up in Python 3000.
i don't see how BaseException addresses issues like accessing
attributes rather than positional args, or introducing something equivalent
to A
Collin Winter wrote:
> Also, the function's return value most certainly is a generator:
So it is; I stand corrected. :)
-Edward
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://
On 5/18/06, Edward Loper <[EMAIL PROTECTED]> wrote:
> Collin Winter wrote:
> > So, reasoning by analogy would point to something like
> > Generator(is_sent=int, yields=int).
>
> You'd probably want this to be Iterator(...) instead of Generator(...),
> since the *return value* is an iterator. (It's
Collin Winter wrote:
> So, reasoning by analogy would point to something like
> Generator(is_sent=int, yields=int).
You'd probably want this to be Iterator(...) instead of Generator(...),
since the *return value* is an iterator. (It's the function itself
that's a generator function, not its re
On 5/18/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 5/18/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > In looking through all of Guido's blog posts on the subject -- and all
> > the comments on them -- I haven't seen anyone consider the case of
> > generators. Assuming that "->" makes asserti
On 5/18/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> In looking through all of Guido's blog posts on the subject -- and all
> the comments on them -- I haven't seen anyone consider the case of
> generators. Assuming that "->" makes assertions only about the
> function's return type, if I were to
"Collin Winter" <[EMAIL PROTECTED]> writes:
> Of course, "->" could be DWIMmy, in the sense that it knows whether
> it's being used in a function or generator context.
This would be a bad idea. A function returning a generator of ints is
very different from a function returning an int.
And a fun
In working on notes for the type annotations PEP, I've hit some
ambiguous/unresolved issues in the BDFL annotation syntax (drawing
primarily from [1] and other blog posts):
As a quick recap, the syntax looks something like this:
"""def foo(a: int, b: float, c: int = 5) -> list[int]"""
In looking
Talk on overloaded functions seems a bit sparse recently, and as I rather like
the idea I wondered if another usecase would be helpful. I reworked
this from an example published 10 years ago by someone who a couple of
you guys might see at lunchtime.
Say we want to read a text document in RTF and
Martin v. Löwis wrote:
> Guido van Rossum wrote:
>> I want good Unicode support for string literals and comments.
>> Everything else in the language ought to be ASCII.
>
> Does that include restricting identifiers to ASCII as well?
I am late on this subthread, but FWIW and FYI with Python 2.4
Kay Schluehr <[EMAIL PROTECTED]> wrote:
> Terry Reedy schrieb:
> >>Unfortunately, for implementation reasons you can't modify most
> >>built-in (and some user-defined) classes in this fashion:
> >>
> >Being able to add Python-coded functions as methods of compiled C-coded
> >types/classes (bu
Terry Reedy schrieb:
>>Unfortunately, for implementation reasons you can't modify most
>>built-in (and some user-defined) classes in this fashion:
>>
>>
>
>Being able to add Python-coded functions as methods of compiled C-coded
>types/classes (builting or otherwise) would require some wrappin
31 matches
Mail list logo
