On 2014-01-17 00:28, Stephan Hoyer wrote:
There was a discussion last year about slicing along specified axes in
numpy arrays:
http://mail.scipy.org/pipermail/numpy-discussion/2012-April/061632.html
[1]
I'm finding that slicing along specified axes is a common task for me
when writing code
This thread is getting a little out of hand which is my fault for initially
mixing different topics in one mail, so let me try to summarize:
We have three issues here:
- a loadtxt bug when loading strings in python3
this has nothing to do with encodings or dtypes it is a bug that should be
fixed.
Julian Taylor jtaylor.debian at googlemail.com writes:
[clip]
- inconvenience in dealing with strings in python 3.
bytes are not strings in python3 which means ascii data is either a byte
array which can be inconvenient to deal with or 4 byte unicode which
wastes space.
A proposal to fix
Julian Taylor jtaylor.debian at googlemail.com writes:
[clip]
For backward compatibility we *cannot* change S.
Maybe we could change the meaning of 'a' but it would be safer
to add a new dtype, possibly 'S' can be deprecated in favor
of 'B' when we have a specific encoding dtype.
Note that
On Fri, Jan 17, 2014 at 5:59 AM, Pauli Virtanen p...@iki.fi wrote:
Julian Taylor jtaylor.debian at googlemail.com writes:
[clip]
- inconvenience in dealing with strings in python 3.
bytes are not strings in python3 which means ascii data is either a byte
array which can be inconvenient to
On Fri, Jan 17, 2014 at 10:59:27AM +, Pauli Virtanen wrote:
Julian Taylor jtaylor.debian at googlemail.com writes:
[clip]
- inconvenience in dealing with strings in python 3.
bytes are not strings in python3 which means ascii data is either a byte
array which can be inconvenient to
On Fri, Jan 17, 2014 at 5:59 AM, Pauli Virtanen p...@iki.fi wrote:
Julian Taylor jtaylor.debian at googlemail.com writes:
[clip]
- inconvenience in dealing with strings in python 3.
bytes are not strings in python3 which means ascii data is either a byte
array which can be inconvenient
On Fri, Jan 17, 2014 at 1:44 PM, Oscar Benjamin
oscar.j.benja...@gmail.comwrote:
On Fri, Jan 17, 2014 at 10:59:27AM +, Pauli Virtanen wrote:
Julian Taylor jtaylor.debian at googlemail.com writes:
[clip]
For backward compatibility we *cannot* change S.
Do you mean to say that
On 17/01/14 13:09, Aldcroft, Thomas wrote:
I've been playing around with porting a stack of analysis libraries to
Python 3 and this is a very timely thread and comment. What I
discovered right away is that all the string data coming from binary
HDF5 files show up (as expected) as 'S' type,,
On Fri, Jan 17, 2014 at 2:10 PM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
On Fri, Jan 17, 2014 at 1:44 PM, Oscar Benjamin
oscar.j.benja...@gmail.com wrote:...
...
No latin1 de/encoding is required for anything, I don't know why you would
want do to that in this context.
Does
On Fri, Jan 17, 2014 at 02:10:19PM +0100, Julian Taylor wrote:
On Fri, Jan 17, 2014 at 1:44 PM, Oscar Benjamin
oscar.j.benja...@gmail.comwrote:
On Fri, Jan 17, 2014 at 10:59:27AM +, Pauli Virtanen wrote:
Julian Taylor jtaylor.debian at googlemail.com writes:
[clip]
For
On Fri, Jan 17, 2014 at 8:40 AM, Oscar Benjamin
oscar.j.benja...@gmail.com wrote:
On Fri, Jan 17, 2014 at 02:10:19PM +0100, Julian Taylor wrote:
On Fri, Jan 17, 2014 at 1:44 PM, Oscar Benjamin
oscar.j.benja...@gmail.comwrote:
On Fri, Jan 17, 2014 at 10:59:27AM +, Pauli Virtanen wrote:
On Fri, Jan 17, 2014 at 2:40 PM, Oscar Benjamin
oscar.j.benja...@gmail.comwrote:
On Fri, Jan 17, 2014 at 02:10:19PM +0100, Julian Taylor wrote:
On Fri, Jan 17, 2014 at 1:44 PM, Oscar Benjamin
oscar.j.benja...@gmail.comwrote:
On Fri, Jan 17, 2014 at 10:59:27AM +, Pauli Virtanen
On Fri, Jan 17, 2014 at 03:12:32PM +0100, Julian Taylor wrote:
On Fri, Jan 17, 2014 at 2:40 PM, Oscar Benjamin
oscar.j.benja...@gmail.comwrote:
On Fri, Jan 17, 2014 at 02:10:19PM +0100, Julian Taylor wrote:
no, the right solution is to add an encoding argument.
Its a 4 line patch for
On Fri, Jan 17, 2014 at 10:26 AM, Oscar Benjamin
oscar.j.benja...@gmail.com wrote:
On Fri, Jan 17, 2014 at 03:12:32PM +0100, Julian Taylor wrote:
On Fri, Jan 17, 2014 at 2:40 PM, Oscar Benjamin
oscar.j.benja...@gmail.comwrote:
On Fri, Jan 17, 2014 at 02:10:19PM +0100, Julian Taylor wrote:
On Fri, Jan 17, 2014 at 10:58:25AM -0500, josef.p...@gmail.com wrote:
On Fri, Jan 17, 2014 at 10:26 AM, Oscar Benjamin
oscar.j.benja...@gmail.com wrote:
On Fri, Jan 17, 2014 at 03:12:32PM +0100, Julian Taylor wrote:
You don't show how you created the file. I think that in your case the
17.01.2014 15:09, Aldcroft, Thomas kirjoitti:
[clip]
I've been playing around with porting a stack of analysis libraries
to Python 3 and this is a very timely thread and comment. What I
discovered right away is that all the string data coming from
binary HDF5 files show up (as expected) as
On 17.01.2014 15:12, Julian Taylor wrote:
On Fri, Jan 17, 2014 at 2:40 PM, Oscar Benjamin
oscar.j.benja...@gmail.com mailto:oscar.j.benja...@gmail.com wrote:
On Fri, Jan 17, 2014 at 02:10:19PM +0100, Julian Taylor wrote:
On Fri, Jan 17, 2014 at 1:44 PM, Oscar Benjamin
On Fri, Jan 17, 2014 at 2:18 PM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
On 17.01.2014 15:12, Julian Taylor wrote:
On Fri, Jan 17, 2014 at 2:40 PM, Oscar Benjamin
oscar.j.benja...@gmail.com mailto:oscar.j.benja...@gmail.com wrote:
On Fri, Jan 17, 2014 at 02:10:19PM +0100,
On Fri, Jan 17, 2014 at 1:38 AM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
This thread is getting a little out of hand which is my fault for
initially mixing different topics in one mail,
still a bit mixed ;-) -- but I think the loadtxt issue requires a lot
less discussion, so
numpy.recfromtxt(open('Õscar_3.txt',r, encoding='utf8'),
delimiter=',')
Traceback (most recent call last):
File pyshell#251, line 1, in module
numpy.recfromtxt(open('Õscar_3.txt',r, encoding='utf8'),
delimiter=',')
File C:\Programs\Python33\lib\site-packages\numpy\lib\npyio.py,
On Fri, Jan 17, 2014 at 5:18 AM, Freddie Witherden fred...@witherden.orgwrote:
In terms of HDF5 it is interesting to look at how h5py -- which has to
go between NumPy types and HDF5 conventions -- handles the problem as
described here:
http://www.h5py.org/docs/topics/strings.html
from
On Fri, Jan 17, 2014 at 3:17 PM, Chris Barker chris.bar...@noaa.gov wrote:
numpy.recfromtxt(open('Õscar_3.txt',r, encoding='utf8'),
delimiter=',')
Traceback (most recent call last):
File pyshell#251, line 1, in module
numpy.recfromtxt(open('Õscar_3.txt',r, encoding='utf8'),
Small note:
Being an English speaker I don't normally use non-ascii characters in
filenames but my system (Ubuntu Linux) still uses utf-8 rather than
latin-1 or
(and rightly so!).
just to be really clear -- encoding for filenames and encoding for
file content have nothing to do with
On Fri, Jan 17, 2014 at 12:36 PM, josef.p...@gmail.com wrote:
('S' ?) -- which is probably not what you want particularly if you
specify
an encoding. Though I can't figure out at the moment why the previous one
failed -- where did the bytes object come from when the encoding was
On Fri, Jan 17, 2014 at 4:20 PM, Chris Barker chris.bar...@noaa.gov wrote:
On Fri, Jan 17, 2014 at 12:36 PM, josef.p...@gmail.com wrote:
('S' ?) -- which is probably not what you want particularly if you
specify
an encoding. Though I can't figure out at the moment why the previous
one
On Fri, Jan 17, 2014 at 1:43 PM, josef.p...@gmail.com wrote:
2) Either:
a) open as a binary file and use bytes for anything that doesn't
parse
as text -- this means that the user will need to do the conversion to
text
themselves
b) decode as latin-1: this would work well for
Folks,
I've been blathering away on the related threads a lot -- sorry if it's too
much. It's gotten a bit tangled up, so I thought I'd start a new one to
address this one question (i.e. dont bring up genfromtext here):
Would it be a good thing for numpy to have a one-byte--per-character string
On Fri, Jan 17, 2014 at 4:43 PM, josef.p...@gmail.com wrote:
On Fri, Jan 17, 2014 at 4:20 PM, Chris Barker chris.bar...@noaa.gov
wrote:
On Fri, Jan 17, 2014 at 12:36 PM, josef.p...@gmail.com wrote:
('S' ?) -- which is probably not what you want particularly if you
specify
an
On Fri, Jan 17, 2014 at 5:30 PM, Chris Barker chris.bar...@noaa.gov wrote:
Folks,
I've been blathering away on the related threads a lot -- sorry if it's
too much. It's gotten a bit tangled up, so I thought I'd start a new one to
address this one question (i.e. dont bring up genfromtext
It looks like both recfromtxt and loadtxt are flexible enough to
handle string/bytes en/decoding, - with a bit of work and using enough
information
dtype=[('f0', 'i4'), ('f1', 'i4'), ('f2', 'i4'), ('f3', 'U9')]
data = numpy.recfromtxt(open('Õscar_3.txt',rb), dtype=dtype,
31 matches
Mail list logo
