Forgive my ignorance, but I'm not really sure what this PEP is trying to
do. I don't want to sound negative, I really just don't understand the
purpose. I've just never encountered a problem this that I can see how
this PEP will help me solve.
That doesn't mean it's not worthwhile, I just do
On 4/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
You summarize the differences clearly. Let's agree to disagree. I
think that having to have an abstraction marker on the class *and* on
the abstract methods is asking the user to repeat (nearly) the same
information twice, and I really don
On 4/22/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I got off to a good start in terms of figuring out what needs to be in the
> PEP... good enough to realize that a complete specification of what I have
> in mind is probably going to dwarf the WSGI spec. There are just too many
> details tha
I'm one of the PEP editors at the end of peps-at-python-dot-org; Barry
Warsaw is the other. Since before PyCon, I haven't had time for PEP
number assignments, editing, and checkins. I don't follow python-dev
or python-3000 closely, so I only recently learned of the April 30
deadline for PEPs. I'd l
At 06:33 AM 4/26/2007 -0700, BJörn Lindqvist wrote:
>On 4/22/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > I got off to a good start in terms of figuring out what needs to be in the
> > PEP... good enough to realize that a complete specification of what I have
> > in mind is probably going to
Phillip J. Eby wrote:
> In particular, when you implement generic functions using generic
> functions, it reads a lot like trying to explain the relationships between
> "type" and "object" (i.e. type being its own type and an instance of
> object, and object being a subclass of type). You can s
[sage list added]
"Travis E. Oliphant" <[EMAIL PROTECTED]> writes:
> The SAGE people may be interested in this, but I doubt there will more
> than a handful of users of these algebraic base classes.
SAGE has quite a sophisticated type hierarchy, and a sophisticated set
of coercion methods. Wha
On 4/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> In [Emin's] version one has to repeat "AbstractBaseClass" each
> time a class contains (or inherits) abstract methods.
His modified proposal is better, though perhaps still too complicated.
You must declare a class abstract *either* by ex
> Are the base number operations in Python all that difficult to
> understand?
Well, they're a little tricky.
But the basic problem with "number" support, in almost every
programming language, is that they are too low-level an abstraction.
A number in a program is never *just* an integer or a flo
On Thu, 26 Apr 2007 10:11:27 PDT, Bill Janssen <[EMAIL PROTECTED]> wrote:
>> Are the base number operations in Python all that difficult to
>> understand?
>
>Well, they're a little tricky.
>
>But the basic problem with "number" support, in almost every
>programming language, is that they are too lo
> Jeffrey, is there any way you can drop the top of the tree and going
> straight from Number to Complex -> Real -> Rational -> Integer? These
> are the things that everyone with high school math will know.
I think knowledge of the concepts of group, ring, and field is
supposed to be standard know
> But it makes sense in some cases to insist that someone who goes
> through the trouble of inheriting from an ABC gets an error if they
> forget to implement one of the methods that are deemed 'essential' to
> that ABC.
This is the problem with abstract methods. What should happen is that
the de
On 4/26/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
[Guido]
> > But it makes sense in some cases to insist that someone who goes
> > through the trouble of inheriting from an ABC gets an error if they
> > forget to implement one of the methods that are deemed 'essential' to
> > that ABC.
>
> This i
I've come late to this thread, and misunderstood what was wrong with
super(), so a thousand pardons please. But since that's never stopped
me before...
Guido van Rossum wrote:
> But:
>
> class E(D): pass
>
> print E().f()
>
> This prints DDBCA which surely isn't right.
>
> Sounds like the
Writing B.__super__.f(self) instead of super(B, self).f() is not an improvement.
On 4/26/07, Joel Bender <[EMAIL PROTECTED]> wrote:
> I've come late to this thread, and misunderstood what was wrong with
> super(), so a thousand pardons please. But since that's never stopped
> me before...
>
> Gui
At 09:00 AM 4/26/2007 -0700, Talin wrote:
>I kind of wonder about the idea of implementing generic functions using
>generic functions. It's one of those ideas that is so obviously elegant
>and clever, that it's very easy for a programmer to fall in love with.
>As someone who frequently finds himsel
On 4/25/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> The current ABC proposal is to use isinstance as the test; Jeffrey
> Yaskin's numbers PEP highlighted the weakness there with a concrete
> example.
>
> If you need to an abstraction less powerful than an existing ABC,
> you're out of luck; you can
On 4/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I now have a proposal to allow overloading isinstance() and
> issubclass(), by defining special (class) methods on the second
> argument. See http://python.org/sf/1708353. Does this need a PEP? The
> unit test shows that it can be used to su
On 4/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I now have a proposal to allow overloading isinstance() and
> issubclass(), by defining special (class) methods on the second
> argument. See http://python.org/sf/1708353. Does this need a PEP?
It needs to be mentioned in the ABC PEP; wheth
David> ... I only recently learned of the April 30 deadline for
David> PEPs.
This is the first I heard of any sort of deadline...
Skip
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubs
Guido van Rossum wrote:
> Yeah. I like @abstractmethod to mean "not implemented" (except perhaps
> as an end point for cooperative super calls). For the latter concept,
> I propose that all methods present in an apparent ABC are considered
> part of the interface, unless their name starts with a si
On 4/26/07, Talin <[EMAIL PROTECTED]> wrote:
> I kind of wish that it was called "incomplete" rather than abstract, for
> reasons that we've already discussed.
Can't remember the details though I vaguely recall some grumblings about that.
But why invent new terminology when we can leverage existi
22 matches
Mail list logo
