On Mon, 21 Aug 2006 14:21:30 -0700, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
>Talin <[EMAIL PROTECTED]> wrote:
>[snip]
>> I've been thinking about the transition to unicode strings, and I want
>> to put forward a notion that might allow the transition to be done
>> gradually instead of all at on
Talin <[EMAIL PROTECTED]> wrote:
[snip]
> I've been thinking about the transition to unicode strings, and I want
> to put forward a notion that might allow the transition to be done
> gradually instead of all at once.
>
> The idea would be to temporarily introduce a new name for 8-bit strings
On 8/20/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-Hash: SHA1On Aug 20, 2006, at 11:24 AM, Guido van Rossum wrote:> I wonder if it would make sense to focus in 2.6 on making porting of> 2.6 code to 3.0 easier, rather than trying to introduce new features
> in 2.6.
I'll keep this in mind -- with the caveat that Georg mentioned.
For the next 96 hours I'm going to be severely limited in bandwidth
due to the physical requirements of the sprint at Google. I'd
appreciate not receiving too much email during this period...
--Guido
On 8/20/06, Talin <[EMAIL PROTEC
On 8/21/06, Alexander Belopolsky <[EMAIL PROTECTED]> wrote:
There are also cases of implicit casts like this that were notcaught so far:static Py_ssize_tmmap_buffer_getreadbuf(mmap_object *self, Py_ssize_t index, constvoid **ptr){ ... return self->size;
}static Py_ssize_tmmap_buffer_getwr
On Aug 21, 2006, at 10:34 AM, Thomas Wouters wrote:
>
> Is there a simple automated way to detect situations like this? Maybe
> there is a win64 compiler that would generate a warning.
>
> I doubt it. Explicit casts are meant to silence warnings (among
> other things.) Warning for all casts is
On 8/21/06, Alexander Belopolsky <[EMAIL PROTECTED]> wrote:
Here is a similar problem:typedef struct { ... size_t pos; ...} mmap_object;...mmap_tell_method(mmap_object *self, PyObject *unused){CHECK_VALID(NULL);return PyInt_FromLong((long) self->pos);
}See Modules/mmapmodule.
On 8/21/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
[snip]
> > Is this a bug?
[snap]
> Yes. Py_ssize_t can be bigger than a long (on LLP64 systems, such as Win64).
Here is a similar problem:
typedef struct {
...
size_t pos;
...
} mmap_object;
...
mmap_tell_method(mmap_object *self, PyO
Collin Winter:
> [ improvements to unittest]
These would all have been (mostly) reasonable when the module was
first added to the standard library. But it has been there as an ugly
fragile unchanging beast for several years, and is ironically not well
endowed with unit tests. I therefore think
On 8/21/06, Alexander Belopolsky <[EMAIL PROTECTED]> wrote:
On Aug 15, 2006, at 3:16 AM, Martin v. Löwis wrote:>> Where does it assume that it is safe to case ssize_t -> long?> That would be a bug.Is this a bug?file_readinto(PyFileObject *f, PyObject *args)
{... Py_ssize_t ndone, nnow;...
John J Lee wrote:
>> And once the result has been promoted to unicode, __unicode__ is used
>> directly:
>>
> print repr("%s%s" % (a(), a()))
>> __str__
>> accessing <__main__.a object at 0x00AF66F0>.__unicode__
>> __str__
>> accessing <__main__.a object at 0x00AF6390>.__unicode__
>> __str__
>
Talin wrote:
> Guido van Rossum wrote:
>> I've been thinking a bit about a focus for the 2.6 release.
>>
>> We are now officially starting parallel development of 2.6 and 3.0. I
>> really don't expect that we'll be able to merge the easily into the
>> 3.0 branch much longer, so effectively 3.0 wil
12 matches
Mail list logo
