confirm if unicode keys are ever populated in the header dictionary about blimpy

[gijzelaerr]

or use .encode() and .decode(), usually works with both py2 and py3.

[gijzelaerr]

So in case of Python2 you want a non unicode string and for python3 you want a bytes? use .encode().

$  python2                                                             
Python 2.7.15rc1 (default, Apr 15 2018, 21:51:34)                      
[GCC 7.3.0] on linux2                                                  
Type "help", "copyright", "credits" or "license" for more information. 
>>> s = 'bla'                                                          
>>> b = b'bla'                                                         
>>> s.encode()                                                         
'bla'                                                                  
>>> s.decode()                                                         
u'bla'                                                                 
>>> b.decode()                                                         
u'bla'                                                                 
>>> b.encode()                                                         
'bla'                                                                  

Python 3.6.6 (default, Sep 12 2018, 18:26:19)
[GCC 8.0.1 20180414 (experimental) [trunk revision 259383]] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> b = b'bla'
>>> s = 'bla'
>>> b.decode()
'bla'
>>> s.encode()
b'bla'

node that you can't encode a string and decode a bytes with python3.

[jeenriquez]

would be great if we can use unicode for all if possible.
we could use .encode('utf-8') instead of 'ascii'
although I guess .fil files only support ascii?

[telegraphic]

I'm ambivalent, but found previously it was easier to force to bytestrings, as these are more similar between Py2 and Py3. In blimpy, we've already forced quite a few things to be bytestrings, so it's probably much more effort to change everything to UTF-8.

Having said that, it would look cleaner if keywords were header['hello'] instead of header[b'hello'], so I won't stop anyone from embarking on a holy crusade against bytestrings should they desire.

[david-macmahon]

I've been staying out of this, but I feel like I have to offer a few cents' worth of opinion... Most (at least 2/3?) of the file types which blimpy takes as input use ASCII text in their headers. Since the dawn of Unicode and UTF-8, I have (mis?)understood that ASCII text is byte-wise identical to the UTF-8 encoding of the equivalent Unicode character sequence. There seems to be a lot of confusion (perhaps only to me?) about how Python 2 vs Python 3 treats strings vs bytes vs character sequences vs byte sequences I think the important thing is that blimpy stays self-consistent internally. By that I mean that however blimpy wants to treat strings internally is basically irrelevant so long as it automatically translates, as necessary, between the external string convention(s) and the internal string convention. Just my $0.02. Dave

…

On Oct 5, 2018, at 23:04, Danny Price ***@***.***> wrote: I'm ambivalent, but found previously it was easier to force to bytestrings, as these are more similar between Py2 and Py3. In blimpy, we've already forced quite a few things to be bytestrings, so it's probably much more effort to change everything to UTF-8. Having said that, it would look cleaner if keywords were header['hello'] instead of header[b'hello'], so I won't stop anyone from embarking on a holy crusade against bytestrings should they desire. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#59 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAslJl3kqCo-oCigjNLAol0Y2q3QiyrJks5uiEfUgaJpZM4XJsCM>.

[gijzelaerr]

it is going to be slightly to massively messy in all cases unless you drop python2 support.

Just my €0.02

[david-macmahon]

I think this is a statement on the impending Pypocalypse [1]. Now I'm up to $0.04, so maybe we're even? :) Dave [1] https://www.reddit.com/r/Python/comments/92zezn/the_apocalypse/

…

On Oct 6, 2018, at 00:13, Gijs Molenaar ***@***.***> wrote: it is going to be slightly to massively messy in all cases unless you drop python2 support. Just my €0.02 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#59 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAslJpVcD_KCa4ggTC5TEtokAEsOhVO_ks5uiFgcgaJpZM4XJsCM>.

[telegraphic]

I'm pretty serious about recompiling Julia to be zero-indexed and rebadging it as Python 4.

[texadactyl]

Occurences of Python encoding, 100% ASCII and only in io/sigproc.py, for better or worse:

./io/sigproc.py:        return np.int32(len(keyword)).tobytes() + keyword.encode('ascii')
./io/sigproc.py:        value = value.encode('ascii')
./io/sigproc.py:        return np.int32(len(keyword)).tobytes() + keyword.encode('ascii') + np.int32(len(value)).tobytes() + value
./io/sigproc.py:    return np.int32(len(keyword)).tobytes() + keyword.encode('ascii') + value_dtype(value).tobytes()

@david-macmahon "I think the important thing is that blimpy stays self-consistent internally."

It is. Let's leave it at that.