On 3/8/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
There's an incomplete wiki page about a possible factoring of types at
http://wiki.python.org/moin/AbstractBaseClasses.
The one thing that I have been unable to figure out (from that page, the
python-dev/python-3000 messages on the subject an
Thanks! This is a very interesting idea, I'd like to keep this around somehow.
I also see that you noticed a problem with text I/O in the current
design; there's no easy way to implement readline() efficiently. I
want readline() to be as efficient as possible -- "for line in "
should *scream*, lik
Actually, I like the version with t[0]-t[1] better. This is supposed
to be an exposition about groupby. Working out how it works, the
version with count() seems to take more effort.
But thanks for doing this! Is it done, apart from this nit? Then I'll
check it in.
--Guido
On 3/10/07, Tony Lownds
+1 for test.support too. -1 for putting code in test/__init__.py.
On 3/10/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 3/10/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> [snip]
> > And does anyone else find test.test_support an odd name; it isn't
> > testing anything! I really want to rename
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 11, 2007, at 7:50 AM, Benji York wrote:
> Greg Ewing wrote:
>> Barry Warsaw wrote:
>>> We already have an established, community accepted implementation
>>> of interfaces,
>> Really? Which one is that?
>
> I believe Barry was referring to zo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 12, 2007, at 1:02 PM, Thomas Wouters wrote:
> - Mixing interface-definition and implementation like that makes
> it hard for new programmers to pick up the difference. It will be
> harder to explain the difference between 'dict' and 'Mappi
This is all my fault.
Long ago, there was only __builtin__, and all was well; you had to
import it before using it.
Then I added __builtins__ as an internal hook for restricted execution
mode. The idea was that if __builtins__ was set to something
nonstandard you were automatically in restricted
On Mar 12, 2007, at 11:09 AM, Guido van Rossum wrote:
> Actually, I like the version with t[0]-t[1] better. This is supposed
> to be an exposition about groupby. Working out how it works, the
> version with count() seems to take more effort.
>
> But thanks for doing this! Is it done, apart from t
On 3/12/07, Tony Lownds <[EMAIL PROTECTED]> wrote:
>
> On Mar 12, 2007, at 11:09 AM, Guido van Rossum wrote:
>
> > Actually, I like the version with t[0]-t[1] better. This is supposed
> > to be an exposition about groupby. Working out how it works, the
> > version with count() seems to take more ef
On Mar 12, 2007, at 12:06 PM, Collin Winter wrote:
> I can take care of it. It'll be a good excuse to get back to 2to3
> after a few days spent in the depths of the patch tracker : )
>
Cool. Out of curiosity, what versions of Python should 2to3 need to
run? I know that 2to3/refactor.py needs 2.3
On 3/12/07, Tony Lownds <[EMAIL PROTECTED]> wrote:
>
> On Mar 12, 2007, at 12:06 PM, Collin Winter wrote:
>
> > I can take care of it. It'll be a good excuse to get back to 2to3
> > after a few days spent in the depths of the patch tracker : )
> >
>
> Cool. Out of curiosity, what versions of Python
At 02:14 PM 3/12/2007 -0400, Barry Warsaw wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>On Mar 11, 2007, at 7:50 AM, Benji York wrote:
>
> > Greg Ewing wrote:
> >> Barry Warsaw wrote:
> >>> We already have an established, community accepted implementation
> >>> of interfaces,
> >> Real
On 3/12/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 3/12/07, Tony Lownds <[EMAIL PROTECTED]> wrote:
> >
> > On Mar 12, 2007, at 12:06 PM, Collin Winter wrote:
> >
> > > I can take care of it. It'll be a good excuse to get back to 2to3
> > > after a few days spent in the depths of the patch tr
On 12 Mar 2007, at 17:56, Guido van Rossum wrote:
> Thanks! This is a very interesting idea, I'd like to keep this
> around somehow.
Thanks for the positive feedback - much appreciated.
> I also see that you noticed a problem with text I/O in the current
> design; there's no easy way to impleme
On 3/12/07, Mark Russell <[EMAIL PROTECTED]> wrote:
> On 12 Mar 2007, at 17:56, Guido van Rossum wrote:
> > Thanks! This is a very interesting idea, I'd like to keep this
> > around somehow.
>
> Thanks for the positive feedback - much appreciated.
>
> > I also see that you noticed a problem with te
On 12 Mar 2007, at 20:18, Guido van Rossum wrote:
> I would love for you to start working on this. Let me know off-line if
> you need more guidance (but CC Daniel and Mike so they know what's
> going on).
Great! I'll start off by working up a patch that implements any easy
missing stuff from ht
On 3/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/12/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > On 3/12/07, Tony Lownds <[EMAIL PROTECTED]> wrote:
> > > Cool. Out of curiosity, what versions of Python should 2to3 need to
> > > run? I know that 2to3/refactor.py needs 2.3 < Python
On 3/12/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
> On 3/8/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > There's an incomplete wiki page about a possible factoring of types at
> > http://wiki.python.org/moin/AbstractBaseClasses.
>
> The one thing that I have been unable to figure out (from
Collin Winter schrieb:
>> > > Also, since I believe sys.exc_info() is staying, fix_sysexcinfo
>> > > should change...
>> >
>> > Right. It's already on my todo list.
>>
>> I must've missed that. What happened?
>
> I thought the decision had been made (or at least, the consensus
> reached) that sys
On 3/12/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Has the final decision now been made whether the traceback should be
> stuck on the exception or not?
If it has, I wasn't there. :-(
I'm still hoping we can get agreement that storing the traceback on
the exception object is the way to go. Onl
Ka-Ping Yee wrote:
> We have "import as", though. If you want to import the default
> builtins without using them as the builtins, you can say
>
> import __builtin__ as default_builtin
Seems to me it would be better to rename the module
to a non-double-underscore name. There's really nothin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 12, 2007, at 6:12 PM, Greg Ewing wrote:
> Seems to me it would be better to rename the module
> to a non-double-underscore name. There's really nothing
> magical about the module itself, only the name used
> by global variable lookups. So just
On 3/12/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Ka-Ping Yee wrote:
>
> > We have "import as", though. If you want to import the default
> > builtins without using them as the builtins, you can say
> >
> > import __builtin__ as default_builtin
>
> Seems to me it would be better to rename th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 12, 2007, at 3:33 PM, Phillip J. Eby wrote:
> For maybe 80-90% of the purposes that I originally created
> PyProtocols for, I have found that "simplegeneric" ( http://
> cheeseshop.python.org/simplegeneric/ ) is more than adequate -- and
>
Guido van Rossum wrote:
> I'm still hoping we can get agreement that storing the traceback on
> the exception object is the way to go. Only a handful of modules using
> pre-baked exception objects would have to be fixed, and likely those
> were doing it out of a misunderstanding of the performance
At 07:00 PM 3/12/2007 -0400, Barry Warsaw wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>On Mar 12, 2007, at 3:33 PM, Phillip J. Eby wrote:
>
> > For maybe 80-90% of the purposes that I originally created
> > PyProtocols for, I have found that "simplegeneric" ( http://
> > cheeseshop.pyt
I will go ahead and add it this to PEP 3108.
-Brett
On 3/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> +1 for test.support too. -1 for putting code in test/__init__.py.
>
> On 3/10/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > On 3/10/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > [sni
On 3/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/12/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Ka-Ping Yee wrote:
> >
> > > We have "import as", though. If you want to import the default
> > > builtins without using them as the builtins, you can say
> > >
> > > import __builti
On 3/9/07, Talin <[EMAIL PROTECTED]> wrote:
> I had a conversation with Guido last night at the Python user's group
> meeting, and we hashed out some of the details of how metaclasses should
> work. I've gone ahead and written up a PEP, which I present for your review.
Executive summary: I'm defen
On 3/12/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I'm still hoping we can get agreement that storing the traceback on
> > the exception object is the way to go. Only a handful of modules using
> > pre-baked exception objects would have to be fixed, and likely those
> >
On 3/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/12/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
> > > I'm still hoping we can get agreement that storing the traceback on
> > > the exception object is the way to go. Only a handful of modules using
> > > pre-ba
Phillip,
I think there is a certain schizophrenia in Python between the older
original procedural/functional orientation (itself somewhat split),
and the newer-fangled (for Python) object style, between len(obj) and
obj.len(). That's what makes it hard to evaluate the pros and cons
between adding
On 3/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
[snip stuff I agree with]
> On 3/9/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Do the keywords have to follow the metaclass keyword, or is order
> > irrelevant? While order makes sense, it would be a new precedent for
> > keyword argument
At 05:30 PM 3/12/2007 -0700, Guido van Rossum wrote:
>I don't know about sealed, but using class attributes topassing
>parameter (other than the namespace itself) to the metaclass seems a
>pretty lousy mechanism, and keyword arguments in the classdef are a
>much cleaner solution for this need. For
At 06:06 PM 3/12/2007 -0700, Bill Janssen wrote:
>Phillip,
>
>I think there is a certain schizophrenia in Python between the older
>original procedural/functional orientation (itself somewhat split),
>and the newer-fangled (for Python) object style, between len(obj) and
>obj.len().
Where you see s
On 3/12/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 3/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [snip stuff I agree with]
> > On 3/9/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > > Do the keywords have to follow the metaclass keyword, or is order
> > > irrelevant? While order ma
Phillip J. Eby wrote:
> I posted here several months ago a short "Interface" class that
> used generic functions for its base
How could Python use generic functions to accomplish what the proposed
ABCs aim to? By first implementing interfaces? Perhaps by implementing
is_file() with a generic
Eric Smith and I have a reasonable first-cut of a C implementation for
Talin's PEP3101 (it runs as an extension module and has been tested on
Python 2.3, 2.4, and 3.0) along with some test cases. It's sort of
experimental, in that it mostly implements the PEP, but also
implements a few possible e
On 3/12/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 02:14 PM 3/12/2007 -0400, Barry Warsaw wrote:
> >The question then becomes whether we really want to invent a third
> >way of doing interfaces in Python, or whether our time is better
> >spent selecting and promoting one of the existing, tr
On 3/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/9/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Do the keywords have to follow the metaclass keyword, or is order
> > irrelevant? While order makes sense, it would be a new precedent for
> > keyword arguments to have an important ord
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
FWIW, I agree that class definition meta-information should go in the
header rather that the body. To me, metaclass=mymeta at the top is much
prettier than __metaclass__ = mymeta in the body. It will also make it
Unsure why you present this as a question; I'm not sure anyone has
thought much about it yet. I wonder if the call shouldn't be made like
this:
__prepare__(name, bases, **kwargs)
so that if you only expect certain specific keyword args you can
define it like this:
def __prepare__(name, base, met
At 10:03 PM 3/12/2007 -0400, Benji York wrote:
>Phillip J. Eby wrote:
> > I posted here several months ago a short "Interface" class that
> > used generic functions for its base
>
>How could Python use generic functions to accomplish what the proposed
>ABCs aim to?
Which specific aim do you have i
On 3/12/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> the signature of the method called will be::
> __prepare__(name, args, kwargs)
> not
> __prepare__(name, *args, **kwargs)
> right?
On 3/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'm not sure anyone has thought much about it
At 08:48 PM 3/12/2007 -0600, Steven Bethard wrote:
>On 3/12/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > For maybe 80-90% of the purposes that I originally created PyProtocols for,
> > I have found that "simplegeneric" (
> > http://cheeseshop.python.org/simplegeneric/ ) is more than adequate -
At 09:32 PM 3/12/2007 -0600, Steven Bethard wrote:
>On 3/12/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > the signature of the method called will be::
> > __prepare__(name, args, kwargs)
> > not
> > __prepare__(name, *args, **kwargs)
> > right?
>
>On 3/12/07, Guido van Rossum <[EMAIL PR
On 3/12/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 08:48 PM 3/12/2007 -0600, Steven Bethard wrote:
> >On 3/12/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > Of course, generic functions require you to say 'foo(bar)' instead of
> > > 'bar.foo()' (and IIUC, that's the big sticking point
On 3/12/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:32 PM 3/12/2007 -0600, Steven Bethard wrote:
> >On 3/12/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > > the signature of the method called will be::
> > > __prepare__(name, args, kwargs)
> > > not
> > > __prepare__(name, *arg
On 3/12/07, Patrick Maupin <[EMAIL PROTECTED]> wrote:
Eric Smith and I have a reasonable first-cut of a C implementation for
Talin's PEP3101 (it runs as an extension module and has been tested on
Python 2.3, 2.4, and 3.0) along with some test cases. It's sort of
experimental, in that it mostly
49 matches
Mail list logo
