On 21 January 2017 at 14:51, Nathaniel Smith wrote:
> On Fri, Jan 20, 2017 at 7:39 PM, Nathaniel Smith wrote:
>> [...]
>> Some of these strategies that you might find helpful (or not):
>
> Oh right, and of course just after I hit send I realized I forgot one
> of my favorites!
>
> - come up with
On Fri, Jan 20, 2017 at 7:39 PM, Nathaniel Smith wrote:
> [...]
> Some of these strategies that you might find helpful (or not):
Oh right, and of course just after I hit send I realized I forgot one
of my favorites!
- come up with a real chunk of code from a real project that would
benefit from
On Fri, Jan 20, 2017 at 3:37 PM, Elizabeth Myers
wrote:
[...]
>> Some of the responses on the bug are discouraging... mostly seems to
>> boil down to people just not wanting to expand the struct module or
>> discourage its use. Everyone is a critic. I didn't know adding two
>> format specifiers wa
On 20Jan2017 17:26, Elizabeth Myers wrote:
Some of the responses on the bug are discouraging... mostly seems to
boil down to people just not wanting to expand the struct module or
discourage its use. Everyone is a critic. I didn't know adding two
format specifiers was going to be this controvers
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 like
>>> (length unpacked, (data...))
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.
>
> Fully agree with this.
>
On Jan 20, 2017 12:48 PM, "Elizabeth Myers"
wrote:
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
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.
Fully agree with this.
If the calcsize solution
feels a bit weird (it isn't mu
On 20 January 2017 at 20:47, Elizabeth Myers wrote:
> Two things:
>
> 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. If the calcsize solution
> feels a bit weird (it isn'
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 it.
>
> It feels a bit minor to nee
On 20 January 2017 at 18:18, Guido van Rossum wrote:
> I'd be wary of making a grab-bag of small improvements, it encourages
> bikeshedding.
Agreed. Plus the bikeshedding and debating risks draining Elizabeth's
motivation.
Paul
___
Python-ideas mailing
I'd be wary of making a grab-bag of small improvements, it encourages
bikeshedding.
--Guido (mobile)
On Jan 20, 2017 10:16 AM, "Ethan Furman" wrote:
> On 01/20/2017 10:09 AM, Joao S. O. Bueno wrote:
>
>> On 20 January 2017 at 16:51, Elizabeth Myers wrote:
>>
>
> Should I write up a PEP about th
On 01/20/2017 10:09 AM, Joao S. O. Bueno 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 it.
Yes - maybe a PEP.
I agr
On 20 January 2017 at 15:13, Nathaniel Smith wrote:
> On Jan 20, 2017 09:00, "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
On Jan 20, 2017 09:00, "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 it.
It feels a bit minor to need
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 it.
It feels a bit minor to need a PEP, but having said that did you pick
up
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 packets
>>> with a length field, y
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'\x00\x05hello\x00\x07goodbye\x00\x04test'
> o
On 19/01/17 15: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 your proposal to decode all of message's fields i
On Fri, Jan 20, 2017 at 12:30 AM, Steven D'Aprano wrote:
> Does it require a PEP just to add one more
> format code? (Maybe it will, if the format code requires a complete
> re-write of the entire module.)
Yes, I think a PEP would be useful in this case. The proposed change
*would* entail some fa
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 your proposal to decode all of message's fields in on
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'\x00\x05hello\x00\x07goodbye\x00\x04test'
offset = 0
while offset < len(test_bytes):
... length = s
Nevertheless the C meaning *is* the etymology of the module name. :-)
--Guido (mobile)
On Jan 19, 2017 16:54, "Chris Angelico" wrote:
> On Fri, Jan 20, 2017 at 11:38 AM, Steven D'Aprano
> wrote:
> > On Fri, Jan 20, 2017 at 05:16:28AM +1100, Chris Angelico wrote:
> >
> >> To be fair, the name "
On Fri, Jan 20, 2017 at 11:38 AM, Steven D'Aprano wrote:
> On Fri, Jan 20, 2017 at 05:16:28AM +1100, Chris Angelico wrote:
>
>> To be fair, the name "struct" implies a C-style structure, which
>> _does_ have a fixed size, or at least fixed offsets for its members
>
>
> Ah, the old "everyone thinks
On Fri, Jan 20, 2017 at 05:16:28AM +1100, Chris Angelico wrote:
> To be fair, the name "struct" implies a C-style structure, which
> _does_ have a fixed size, or at least fixed offsets for its members
Ah, the old "everyone thinks in C terms" fallacy raises its ugly head
agan :-)
The name doesn
On Thu, Jan 19, 2017 at 08:31:03AM +, 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 sense variable length, bu
There is now an issue for this:
http://bugs.python.org/issue29328
--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
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 your proposal to decode all of message's fields in one shot.
Which is good.
Not all protocols us
On 2017-01-19 12: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-width formats.
Unfortunately, that's not really true: the Pascal strings
Construct has radical API changes and should remain apart. It feels to me
like a straw-man to introduce a large library to the discussion as
justification for it being too-specialized.
This proposal to me seems much more modest: add another format character
(or two) to the existing set of a dozen
I haven't had a chance to use it myself yet, but I've heard good things
about
https://construct.readthedocs.io/en/latest/
It's certainly far more comprehensive than struct for this and other
problems.
As usual, there's some tension between adding stuff to the stdlib versus
using more specialized
ctypes.Structure is *literally* the interface to the C struct that as Chris
mentions has fixed offsets for all members. I don't think that should
(can?) be altered.
In file formats (beyond net protocols) the string size + variable length
string motif comes up often and I am frequently re-implement
I am for upgrading struct to these, if possible.
But besides my +1, I am writting in to remember folks thatthere is another
"struct" model in the stdlib:
ctypes.Structure -
For reading a lot of records with the same structure it is much more handy than
struct, since it gives one a suitable Pyt
On Fri, Jan 20, 2017 at 5:08 AM, Elizabeth Myers
wrote:
> I do understand it might require a possible major rewrite or major
> changes the struct module, but in the long run, I think it's worth it
> (especially because the struct module is not all that big in scope). As
> it stands, the struct mod
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-width formats.
>>>
>>> Unfortunately, that's not really tr
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
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 sense variable length, but are stored in a fixed-width
field
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 sense variable length, but are stored in a fixed-width
field. The internals of the struct module rely
On Wed, Jan 18, 2017 at 04:24:39AM -0600, Elizabeth Myers wrote:
> 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 byte
+1 on the idea of supporting variable-length strings with the length
encoded in the preceding packed element!
Several months ago I was trying to write a parser and writer of
PostgreSQL's COPY ... WITH BINARY format. I started out trying to implement
it in pure python using the struct module. Due t
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
42 matches
Mail list logo
