Travis Oliphant added the comment:
On Aug 3, 2012, at 1:35 AM, Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>> This is a mis-understanding of what NumPy does and why.There is
>> a need to byte-swap only when the data is stored on disk in the
Travis Oliphant added the comment:
On Aug 2, 2012, at 6:09 PM, Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> The byte-swapping must be done prior to conversion to a Python
>> Unicode-Object when selecting data out of the array.
>
> But t
Travis Oliphant added the comment:
On Aug 2, 2012, at 5:28 PM, Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
> Agreed with Martin. Byte-swapped unicode data in unicode objects doesn't make
> sense, since it will break the semantics of many operations.
Travis Oliphant added the comment:
On May 19, 2010, at 2:38 PM, Mark Dickinson wrote:
>
> Mark Dickinson added the comment:
>
> Travis, this issue is still assigned to you. Do you plan to work on this at
> some stage, or may I unassign you?
>
You may unassign it from m
Travis Oliphant added the comment:
On Feb 12, 2010, at 7:29 PM, Meador Inge wrote:
>
> Meador Inge added the comment:
>
> Is anyone working on implementing these new struct modifiers? If
> not, then I would love to take a shot at it.
That would be
Travis Oliphant <[EMAIL PROTECTED]> added the comment:
Another comment on statements made
* I don't see where array.array getbuf implementation is broken. It
looks correct to me. It sets view.shape to NULL unless the consumer
asked for the shape information to be reported in wh
Travis Oliphant <[EMAIL PROTECTED]> added the comment:
My perspective on statements made:
* Memoryview object should report it's length as self->view.shape[0]
unless self->view.shape is NULL (indicating in this case a 0-d array or
scalar). In this case, it should raise a
Travis Oliphant <[EMAIL PROTECTED]> added the comment:
I will take some time in the next week to look at this issue. Thank you
for bringing these bugs to my attention.
I did not finish the memoryview implementation, due to other demands on
my time. I appreciate the efforts of so m
Travis Oliphant <[EMAIL PROTECTED]> added the comment:
This can be re-targeted to 3.1 as described.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Travis Oliphant <[EMAIL PROTECTED]>:
--
versions: +Python 3.1 -Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Travis Oliphant <[EMAIL PROTECTED]> added the comment:
It would have been nice to finish the memoryview object for 3.0, but I
ran into time constraints. The pieces that are left can be pushed to 3.1
___
Python tracker <[EMAIL PROTECTE
Changes by Travis Oliphant <[EMAIL PROTECTED]>:
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3046>
___
__
Travis Oliphant <[EMAIL PROTECTED]> added the comment:
I've added comments in the code to document these functions. I have no
opinion where they live except they should probably be available to
extensions modules.
These routines increment an N-length counter representing a posit
Travis Oliphant <[EMAIL PROTECTED]> added the comment:
I'm sorry that I was unavailable for comment during July and August as
it looks like a lot of decisions were made that have changed the
semantics a bit. I'm still trying to figure out why the decisions were
made that were
Travis Oliphant <[EMAIL PROTECTED]> added the comment:
I will look at the patch, but generally I'm not inclined to give the
array module more legs because I agree that the desired functionality
should be put into the memoryview object and the buff
Travis Oliphant <[EMAIL PROTECTED]> added the comment:
Greg Ewing's comment in the thread that read/write locking is orthogonal
to memory-buffer moving is to me the most convincing argument that the
locking portion of the getbuffer function call should be removed and
potentially
Changes by Travis Oliphant <[EMAIL PROTECTED]>:
--
assignee: -> theller
components: +ctypes
nosy: +theller
type: -> behavior
versions: +Python 2.6
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
New submission from Travis Oliphant <[EMAIL PROTECTED]>:
The ctypes object will support the PEP 3118 buffer protocol. This
support can be back-ported to Python 2.6
--
messages: 63977
nosy: teoliphant
severity: normal
status: open
title: Backport ctypes support for buffer proto
Changes by Travis Oliphant <[EMAIL PROTECTED]>:
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2399>
__
___
Python-bugs
Changes by Travis Oliphant <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file9734/msi.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2399>
__
_
New submission from Travis Oliphant <[EMAIL PROTECTED]>:
The attached patches add the following features to MSI building:
* allow splitting into multiple CABs
* prevent problem when data-base commits grow beyond a certain number
* fix to handle all file names
* change the way unique ke
Changes by Travis Oliphant <[EMAIL PROTECTED]>:
--
title: struct module changes of PEP 3118 -> [Py3k] struct module changes of PEP
3118
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Travis Oliphant <[EMAIL PROTECTED]>:
--
title: Finish the memoryview object implementation -> [Py3k] Finish the
memoryview object implementation
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
New submission from Travis Oliphant <[EMAIL PROTECTED]>:
The changes to the struct module in PEP 3118 should be backported to 2.6
as it is backward compatible and would smooth the transition to 3.0. It
is lower priority and could wait until 2.7
--
components: Library (Lib)
me
New submission from Travis Oliphant <[EMAIL PROTECTED]>:
The memoryview object in Python 2.6 would help in the transition to
Python 3.0. It is a lower-priority and could wait until 2.7 if it
doesn't get finished.
--
components: Interpreter Core
messages: 63930
nosy: teolipha
Changes by Travis Oliphant <[EMAIL PROTECTED]>:
--
type: -> behavior
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2395>
__
___
Python-b
New submission from Travis Oliphant <[EMAIL PROTECTED]>:
The additions to the struct module spelled out in PEP 3118 need to be
implemented for Python 3.0
--
components: Library (Lib)
messages: 63929
nosy: teoliphant
severity: normal
status: open
title: struct module changes of PE
New submission from Travis Oliphant <[EMAIL PROTECTED]>:
The memoryview object in Python 3.0 needs to be finished. There are a
few methods that are not complete. In particular, the __getitem__ and
__setitem__ functionality needs to be finished as well as the tolist()
Travis Oliphant <[EMAIL PROTECTED]> added the comment:
Back-porting of the new buffer interface was done in r61491. This issue
can be closed.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Travis Oliphant <[EMAIL PROTECTED]>:
Some (or all) of PEP 3118 should be backported to Python 2.6 because it
does not require backward-incompatible changes and can assist in the
transition to 3.0.
This issue is to be sure that the buffer-interface portion of PEP 3
Travis Oliphant added the comment:
I have two issues with this patch:
1) I'm not sure it's that bad to need to use '%d' % long(obj) to ensure
conversion to a long integer.
2) If this kind of auto-conversion is deemed useful, then the patch
itself is rather complicated.
Travis Oliphant added the comment:
This issue can be closed. The issue is resolved in SVN.
--
nosy: +teoliphant
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Travis Oliphant added the comment:
I applied phuang's patch in revision 58598. This can be closed.
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue708374>
_
Travis Oliphant added the comment:
I think this patch can be committed to SVN. Paul Moore has tested it on
Windows and I (Travis Oliphant) have tested it on UNIX (Mac OS X). The
patch also includes documentation updates and tests.
--
nosy: +teoliphant
Travis Oliphant added the comment:
This issue may be closed.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1268>
__
___
Python-bugs-list mailing list
Unsubs
35 matches
Mail list logo
