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
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
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
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
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
"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
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
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
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, 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:
> Also, the function's return value most certainly is a generator:
So it is; I stand corrected. :)
-Edward
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://
> 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
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
"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
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
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.
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:
>
> """
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:
[...]
> 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/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, 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
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/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
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/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
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, 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
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
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/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
31 matches
Mail list logo
