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(verbose error message that includes somedir and e)
files = os.listdir(somedir)
Instead of a codecs error handler name, how about a callback for
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 like the
Antoine Pitrou wrote:
Nick Coghlan ncoghlan at 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
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(verbose error message that includes somedir and e)
files = os.listdir(somedir)
Instead of a codecs
* 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(verbose error message that includes somedir and e)
files =
Antoine Pitrou wrote:
Alexander Belopolsky alexander.belopolsky at 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
Antoine Pitrou wrote:
Alexander Belopolsky alexander.belopolsky at 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
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 discussion is
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/ here,
Antoine Pitrou solipsis at 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).
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
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 anything
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
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 the
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 system
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
Well, not an
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
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 special
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:
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
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
Nick Coghlan ncoghlan at 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
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
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
Greg Ewing greg.ewing at 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
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 usual
26 matches
Mail list logo
