On Fri, Sep 26, 2008 at 7:42 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-09-26 12:08, Antoine Pitrou wrote:
>> So what would be the outcome of this discussion, and should a decision (and
>> which one) be taken?
>
> I'm still -1 on changing Unicode objects to PyVarObjects for the
> reason
On 2008-09-26 12:08, Antoine Pitrou wrote:
> So what would be the outcome of this discussion, and should a decision (and
> which one) be taken?
I'm still -1 on changing Unicode objects to PyVarObjects for the
reasons already stated in various postings on this thread and on
the ticket.
I'd much ra
So what would be the outcome of this discussion, and should a decision (and
which one) be taken?
Regards
Antoine.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python
> Coming back to this: Why is this done anyway? Can't the new instance of the
> unicode-subtype just steal the buffer pointer of the already allocated
> unicode
> object?
Only if the refcount of the tmp object is 1. But then, yes, it could.
You then also need to change unicode_dealloc, to only
Hello,
M.-A. Lemburg egenix.com> writes:
>
> It turned out that the patch only provides a marginal performance
> improvement, so the perceived main argument for the PyVarObject
> implementation doesn't turn out to be a real advantage.
Uh, while the results are not always overwhelming, they are
Stefan Behnel wrote:
> Antoine Pitrou wrote:
>> Stefan Behnel behnel.de> writes:
>>> From a Cython perspective, I find the lack of efficient subclassing after
>>> such a change particularly striking.
>> what do you call "efficient subclassing"? if you look at the current
>> implementation of unico
Before jumping to conclusions, please read the discussion on the
patch ticket:
http://bugs.python.org/issue1943
It turned out that the patch only provides a marginal performance
improvement, so the perceived main argument for the PyVarObject
implementation doesn't turn out to be a real advant
Stefan Behnel wrote:
> (s + s->tp_basicsize)
I (obviously) meant
(s + Py_TYPE(s)->tp_basicsize)
so the impact is another bit bigger.
Stefan
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-
Greg Ewing canterbury.ac.nz> writes:
> > We create a new struct for the type that contains the parent-struct
> > as first field, and then we add the new attributes of the new type behind
> > that.
>
> I seem to remember there's a field in the type called tp_basicsize
> that's meant to indicate ho
Martin v. Löwis wrote:
>> I wouldn't mind letting Cython special case subtypes of str (or unicode in
>> Py3) *somehow*, as long as this "somewhow" proves to be a viable solution
>> that
>> only applies to exactly those types *and* can be done realiably for subtypes
>> of subtypes. I'm just not awa
> How about putting the variable sized data _before_ the struct?
That won't work for container objects (such as tuples); they already
have the GC structure before the PyObject, whose size and layout is
opaque to the objects.
Regards,
Martin
___
Python-3
Stefan Behnel wrote:
We create a new struct for the type that contains the parent-struct
as first field, and then we add the new attributes of the new type behind
that.
I seem to remember there's a field in the type called tp_basicsize
that's meant to indicate how big the base part of the stru
Martin v. Löwis wrote:
I wouldn't mind letting Cython special case subtypes of str (or unicode in
Py3) *somehow*, as long as this "somewhow" proves to be a viable solution that
only applies to exactly those types *and* can be done realiably for subtypes
of subtypes. I'm just not aware of such a s
> base_address + base_address[ob_len]*elem_size - more_fields_size
The subtraction is wrong, of course - it's still an addition. I was
just confused by tp_dictoffset being negative in that case; the sign
is but a mere flag in that case, and the offset is still positive.
Regards,
Martin
> I wouldn't mind letting Cython special case subtypes of str (or unicode in
> Py3) *somehow*, as long as this "somewhow" proves to be a viable solution that
> only applies to exactly those types *and* can be done realiably for subtypes
> of subtypes. I'm just not aware of such a solution.
As peop
Stefan Behnel behnel.de> writes:
>
> cdef class MyListSubType(PyListObject):
> cdef int some_additional_int_field
> cdef my_struct* some_struct
>
> def __init__(self):
> self.some_struct = get_the_struct_pointer(...)
> self.some_additional_int_
Martin v. Löwis wrote:
>>> Can you explain this a bit more? I presume you're talking about
>>> subclassing in C
>> Yes, I mentioned Cython above.
>
> Can you please still elaborate? I have never used Cython before
Should have been clearer, sorry. C-level subtyping in Cython/Pyrex works as
follows
> Given that you can, today, subclass str in Python, without wasting an
> extra 4/8 bytes of memory, or adding anything new to the class object,
> why wouldn't anyone who really wanted to make a hypothetical optimized
> subclass just use the same mechanism (putting your additional data
> *after* th
>> Can you explain this a bit more? I presume you're talking about
>> subclassing in C
>
> Yes, I mentioned Cython above.
Can you please still elaborate? I have never used Cython before, but
if it cannot efficiently subclass str, isn't that a bug in Cython?
>> I do note that the mechanisms that
On Sep 7, 2008, at 6:55 PM, Guido van Rossum wrote:
One possibility that occurs to me is to use a PyVarObject variant
that
allocates space for an additional void pointer before the variable
sized
section of the object. The builtin type would leave that pointer
NULL,
but subtypes could perfor
On Sun, Sep 7, 2008 at 2:23 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>> All in all, given the advantage (half the number of allocations) of
>> the proposal I think there would have to be *very* good arguments
>> against before we reject this outright. I'd like to unders
Guido van Rossum wrote:
> All in all, given the advantage (half the number of allocations) of
> the proposal I think there would have to be *very* good arguments
> against before we reject this outright. I'd like to understand
> Marc-Andre's reasons too.
As Stefan notes, because of the frequency w
Hi,
Guido van Rossum wrote:
> On Sun, Sep 7, 2008 at 12:15 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
>> Antoine Pitrou wrote:
>>> Also note that Marc-André Lemburg (one of the authors of the unicode
>>> implementation) is opposed to that change. See the discussion in the bug
>>> tracker
>>> is
Antoine Pitrou wrote:
> Stefan Behnel behnel.de> writes:
>> From a Cython perspective, I find the lack of efficient subclassing after
>> such
>> a change particularly striking. That seriously bit me in Py2 when I tried
>> making XML text content a bit more intelligent in lxml (i.e. make it rememb
On Sun, Sep 7, 2008 at 12:15 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> Antoine Pitrou wrote:
>> Also note that Marc-André Lemburg (one of the authors of the unicode
>> implementation) is opposed to that change. See the discussion in the bug
>> tracker
>> issue for the details.
>
> From a Cyth
Stefan Behnel behnel.de> writes:
>
> From a Cython perspective, I find the lack of efficient subclassing after such
> a change particularly striking. That seriously bit me in Py2 when I tried
> making XML text content a bit more intelligent in lxml (i.e. make it remember
> what XML element it ori
Antoine Pitrou wrote:
> Also note that Marc-André Lemburg (one of the authors of the unicode
> implementation) is opposed to that change. See the discussion in the bug
> tracker
> issue for the details.
From a Cython perspective, I find the lack of efficient subclassing after such
a change partic
Jeremy Kloth gmail.com> writes:
>
> I don't know if this is too late to do before the final release, but
> shouldn't
> the implementation of PyUnicodeObject be updated to match the much more
> efficient old PyStringObject layout? I mean eliminating the double malloc
> that is currently requi
This is an excellent idea that fell by the wayside. Since it is a
major coding project there's no way it can be done for 3.0 -- the risk
of introducing new instabilities or leaks is just too high. We *might*
be able to get it in for 3.0.1, if the code is reviewed really well.
Though it might be saf
I don't know if this is too late to do before the final release, but shouldn't
the implementation of PyUnicodeObject be updated to match the much more
efficient old PyStringObject layout? I mean eliminating the double malloc
that is currently required for each unicode string.
PyStringObject is
30 matches
Mail list logo
