Travis E. Oliphant wrote:
> How to handle unicode data-formats could definitely be improved.
> Suggestions are welcome.
'U4*10' string of 10 4-byte Unicode chars
Then for consistency you'd want 'S*10' rather than
just 'S10' (or at least allow it as an alternative).
--
Greg
___
Travis E. Oliphant wrote:
> The 'kind' does not specify how "big" the data-type (data-format) is.
What exactly does "bit" mean in that context?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Nick Coghlan wrote:
> I'd say the answer to where we put it will be dependent on what happens to
> the
> idea of adding a NumArray style fixed dimension array type to the standard
> library. If that gets exposed through the array module as array.dimarray,
> then
> it would make sense to expose
Nick Coghlan wrote:
> Greg Ewing wrote:
>> Also, what if I want to refer to fields by name
>> but don't want to have to work out all the offsets
> Use the list definition form. With the changes I've
> suggested above, you wouldn't even have to name the fields you don't
> care about - just desc
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>> In this case, the 'kind' does not specify how large the data-type is.
>> You can have 'u1', 'u2', 'u4', etc.
>>
>> The same is true with Unicode. You can have 10-character unicode
>> elements, 20-character, etc. But, we have to be clear ab
Martin v. Löwis wrote:
> Georg Brandl schrieb:
>> I wonder if it's possible that the build bot notification mails that go
>> to python-checkins include the last 10-15 lines from the log. This would
>> make it much easier to decide whether a buildbot failure is an old,
>> esoteric one (e.g.
>
> It
BJörn Lindqvist wrote:
> I'd like to write a post mortem for PEP 355. But one important
> question that haven't been answered is if there is a possibility for a
> path-like PEP to succeed in the future? If so, does the path-object
> implementation have to prove itself in the wild before it can be
>
Travis E. Oliphant wrote:
> M.-A. Lemburg wrote:
>> Travis E. Oliphant wrote:
>>> M.-A. Lemburg wrote:
Travis E. Oliphant wrote:
>
>
> PEP:
> Title: Adding data-type objects to the standard library
>
Georg Brandl schrieb:
> I wonder if it's possible that the build bot notification mails that go
> to python-checkins include the last 10-15 lines from the log. This would
> make it much easier to decide whether a buildbot failure is an old,
> esoteric one (e.g.
It should be possible to implement t
Travis E. Oliphant schrieb:
> In this case, the 'kind' does not specify how large the data-type is.
> You can have 'u1', 'u2', 'u4', etc.
>
> The same is true with Unicode. You can have 10-character unicode
> elements, 20-character, etc. But, we have to be clear about what a
> "character" is
Armin Rigo wrote:
> Hi Travis,
>
> On Fri, Oct 27, 2006 at 02:05:31PM -0600, Travis E. Oliphant wrote:
>> This PEP proposes adapting the data-type objects from NumPy for
>> inclusion in standard Python, to provide a consistent and standard
>> way to discuss the format of binary data.
M.-A. Lemburg wrote:
> Travis E. Oliphant wrote:
>> M.-A. Lemburg wrote:
>>> Travis E. Oliphant wrote:
PEP:
Title: Adding data-type objects to the standard library
Attributes
kind
Josiah Carlson wrote:
> I think that even on 64 bit platforms, using 'int' or 'long' generally
> means 32 bit. In order to get 64 bit ints, one needs to use 'long long'.
real 64-bit platforms use the LP64 standard, where long and pointers are
both 64 bits:
http://www.unix.org/version2/wha
"M.-A. Lemburg" <[EMAIL PROTECTED]> wrote:
>
> Travis E. Oliphant wrote:
> > M.-A. Lemburg wrote:
> >> Travis E. Oliphant wrote:
> >>>
> >>>
> >>> PEP:
> >>> Title: Adding data-type objects to the standard library
> >>> A
Travis E. Oliphant wrote:
> M.-A. Lemburg wrote:
>> Travis E. Oliphant wrote:
>>>
>>>
>>> PEP:
>>> Title: Adding data-type objects to the standard library
>>> Attributes
>>>
>>> kind -- returns the basic "kind" o
Hi Travis,
On Fri, Oct 27, 2006 at 02:05:31PM -0600, Travis E. Oliphant wrote:
> This PEP proposes adapting the data-type objects from NumPy for
> inclusion in standard Python, to provide a consistent and standard
> way to discuss the format of binary data.
How does this compare with
Hi,
I wonder if it's possible that the build bot notification mails that go
to python-checkins include the last 10-15 lines from the log. This would
make it much easier to decide whether a buildbot failure is an old,
esoteric one (e.g.
test_wait4
sem_post: Success
make: *** [buildbottest] Killed
M.-A. Lemburg wrote:
> Travis E. Oliphant wrote:
>>
>>
>>
>> PEP:
>> Title: Adding data-type objects to the standard library
>> Attributes
>>
>> kind -- returns the basic "kind" of the data-type. The basic kinds
Travis E. Oliphant wrote:
>
>
>
>
> PEP:
> Title: Adding data-type objects to the standard library
> Attributes
>
> kind -- returns the basic "kind" of the data-type. The basic kinds
> ar
On Oct 28, 2006, at 1:50 AM, Martin v. Löwis wrote:
Steven Bethard schrieb:
Jack Howarth asked about creating universal binaries for OS X that
would support 32-bit or 64-bit on both PPC and x86. Ronald Oussoren
pointed out that the 32-bit part of this was already supported, but
indicated that
20 matches
Mail list logo
