> Is anyone aware of any implementations that use other than 64-bit
> floating-point?
As I understand you are asking about Python implementations:
sure, the gmpy package supports arbitrary-precision floating point.
> I'd be particularly interested in any that use greater
> precision than the usua
Greg Ewing canterbury.ac.nz> writes:
>
>1) The memoryview should *not* be holding onto a Py_buffer
> in between calls to its getitem and setitem methods. It
> should request one from the underlying object when needed
> and release it again as soon as possible.
If the memory
Lars Kotthoff wrote:
This prints out "foo" twice although it's only written once to the pipe. It
seems that python doesn't flush file descriptors before copying them to the
child process, thus resulting in the duplicate message. The equivalent C
program behaves as expected,
Your Python and C p
Antoine Pitrou wrote:
Why should it need two? Why couldn't the embedded Py_buffer fullfill all the
needs of the memoryview object?
Two things here:
1) The memoryview should *not* be holding onto a Py_buffer
in between calls to its getitem and setitem methods. It
should request on
Nick Coghlan gmail.com> writes:
>
> For the slicing problem in particular, memoryview is currently trying to
> get away with only one Py_buffer object when it needs TWO.
Why should it need two? Why couldn't the embedded Py_buffer fullfill all the
needs of the memoryview object? If the memoryview
Nick Coghlan wrote:
[from the PEP] "If the exporter wants to be able to change an
object's shape, strides, and/or suboffsets before releasebuffer is
called then it should allocate those arrays when getbuffer is called
(pointing to them in the buffer-info structure provided) and free them
when re
Antoine Pitrou wrote:
That doesn't work if e.g. you take a slice of a memoryview object, since the
shape changes in the process.
See http://bugs.python.org/issue4580
I haven't looked in detail at how memoryview is currently
implemented, but it seems to me that the way it should work
is that wh
Nick Coghlan wrote:
Maintaining a PyDict instance to map from view pointers to shapes
and strides info doesn't strike me as a "complex scheme" though.
I don't see why a given buffer provider should ever need
more than one set of shape/strides arrays at a time. It
can allocate them on creation,
Antoine Pitrou wrote:
> Le mardi 09 décembre 2008 à 22:33 +1000, Nick Coghlan a écrit :
>> memoryview also currently gets the shape wrong on slices:
>
> I know, that's what I'm trying to fix...
Yes, I was slightly misled by your use of slice assignment to
demonstrate the problem. It also turns ou
James Y Knight wrote:
> On Dec 9, 2008, at 6:04 AM, Anders J. Munch wrote:
>> The typical application will just obliviously use os.listdir(dir) and
>> get the default elide-and-warn behaviour for un-decodable names. That
>> rare special application
>
> I guess this is a new definition of rare spec
В Втр, 09/12/2008 в 19:26 +, Lars Kotthoff пишет:
> Dear list,
>
> I recently noticed a python program which uses forks and pipes for
> communication between the processes not behaving as expected. The minimal
> example program:
If you write
r, w = os.pipe()
os.write(w, 'foo')
pid = os
On Dec 9, 2008, at 2:26 PM, Lars Kotthoff wrote:
Dear list,
I recently noticed a python program which uses forks and pipes for
communication between the processes not behaving as expected. The
minimal
example program:
[snip]
This prints out "foo" twice although it's only written once to
On Tue, Dec 9, 2008 at 11:31 AM, Ulrich Eckhardt
<[EMAIL PROTECTED]> wrote:
> On Monday 08 December 2008, Adam Olsen wrote:
>> At this point someone suggests we have a type that can store an
>> arbitrary mix of unicode and bytes, so the undecodable portions stay
>> in their original form. :P
>
> We
Dear list,
I recently noticed a python program which uses forks and pipes for
communication between the processes not behaving as expected. The minimal
example program:
#!/usr/bin/python
import os, sys
r, w = os.p
On Monday 08 December 2008, Adam Olsen wrote:
> At this point someone suggests we have a type that can store an
> arbitrary mix of unicode and bytes, so the undecodable portions stay
> in their original form. :P
Well, not an arbitrary mix, but a type that just stores whatever comes from
the syste
Mark Dickinson wrote:
> On Tue, Dec 9, 2008 at 5:15 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
>> precision than the usual 56-bit mantissa. Do modern 64-bit systems
>> implement anything wider than the normal double?
>
> I may have misinterpreted your question. Are you asking simply
> about what
On Tue, Dec 9, 2008 at 5:15 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
> precision than the usual 56-bit mantissa. Do modern 64-bit systems
> implement anything wider than the normal double?
I may have misinterpreted your question. Are you asking simply
about what the hardware provides, or about
On Tue, Dec 9, 2008 at 5:15 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
> Is anyone aware of any implementations that use other than 64-bit
> floating-point? I'd be particularly interested in any that use greater
> precision than the usual 56-bit mantissa. Do modern 64-bit systems
> implement anyth
Is anyone aware of any implementations that use other than 64-bit
floating-point? I'd be particularly interested in any that use greater
precision than the usual 56-bit mantissa. Do modern 64-bit systems
implement anything wider than the normal double?
regards
Steve
--
Steve Holden+1 571
On Dec 9, 2008, at 6:04 AM, Anders J. Munch wrote:
The typical application will just obliviously use os.listdir(dir)
and get the default elide-and-warn behaviour for un-decodable names.
That rare special application
I guess this is a new definition of rare special application: "an
applicat
On Sat, 6 Dec 2008 at 20:19, [EMAIL PROTECTED] wrote:
On 05:54 pm, [EMAIL PROTECTED] wrote:
On Fri, Dec 5, 2008 at 9:28 PM, <[EMAIL PROTECTED]> wrote:
Whenever someone asks me which version to use, I alwasys respond with
a question -- what do you want to use it for?
In the longer term, I thin
Antoine Pitrou pitrou.net> writes:
>
> > The first is that memoryview is treating the len field in the
> > Py_buffer struct as the number of objects in the view in a few places
> > instead of as the total number of bytes being exposed (it is actually
> > the latter, as defined in PEP 3118).
>
>
Le mardi 09 décembre 2008 à 22:33 +1000, Nick Coghlan a écrit :
> I have zero problem whatsoever if slice assignment TO a memoryview
> object is permitted only if the shape stays the same (i.e. I think that
> issue should be closed as "not a bug").
I'm not even talking about slice /assignment/ her
Antoine Pitrou wrote:
> Alexander Belopolsky gmail.com> writes:
>> I did not follow numpy development for the last year or more, so I
>> won't qualify as "the numpy folks," but my understanding is that numpy
>> does exactly what Nick recommended: the viewed object owns shape and
>> strides just as
Antoine Pitrou wrote:
> Alexander Belopolsky gmail.com> writes:
>> I did not follow numpy development for the last year or more, so I
>> won't qualify as "the numpy folks," but my understanding is that numpy
>> does exactly what Nick recommended: the viewed object owns shape and
>> strides just as
Alexander Belopolsky gmail.com> writes:
>
> I did not follow numpy development for the last year or more, so I
> won't qualify as "the numpy folks," but my understanding is that numpy
> does exactly what Nick recommended: the viewed object owns shape and
> strides just as it owns the data. The v
M.-A. Lemburg wrote:
>
> Well, this is not too far away from just putting the whole decoding
> logic into the application directly:
>
> files = [filename.decode(filesystemencoding, errors='warnreplace')
> for filename in os.listdir(dir)]
>
> (or os.listdirb() if that's where the discuss
* M.-A. Lemburg wrote:
> On 2008-12-09 09:41, Anders J. Munch wrote:
> > On Sun, Dec 7, 2008 at 3:53 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> try:
> files = os.listdir(somedir, errors = strict)
> except OSError as e:
> log()
> files = os.listdir(somedir)
> >
> > I
On 2008-12-09 09:41, Anders J. Munch wrote:
> On Sun, Dec 7, 2008 at 3:53 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
try:
files = os.listdir(somedir, errors = strict)
except OSError as e:
log()
files = os.listdir(somedir)
>
> Instead of a codecs error handler name, how
Antoine Pitrou wrote:
> Nick Coghlan gmail.com> writes:
>> No, you misunderstand what I meant. Py_buffer doesn't need to be changed
>> at all. The *issuing type* would define a new structure with the
>> additional fields, such as:
>
> With to the current buffer API, this is not possible. It's the
Glenn Linderman wrote:
> On approximately 12/8/2008 9:30 AM, came the following characters from
> the keyboard of [EMAIL PROTECTED]:
>> PS: I'd like to see a similar warning issued when an access attempt
>> is made through os.environ to a variable that cannot be decoded.
>
>
> And argv ? Seems l
On Sun, Dec 7, 2008 at 3:53 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
>>> try:
>>> files = os.listdir(somedir, errors = strict)
>>> except OSError as e:
>>> log()
>>> files = os.listdir(somedir)
Instead of a codecs error handler name, how about a callback for
converting bytes to str?
os.listd
32 matches
Mail list logo
