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
Raymond> With the extra time, it would be worthwhile to add dbm.sqlite
Raymond> to 3.0 to compensate for the loss of bsddb so that shelves
Raymond> won't become useless on Windows builds.
My vote is to separate 2.6 and 3.0 then come back together for 2.7 and 3.1.
I'm a bit less sure a
On Mon, Sep 8, 2008 at 7:07 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Guido van Rossum]
>>
>> Well, from the number of release blockers it sounds like another 3.0
>> beta is the right thing. For 2.6 however I believe we're much closer
>> to the finish line -- there aren't all those bytes/
[Guido van Rossum]
Well, from the number of release blockers it sounds like another 3.0
beta is the right thing. For 2.6 however I believe we're much closer
to the finish line -- there aren't all those bytes/str issues to clean
up, for example! And apparently the benefit of releasing on schedule
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
Guido van Rossum wrote:
Well, from the number of release blockers it sounds like another 3.0
beta is the right thing. For 2.6 however I believe we're much closer
to the finish line -- there aren't all those bytes/str issues to clean
up, for example! And apparently the benefit of releasing on sche
On Mon, Sep 8, 2008 at 4:13 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Mon, Sep 8, 2008 at 12:13 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On Mon, Sep 8, 2008 at 6:23 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>>> I don't think there's any way we're going to make our October 1s
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
On Mon, Sep 8, 2008 at 12:13 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 8, 2008 at 6:23 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> I don't think there's any way we're going to make our October 1st goal. We
>> have 8 open release critical bugs, and 18 deferred blockers. We d
> 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
Terry Reedy wrote:
> Different people have different mis-spelling quirks. I might type demon
> (in other contexts) but never deamon instead of daemon. There are other
> stdlib attributes I am more likely to misspell, so worrying about just
> this one, to the point of changing the implementation,
Nick Coghlan wrote:
(I deliberately pronounce daemon as day-mon though, so I don't forget
how to spell it - perhaps pronouncing it as dee-mon makes it harder to
remember the order of the 'a' and the 'e'?)
If it is just the specific typo as 'deamon' that concerns people, adding
a property spec
On Mon, Sep 8, 2008 at 6:23 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> I don't think there's any way we're going to make our October 1st goal. We
> have 8 open release critical bugs, and 18 deferred blockers. We do not have
> a beta3 Windows installer and I don't have high hopes for rectifying
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I don't think there's any way we're going to make our October 1st
goal. We have 8 open release critical bugs, and 18 deferred
blockers. We do not have a beta3 Windows installer and I don't have
high hopes for rectifying all of these problems i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 8, 2008, at 7:04 AM, Paul Moore wrote:
2008/9/8 wesley chun <[EMAIL PROTECTED]>:
the goal is admirable, but unless there are paying sponsors that
require this deadline be met, i'd suggest that we can push the
releases until they're ready. t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 7, 2008, at 4:12 PM, Fredrik Lundh wrote:
Barry Warsaw wrote:
(I have a few minor ET fixes, and possibly a Unicode 5.1 patch,
but have had absolutely no time to spend on that. is the window
still open?)
There are 8 open release blockers
Anand Balachandran Pillai wrote:
> I guess adding __slots__ to Thread class is the best approach
> for this. +1 for that...
>
> IMHO, this is perhaps late for 3.0, but definitely a good thing
> to add for 3.1.
I'd want at least one major release with a deprecation warning on
Thread's __setattr__
Hello,
I thought I'd mention the following issue before it's too late to possibly fix
it in 3.0. Basically, os.write() accepts str as well as bytes object, which
doesn't sound right.
http://bugs.python.org/issue3782
Regards
Antoine.
___
Python-3000
2008/9/8 wesley chun <[EMAIL PROTECTED]>:
> the goal is admirable, but unless there are paying sponsors that
> require this deadline be met, i'd suggest that we can push the
> releases until they're ready. the changes that 2.6 and 3.0 bring are
> too major to be released before they are ready for
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_
22 matches
Mail list logo
