Re: [Python-ideas] Ideas for improving the struct module

2017-01-20 Thread Nathaniel Smith
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

Re: [Python-ideas] Ideas for improving the struct module

2017-01-20 Thread Nathaniel Smith
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

Re: [Python-ideas] Ideas for improving the struct module

2017-01-20 Thread Elizabeth Myers
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 >>>

Re: [Python-ideas] Ideas for improving the struct module

2017-01-20 Thread Elizabeth Myers
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. > >

Re: [Python-ideas] Ideas for improving the struct module

2017-01-20 Thread Cameron Simpson
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

Re: [Python-ideas] Ideas for improving the struct module

2017-01-20 Thread Paul Moore
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 >

Re: [Python-ideas] Ideas for improving the struct module

2017-01-20 Thread Paul Moore
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

Re: [Python-ideas] Ideas for improving the struct module

2017-01-20 Thread Guido van Rossum
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

Re: [Python-ideas] Ideas for improving the struct module

2017-01-20 Thread Joao S. O. Bueno
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 >>

Re: [Python-ideas] Ideas for improving the struct module

2017-01-20 Thread Elizabeth Myers
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

Re: [Python-ideas] Ideas for improving the struct module

2017-01-20 Thread Elizabeth Myers
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 =

Re: [Python-ideas] Ideas for improving the struct module

2017-01-20 Thread Elizabeth Myers
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

[Python-ideas] Context manager to temporarily set signal handlers

2017-01-20 Thread Thomas Kluyver
Not uncommonly, I want to do something like this in code: import signal # Install my own signal handler prev_hup = signal.signal(signal.SIGHUP, my_handler) prev_term = signal.signal(signal.SIGTERM, my_handler) try: do_something_else() finally: # Restore previous signal handlers