Guido van Rossum wrote:
> Unless they were looking at classic classes, why wouldn't they be
> using the specific Py_Check() macros?
I'm thinking of Pyrex code. One of the goals of Pyrex
is that you should be able to write it without needing
to know about the Python/C API. One of the places that's
>> That doesn't work. For variable-sized objects, it would need
>> to be ob_base.ob_base.ob_type.
>
> I was wondering about that. It seems that each level
> of inheritance is going to add another level of
> required member access. Or is it legal to short-
> circuit all that and just cast directly
[-python-dev]
I think these should be two separate proposals, with more specific
names (e.g. "remove implicit string concatenation" and "remove
backslash continuation"). There's no need to mention the octal thing
if it's already a separate PEP.
On 4/29/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
>
[Collin Winter]
> Put another way, a role is an assertion about a set of capabilities.
. . .
> If there's interest in this, I could probably whip up a PEP before the
> deadline.
+100 I'm very interested in seeing a lighter weight alternative to abc.py that:
1) is dynamic
2) doesn't require inhe
On 4/29/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Currently, isinstance(x, C) implies that the
> C struct layout of x is compatible with that
> defined by C. I'm worried that changing this
> could cause difficulties for extension modules
> that use PyObject_IsInstance do decide what
> to do with
On 4/29/07, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> I think the current PEP draft is way too complicated - I don't think
> there's any need for descriptors, etc. I think we can make things work
> in the following way:
>
> 1. When a method is defined, the class is bound to it via an attr
On 4/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/29/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > On 4/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > Hmm... Maybe the conclusion to draw from this is that we shouldn't
> > > make Ring a class? Maybe it ought to be a metaclass,
PEP: 30xz
Title: Simplified Parsing
Version: $Revision$
Last-Modified: $Date$
Author: Jim J. Jewett <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 29-Apr-2007
Post-History: 29-Apr-2007
Abstract
Python initially inherited its parsing from C. While t
On 4/29/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 4/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Hmm... Maybe the conclusion to draw from this is that we shouldn't
> > make Ring a class? Maybe it ought to be a metaclass, so we could ask
> > isinstance(Complex, Ring)?
>
> Yes; all the
On 4/29/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Or isexample, so that we aren't locked into implementing ABCs as base classes.
You don't have to use the feature even if it exists. :-)
I think there are good reasons to support overriding
isinstance/issubclass beyond ABCs.
--
--Guido van Ross
On 4/29/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/29/07, Talin <[EMAIL PROTECTED]> wrote:
> > If it were technically possible, I would recommend that this PEP have to
> > run the same gauntlet that any other large library addition would, which
> > is to go through a long period of commun
On 4/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Hmm... Maybe the conclusion to draw from this is that we shouldn't
> make Ring a class? Maybe it ought to be a metaclass, so we could ask
> isinstance(Complex, Ring)?
Yes; all the ABCs are assertions about the class. (Zope interfaces do
s
Currently, isinstance(x, C) implies that the
C struct layout of x is compatible with that
defined by C. I'm worried that changing this
could cause difficulties for extension modules
that use PyObject_IsInstance do decide what
to do with things, e.g. in a binary operator
method.
--
Greg
___
[cc:-numpy]
On 4/29/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/29/07, Talin <[EMAIL PROTECTED]> wrote:
> > If it were technically possible, I would recommend that this PEP have to
> > run the same gauntlet that any other large library addition would, which
> > is to go through a long per
On 4/29/07, Talin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Maybe we should stop trying to capture radically different
> > mathematical number systems using classes or types, and limit
> > ourselves to capturing the systems one learns in high school: C, R, Q,
> > Z, and (perhaps) N (
On 4/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/29/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > So it is a "keyword" in the sense that None is a keyword; not in the
> > stronger sense that "if" is a keyword?
>
> Um, how do you see those two differ? Is 'if' a keyword in the same
> se
Martin v. Löwis wrote:
> That doesn't work. For variable-sized objects, it would need
> to be ob_base.ob_base.ob_type.
I was wondering about that. It seems that each level
of inheritance is going to add another level of
required member access. Or is it legal to short-
circuit all that and just cas
On 4/29/07, Talin <[EMAIL PROTECTED]> wrote:
> If it were technically possible, I would recommend that this PEP have to
> run the same gauntlet that any other large library addition would, which
> is to go through a long period of community feedback and criticism,
> during which a large number of p
Guido van Rossum wrote:
> Maybe we should stop trying to capture radically different
> mathematical number systems using classes or types, and limit
> ourselves to capturing the systems one learns in high school: C, R, Q,
> Z, and (perhaps) N (really N0). The concrete types would be complex <:
> C,
On 4/29/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> So it is a "keyword" in the sense that None is a keyword; not in the
> stronger sense that "if" is a keyword?
Um, how do you see those two differ? Is 'if' a keyword in the same
sense as 'or', or in a different sense?
I realize that in Python 2.5
On 4/29/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 4/29/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > On 4/29/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > As long as you can be explicit, should the shortcut be a full
> > > shortcut? That is,
> > >
> > > def f(self, a, b=c, *args
On 4/29/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> On 4/29/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > On 4/29/07, Tim Delaney <[EMAIL PROTECTED]> wrote:
> > > 4. super objects are callable, and calling them will execute the super
> > > method with the same name as the instance method curre
On 4/29/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Guido wrote:
> > Note though that only the second argument to either function can
> > overload the rules. IOW if you write isinstance(x, C), there is no way
> > that x could attempt to lie; but C could.
>
> As Barry pointed out, this means a class
[cc:-python-dev]
On 4/29/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> On 4/29/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > As long as you can be explicit, should the shortcut be a full
> > shortcut? That is,
> >
> > def f(self, a, b=c, *args, **kwargs):
> > super()# passes th
On 4/29/07, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> On 4/28/07, Baptiste Carvello <[EMAIL PROTECTED]> wrote:
> > 2) In the PEP, the concepts are used *inconsistently*. Complex derives from
> > Ring
> > because the set of complex numbers *is a* ring. Int derives from Complex
> > because
> > i
On 4/29/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 4/29/07, Tim Delaney <[EMAIL PROTECTED]> wrote:
> > I've been intending to write up a PEP for fixing super, but I haven't had
> > time to get to it.
>
> Calvin Spealman has the most recent draft. I hope he will incorporate
> this into his draft
On 4/29/07, Tim Delaney <[EMAIL PROTECTED]> wrote:
> I've been intending to write up a PEP for fixing super, but I haven't had
> time to get to it.
Calvin Spealman has the most recent draft. I hope he will incorporate
this into his draft.
> 1. 'super' becomes a keyword, that returns a super objec
(Adding python-3000 to the Cc, since that is where much of the recent
discussion occurred)
Calvin's full proposal is archived at:
http://mail.python.org/pipermail/python-dev/2007-April/072835.html
> Abstract
>
> The PEP defines the proposal to enhance the super builtin to work implicit
I've been intending to write up a PEP for fixing super, but I haven't had
time to get to it. I've worked out the semantics I'm going to propose
though. I've attached an implementation of those semantics as far as I've
been able to get them so far.
I think this could be targeted at 2.6, with a
Done.
On 4/25/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> I'd like to propose that the bsddb185 module be added to PEP 3108's
> list of modules slated for removal. Reasons to kill it:
>
> - The module isn't built by default; manual tweaking of setup.py is required.
>
> - The following scare-par
On 4/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Are we going to have a preference over PyObject_HEAD or defining the
> > struct field directly?
>
> That is an open issue. PyObject_HEAD clearly is more
> backwards-compatible. However (besides its current non-C-conformance),
> I never li
On 29/04/2007 19.57, Martin v. Löwis wrote:
> That is an open issue. PyObject_HEAD clearly is more
> backwards-compatible. However (besides its current non-C-conformance),
> I never liked it, because of the missing semicolon (I thought it
> confuses Emacs, but can't reproduce the problem anymore,
>> > if (!module)
>> >return NULL;
>> > PyObject* xx_error = xxstate(module)->ErrorObject;
>> > if (!xx_error) {
>> >PyErr_SetString(PyExc_SystemError, "xx.error missing");
>> >return NULL;
>> > }
>>
>> That should not fail. If the module object is still present,
>> the state should
> Are we going to have a preference over PyObject_HEAD or defining the
> struct field directly?
That is an open issue. PyObject_HEAD clearly is more
backwards-compatible. However (besides its current non-C-conformance),
I never liked it, because of the missing semicolon (I thought it
confuses Emac
On 4/28/07, Baptiste Carvello <[EMAIL PROTECTED]> wrote:
> 2) In the PEP, the concepts are used *inconsistently*. Complex derives from
> Ring
> because the set of complex numbers *is a* ring. Int derives from Complex
> because
> integer are complex numbers (or, alternatively, the set of integers
On 4/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Brett,
>
> Thanks for the suggestions; I added them to the PEP.
>
> > How would I raise xx.error in C code now? I am guessing like this::
>
> Interestingly enough, xxmodule doesn't raise error.
>
> > PyObject* module = PyState_FindModule(
On 4/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > An example of how this will change current code would be good. E.g.,
> > ``o->ob_type->tp_name`` becomes ``PyType(o)->typ_name`` or
> > ``o->ob_base->ob_type->tp_name``.
> >
> > Otherwise I am all for cleaning up the codebase and thus su
On 4/28/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> I'm just going to jump into this and voice a concern that allowing
> overriding of isinstance and issubclass seems like a Bad Idea.
I'm also uncomfortable, which is why I originally suggested a parallel
predicate. That said, I can't put my
Brett,
Thanks for the suggestions; I added them to the PEP.
> How would I raise xx.error in C code now? I am guessing like this::
Interestingly enough, xxmodule doesn't raise error.
> PyObject* module = PyState_FindModule(&xxmodule);
Either that, or just use the self parameter if you are in
> - add the new access macros to 2.6 (defined appropriately)
> - in 3.0, instead of removing PyObject_HEAD and company, redefine them
> appropriately, .e.g, #define PyObject_HEAD PyObject obtype;
Thanks, I added both of them into PEP 3123 (now retitled to
indicate that PyObject_HEAD is not dropped
> An example of how this will change current code would be good. E.g.,
> ``o->ob_type->tp_name`` becomes ``PyType(o)->typ_name`` or
> ``o->ob_base->ob_type->tp_name``.
>
> Otherwise I am all for cleaning up the codebase and thus support this PEP.
Thanks for the suggestions, I have add them all i
>> I propose the PEP below for Py3k.
>
> I think it's a good idea. It would be nice if the PEP included
> something about forwards compatibility. Ideally, there should be a
> way to write a module that works with both 2.x and 3.x (e.g. using
> preprocessor macros). Obviously the 3.x design shou
Greg Ewing schrieb:
> Martin v. Löwis wrote:
>> I expect access to ob_type is frequent in Foo_Check() macros;
>> those need to be rewritten to use Py_Type(op).
>
> Maybe some of this breakage could be repaired by renaming
> the real ob_type field and doing something like
>
>#define ob_type ob
43 matches
Mail list logo
