Fredrik Lundh wrote:
> Talin wrote:
>
>> OK. Its easy to implement either way. I coded up a string-based version,
>> but if you guys want integer constants that's fine with me; probably
>> best to let Fredrik & Larry tweak their patch rather than me continuing
>> along this path since their stuff
Talin wrote:
> OK. Its easy to implement either way. I coded up a string-based version,
> but if you guys want integer constants that's fine with me; probably
> best to let Fredrik & Larry tweak their patch rather than me continuing
> along this path since their stuff is further along.
wouldn't i
Guido van Rossum wrote:
> The ordering argument is also handled by using C99 initializers.
Not being able to compile extension modules under Visual Studio seems
like a show stopper to me.
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
ht
On 12/2/06, Talin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > My preference is for a table-based version over a "lots-of-calls"
> > approach. I think the idea of using predefined (integer) constants
> > instead of string constants fits fine into the table-based approach.
> > However I'
Guido van Rossum wrote:
> My preference is for a table-based version over a "lots-of-calls"
> approach. I think the idea of using predefined (integer) constants
> instead of string constants fits fine into the table-based approach.
> However I'm not sure that a string-based approach is necessarily
My preference is for a table-based version over a "lots-of-calls"
approach. I think the idea of using predefined (integer) constants
instead of string constants fits fine into the table-based approach.
However I'm not sure that a string-based approach is necessarily bad
-- we use that now for every
Talin wrote:
> So I don't think it's the case that nobody's even bothered to look at
> Larry's patch
so are you basing your patch on his work?
> People have looked at the patch and suggested taking a different
> approach.
really? I haven't seen much of a consensus for the string-literals
i
Fredrik Lundh wrote:
> Guido van Rossum wrote:
>
>> Any volunteers? Without code this proposal is dead in the water.
>
> given that nobody's even bothered to look at Larry's patch for 2.X, it
> seems to take a bit more than just code to get something into Py3K.
> Talin obviously suffers from a
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> - Can't we require a C99 compiler and use C99 struct initialization?
> Then the table lines could look like
>
> tp_new = Noddy_new,
> tp_init = Noddy_init,
The C99 syntax is:
.tp_new = Noddy_new,
.tp_init = Noddy_init,
GCC also suppor
Guido van Rossum wrote:
> Any volunteers? Without code this proposal is dead in the water.
given that nobody's even bothered to look at Larry's patch for 2.X, it
seems to take a bit more than just code to get something into Py3K.
Talin obviously suffers from a serious case of NIH, but does that
Guido van Rossum wrote:
> Nevertheless, I kind of like this, and would like someone to produce a
> patch for this approach. It is my opinion that without working code it
> is too easy to overlook design flaws. Since you are keen to have this
> in 2.6, the solution would have to be backwards compat
On 30 Nov 2006, at 1:34 AM, Greg Ewing wrote:
Ronald Oussoren wrote:
It is already possibly to extend the type struct in Python 2.3
and later
From Python?
No, from C.
Python 2.3 (#1, Aug 5 2003, 15:52:30)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits"
I don't know about this one. But I'm sure that the CVS history of
typeobject.c (in the 2.2a through 2.3 era, probably) would show that
serious hacks were necessary to make certain slots perform well
enough. I remember doing quite a bit of performance tuning with some
incredible results -- all to ma
Benji York wrote:
> One such coping mechanism is to configure mailman to not send you copies
> of messages you were sent directly via the "Avoid duplicate copies of
> messages?" option.
That's what I do, and it seems to work well enough.
When replying, sometimes I'll trim the address list down
Brett Cannon wrote:
> Or the other option is that in the future we just don't have the
> distinction and make sure that the __getitem__ methods do the requisite
> type checks. The type check is done at some point in the C code anyway
> so it isn't like there is a performance reason for the dif
Ronald Oussoren wrote:
> It is already possibly to extend the
> type struct in Python 2.3 and later
From Python?
Python 2.3 (#1, Aug 5 2003, 15:52:30)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class C(type):
... __s
Talin wrote:
> The "list" version, however, is considered an internal
> method (since it's more specialized), and has the name ".tp_getitem".
Is there really a need for both the dot and the tp_
prefix? Just ".getitem" etc. ought to be sufficient.
--
Greg
_
Talin wrote:
> Now, I tend to prefer using a static table vs. the
> function-call-per-method simply because of my habits, which tend to be
> overly parsimonious with code size and such (It's a side-effect of
> working on embedded systems, which is what game consoles effectively
> are.) I would
On 11/28/06, Talin <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:
> On 11/28/06, Talin <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > Some comments:
>> >
>> > - Fredrik's solution makes one call per registered method. (I don't
>> > know if the patch he refers to follows that mode
On 11/29/06, Talin <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:
> Have you thought much about the issue of different signature? The
> regular method table only has functions taking one or more objects and
> returning an object. (There are a few flags to indicate variations on
> the call ar
Guido van Rossum wrote:
> By all means use reply-all which CC's the author (and others). This
> seems to be what most people do, so folks who aren't using gmail yet
> have presumably developed other strategies to cope.
One such coping mechanism is to configure mailman to not send you copies
of me
On 11/29/06, Talin <[EMAIL PROTECTED]> wrote:
> (Oh, and off topic, I have a procedural question about the list: Is it
> considered good etiquette to only reply to the list, and not the
> individuals whom you are replying to? If you "reply all", then folks
> might get two copies of the message, but
Guido van Rossum wrote:
> Have you thought much about the issue of different signature? The
> regular method table only has functions taking one or more objects and
> returning an object. (There are a few flags to indicate variations on
> the call args.) The special slots have all sorts of other si
Have you thought much about the issue of different signature? The
regular method table only has functions taking one or more objects and
returning an object. (There are a few flags to indicate variations on
the call args.) The special slots have all sorts of other signatures,
some returning int, so
Guido van Rossum wrote:
> On 11/28/06, Talin <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > Some comments:
>> >
>> > - Fredrik's solution makes one call per registered method. (I don't
>> > know if the patch he refers to follows that model.) That seems a fair
>> > amount of code for an
On 29 Nov 2006, at 1:10 AM, Greg Ewing wrote:
BTW, another advantage of all this is that it provides a lot
more flexibility in the overall approach to implementing
the type object. For example, we might decide to move the
type slots into a separate memory block, so that the
type struct could
Talin wrote:
> It means that
> now the VM gets to decide what methods are special and what methods
> aren't.
Further to that, the VM still gets to decide whether any
given special method gets a type slot. But the SPECIAL
flag is needed to say that you intend the method to be
*used* as a special
Talin wrote:
> The other drawback is that there's a greater chance of a misspelling,
I don't think there is, really. It wouldn't be caught
at compile time, but it would be caught very quickly
at run time if you tried to initialise a type with a
method flagged as "special" whose name wasn't one of
On 11/28/06, Talin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Some comments:
> >
> > - Fredrik's solution makes one call per registered method. (I don't
> > know if the patch he refers to follows that model.) That seems a fair
> > amount of code for an average type -- I'm wondering if
On 11/28/06, Talin <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:
> Some comments:
>
> - Talin's solution seems to require the definition of an awful lot of
> new constants -- one per slot. And a lot of special-casing in the type
> initialization code to handle them because there are so many
Guido van Rossum wrote:
> Some comments:
>
> - Fredrik's solution makes one call per registered method. (I don't
> know if the patch he refers to follows that model.) That seems a fair
> amount of code for an average type -- I'm wondering if it's too early
> to worry about code bloat (I don't thin
Guido van Rossum wrote:
> Some comments:
>
> - Talin's solution seems to require the definition of an awful lot of
> new constants -- one per slot. And a lot of special-casing in the type
> initialization code to handle them because there are so many different
> signatures.
Actually, I was thinki
On 11/28/06, Talin <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
> > Guido van Rossum wrote:
> >
> >> - Fredrik's solution makes one call per registered method. (I don't
> >> know if the patch he refers to follows that model.) That seems a fair
> >> amount of code for an average type -- I'm won
On 11/28/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> >>> Can't we require a C99 compiler and use C99 struct initialization?
> >> that won't address the binary compatibility and optimization issues that
> >> are the main rationales for my proposal, though.
> >
> > Why
Fredrik Lundh wrote:
> Guido van Rossum wrote:
>
>> - Fredrik's solution makes one call per registered method. (I don't
>> know if the patch he refers to follows that model.) That seems a fair
>> amount of code for an average type -- I'm wondering if it's too early
>> to worry about code bloat (I
Guido van Rossum wrote:
>>> Can't we require a C99 compiler and use C99 struct initialization?
>> that won't address the binary compatibility and optimization issues that
>> are the main rationales for my proposal, though.
>
> Why not? This is the Py3k list -- there is no hope for binary
> compat
On 11/28/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > - Fredrik's solution makes one call per registered method. (I don't
> > know if the patch he refers to follows that model.) That seems a fair
> > amount of code for an average type -- I'm wondering if it's too ear
On 11/28/06, Talin <[EMAIL PROTECTED]> wrote:
> For example, consider the case for tp_init and tp_new. ... you have
> to put 37 initializer values before them, whether you use them or not.
> Now, you still have the problem that 'tp_methods' itself is something
> like the 28th field in the struct,
Guido van Rossum wrote:
> - Can't we require a C99 compiler and use C99 struct initialization?
> Then the table lines could look like
>
> tp_new = Noddy_new,
> tp_init = Noddy_init,
>
> This probably means the conversion tool would be even simpler (a
> couple of lines of sed would do). It has m
Guido van Rossum wrote:
> - Fredrik's solution makes one call per registered method. (I don't
> know if the patch he refers to follows that model.) That seems a fair
> amount of code for an average type -- I'm wondering if it's too early
> to worry about code bloat (I don't think the speed is goin
Some comments:
- I'm all for trying something new here; the existing approach is
definitely aged.
- Fredrik's solution makes one call per registered method. (I don't
know if the patch he refers to follows that model.) That seems a fair
amount of code for an average type -- I'm wondering if it's t
Greg Ewing wrote:
> Talin wrote:
>
>> What you end up with is code that looks like this:
>>
>> PyTypeObject myType = {
>> PyObject_HEAD_INIT(NULL)
>> 0,
>> "myType",
>> sizeof(myInstance)
>> }
>>
>> void init() {
>> if (PyType_ReadyInit( &myType, myTypeMethods, myTypeData
Talin wrote:
> What you end up with is code that looks like this:
>
> PyTypeObject myType = {
> PyObject_HEAD_INIT(NULL)
> 0,
> "myType",
> sizeof(myInstance)
> }
>
> void init() {
> if (PyType_ReadyInit( &myType, myTypeMethods, myTypeData ) < 0)
> return;
> }
If
Talin wrote:
> Has anyone proposed the notion of getting away from C-style initializer
> lists, at least for the case of PyTypeObject?
yes, and it was mentioned in the python-dev summaries that were mailed
out a couple of days ago:
http://effbot.org/zone/idea-register-type.htm
Larry Hast
More on the 'cruft removal' topic:
I notice that a number of fields in PyTypeObject are deprecated; the
question is, how to get rid of them without gratuitously breaking
everything? Even if there's zero code out there that still uses
tp_getattr instead of tp_getattro, you can't simply remove th
45 matches
Mail list logo
