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
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
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
>>>
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 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
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
>
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
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
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
>>
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
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 =
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
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
13 matches
Mail list logo