On 20/01/17 17:26, Elizabeth Myers wrote:
> On 20/01/17 16:46, Cameron Simpson wrote:
>> On 20Jan2017 14:47, Elizabeth Myers wrote:
>>> 1) struct.unpack and struct.unpack_from should remain
>>> backwards-compatible. I don't want to return extra values from it
On 20/01/17 16:46, Cameron Simpson wrote:
> On 20Jan2017 14:47, Elizabeth Myers wrote:
>> 1) struct.unpack and struct.unpack_from should remain
>> backwards-compatible. I don't want to return extra values from it like
>> (length unpacked, (data...)) for that reason.
On 20/01/17 10:59, Paul Moore wrote:
> On 20 January 2017 at 16:51, Elizabeth Myers wrote:
>> Should I write up a PEP about this? I am not sure if it's justified or
>> not. It's 3 changes (calcsize and two format specifiers), but it might
>> be useful to codify i
On 20/01/17 10:47, Elizabeth Myers wrote:
> On 19/01/17 20:54, Cameron Simpson wrote:
>> On 19Jan2017 16:04, Yury Selivanov wrote:
>>> This is a neat idea, but this will only work for parsing framed
>>> binary protocols. For example, if you protocol prefixes all pack
On 19/01/17 20:54, Cameron Simpson wrote:
> On 19Jan2017 16:04, Yury Selivanov wrote:
>> This is a neat idea, but this will only work for parsing framed
>> binary protocols. For example, if you protocol prefixes all packets
>> with a length field, you can write an efficient read buffer and
>> use
On 19/01/17 20:40, Cameron Simpson wrote:
> On 19Jan2017 12:08, Elizabeth Myers wrote:
>> I also didn't mention that when you are unpacking iteratively (e.g., you
>> have multiple strings), the code becomes a bit more hairy:
>>
>>>>> test_bytes = b
rk with structs that use
> variable length fields.
Should probably raise an error if the format has a variable-length
string in it. If you're using variable-length strings, you probably
aren't a consumer of struct.calcsize anyway.
>
> Yury
>
>
> On 2017-01-18 5:2
On 19/01/17 06:47, Elizabeth Myers wrote:
> On 19/01/17 05:58, Rhodri James wrote:
>> On 19/01/17 08:31, Mark Dickinson wrote:
>>> On Thu, Jan 19, 2017 at 1:27 AM, Steven D'Aprano
>>> wrote:
>>>> [...] struct already supports
>>>> variable
On 19/01/17 05:58, Rhodri James wrote:
> On 19/01/17 08:31, Mark Dickinson wrote:
>> On Thu, Jan 19, 2017 at 1:27 AM, Steven D'Aprano
>> wrote:
>>> [...] struct already supports
>>> variable-width formats.
>>
>> Unfortunately, that's not really true: the Pascal strings it supports
>> are in some s
Hello,
I've noticed a lot of binary protocols require variable length
bytestrings (with or without a null terminator), but it is not easy to
unpack these in Python without first reading the desired length, or
reading bytes until a null terminator is reached.
I've noticed the netstruct library
(ht
10 matches
Mail list logo
