On 4/23/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 4/23/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> > Replace list() with the BList.
>
> I looked over this patch and have various questions/comments. In
> rough priority order:
Thanks for taking the time to look over the code. I greatl
At 11:17 PM 4/23/2007 -0700, Talin wrote:
>I'm not sure what Phillip is talking about here - C++ does not allow you
>to instantiate a class that has non-overridden pure virtual methods, and
>no pure virtual method can have a body. You cannot provide an
>implementation for a pure virtual function
At 09:25 PM 4/23/2007 -0700, Guido van Rossum wrote:
>On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 04:49 PM 4/23/2007 -0700, Guido van Rossum wrote:
> > >>I suppose there is some value in requiring people to override @abstract
> > >>methods to make a subclass instantiable, versus me
I must have miscopied then because it worked perfectly here. Yes, I
meant to have the _superdesc defined inside the metaclass __init__,
but thought I could pull it out to make it cleaner. I forgot it
actually had to be there! Here is the metaclass that works.
class autosuper(type):
def __i
Dear Guido, Talin, and other Python Experts,
I would like to register my strong support/encouragement for some type of
abstract base class (ABC) mechanism in python. While I think dynamism,
reflection, duck-typing, unit tests, etc. are wonderful, I often come across
situations where ABCs are very
On 4/23/07, Talin <[EMAIL PROTECTED]> wrote:
> I think I am in (weak) agreement with Phillip here. In every language
> that I am familiar with, the adjective "abstract" when applied to a
> method implies two things: (1) that the method does not have a body, and
> (2) the method must be implemented
On 4/24/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'm not afraid of breaking new ground. Since the fact of the matter is
> that we can't prevent abstract methods from having a body (that would
> require syntactic support for abstract methods which is out of scope
> here) we might as well ma
On 4/24/07, Talin <[EMAIL PROTECTED]> wrote:
> In what is considered "good style" for such languages, protected helper
> methods ought to have different names than the methods which invoke
> them. So for example, you might have the following:
> /// Abstract base class for hashable object
>
On 4/24/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> I must have miscopied then because it worked perfectly here. Yes, I
> meant to have the _superdesc defined inside the metaclass __init__,
> but thought I could pull it out to make it cleaner. I forgot it
> actually had to be there! Here is th
On 4/24/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
[SNIP]
> Is there a document that describes the right times to use int vs
> size_t vs Py_ssize_t?
Try PEP 353: http://www.python.org/dev/peps/pep-0353/
-Brett
___
Python-3000 mailing list
Python-30
On 4/24/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Right - but as I understand it, Java and C# allow a class to be abstract
> without having *any* of its methods being abstract. I wasn't proposing
> that a redudnant class level @abstract be required; just noting that it
> seems useful to decl
On 4/24/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:25 PM 4/23/2007 -0700, Guido van Rossum wrote:
> >I don't see the point of having an abstract class without abstract methods.
Phillip is used to writing classes with (unbased) mutally recursive
functions. Concrete example:
class
On 4/24/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > class autosuper(type):
> I still get the same error.
No doubt it is fiddly, but he did remind me to look at some of the
older recipes.
In the stdlib test\test_descr.py (inside function metaclass), there is
an autosuper class that comes p
On 4/24/07, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
>
>
> But Python doesn't have protected, and isn't about to get it.
>
We use methods names with one underscore as a convention for protected
methods and I think we learned that from somebody else:
class Eggs:
def thePublicMethod(self)
Let's agree to disagree. I am getting tired from going around in
circles about this.
On 4/24/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:50 AM 4/24/2007 -0700, Guido van Rossum wrote:
> >On 4/24/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >>Mine (courtesy of other languages) is, "a m
At 10:50 AM 4/24/2007 -0700, Guido van Rossum wrote:
>On 4/24/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>Mine (courtesy of other languages) is, "a method without an
>>implementation". Yours appears to be "a method that must be
>>overridden".
>
>That's a very subtle distinction, since the *goa
At 12:00 PM 4/24/2007 -0700, Guido van Rossum wrote:
>Let's agree to disagree. I am getting tired from going around in
>circles about this.
Does that mean you're -1 on renaming @abstractmethod to @required or
@requiredmethod, or did you not see that proposal?
Other than that question, I'm done o
Just to chime in...
My preference would be to have "abstract" just mark classes that
define an API, that define the "abstraction" of that particular
interface. Not carry over meanings from Java and C++ that "abstract"
somehow always means "partial" or "incomplete". I'd envision having
"abstract"
On 4/24/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> Just to chime in...
>
> My preference would be to have "abstract" just mark classes that
> define an API, that define the "abstraction" of that particular
> interface. Not carry over meanings from Java and C++ that "abstract"
> somehow always m
> > Maybe "abstraction" is a better keyword than "abstract".
> >
> > Maybe it makes sense to have "abstraction" classes, and an
> > "@ignorethismethod" decorator to mark methods that are *not* part of
> > the abstraction, instead of "@abstractmethod" decorators to mark the
> > methods that *are* pa
Daniel Stutzbach wrote:
> I'm not really sure what variance bars would reveal.
> I can testify that when I rerun the experiments with the same
> code, the results would look *very* similar.
If you're running real-world timing tests, then there
will be some variance in the results, so you need t
I've been off sick from work for over a week - I've been following this
discussion, but now I think I've got something which matches all the
criteria we've been discussing, so I've changed my subscription address
temporarily to my home one.
It involves bytecode hacking for now, as well as a me
From: "Tim Delaney" <[EMAIL PROTECTED]>
> I've been off sick from work for over a week - I've been following this
> discussion, but now I think I've got something which matches all the
> criteria we've been discussing, so I've changed my subscription address
> temporarily to my home one.
>
> It in
Do we really need to have B&D-ish enforcement of abstract
method implementation? It doesn't seem pythonic to me.
I might want to leave some methods of an ABC unimplemented
because I'm not intending to use them. I'd be annoyed if
I were prevented from doing that because of some theoretical
notion th
On 4/24/07, guido.van.rossum <[EMAIL PROTECTED]> wrote:
> +We define a new built-in decorator, [EMAIL PROTECTED]
[snip]
> +**Implementation:** The [EMAIL PROTECTED] decorator sets the
> +function attribute ``__isabstractmethod__`` to the value ``True``.
> +The ``type.__new__`` method computes the t
On 4/24/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/24/07, guido.van.rossum <[EMAIL PROTECTED]> wrote:
> > +We define a new built-in decorator, [EMAIL PROTECTED]
> [snip]
> > +**Implementation:** The [EMAIL PROTECTED] decorator sets the
> > +function attribute ``__isabstractmethod__`` to t
On 4/24/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> Or could __abstractmethods__ be created dynamically? Which would be
> used less, __abstractmethods__ or setting class attributes, that it
> would be OK to be a bit slower?
I considered that, but __abstractmethods__ gets checked at every clas
Guido van Rossum wrote:
> So if we had this feature I'd make
> BaseException, Exception, StandardError, EnvironmentError and Warning
> abstract (or at least the first 2-3 of those).
I'm not sure I follow the reasoning here.
I've just written some code which raises EnvironmentError
in numerous pla
On 4/24/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/24/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > Or could __abstractmethods__ be created dynamically? Which would be
> > used less, __abstractmethods__ or setting class attributes, that it
> > would be OK to be a bit slower?
>
> I co
On 4/24/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'm not sure what the point would be of supporting dynamically
> modifying ABCs -- it looks like you're just exploring the corners of
> the semantics rather than providing actual use cases.
Yep, I'm just checking the corner case semantics.
On 4/24/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/24/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > I must have miscopied then because it worked perfectly here. Yes, I
> > meant to have the _superdesc defined inside the metaclass __init__,
> > but thought I could pull it out to make
On 4/24/07, Emin.shopper Martinian.shopper <[EMAIL PROTECTED]> wrote:
>
> Below are links to the ABC implementation based on meta-classes and
> decorators which I have been using for quite a while.
Emin,
You can get similar functionality by using tools such as pychecker.
PyLint and pyflakes may a
[Daniel Stutzbach]
> As a pet project, I've written a container type that looks, acts, and
> quacks like a Python list(), but has better asymptotic performance.
> Specifically, O(log n) time for inserts and deletes in the middle of
> the list. I'd like to offer it for inclusion in the collections
33 matches
Mail list logo
