5 ms·

I still don't understand why anyone would want this. It seems pretty hostile to the users of Python without any real benefit. Maybe the benefit is the people wh

by wolfd 7y ago

I still don't understand why anyone would want this. It seems pretty hostile to the users of Python without any real benefit. Maybe the benefit is the people who are pushing for the change get to smugly know that people won't do horrible things with the language. Maybe I don't get it, but... why?

toraobo 7y ago
From the article: > Picking an arbitrary limit less than 232 is certainly safer for many reasons, and very unlikely to impact real usage. We already have some real limits well below 106 (such as if/else depth and recursion limits). > A range of -1,000,000 to 1,000,000 could fit in 21 bits and that three of those values could be packed into a 64-bit word. In theory this could bring security and performance benefits. In practice if you claim to be limited by MAX_UINT you're likely to encounter issues if you try to close to that limit without very careful coding around overflow.
- vallode 7y ago
  Extended reading on this? I found myself chuckling at the absurdity of this at first, and then kept reading finding out that this is actually quite a good idea. What topics would this come under? General compiler architecture?
- m463 7y ago
  If we lowered the speed limit of highways to 25 mph, we would prevent many highway deaths, and could narrow the lanes to fit 4 lanes where previously there were 3 lanes.
allendoerfer 7y ago
Restricting memory usage of Python objects seems like a good idea.
swiley 7y ago
It’s about having a complete specification so that the compiler and VM can be correct. Correctness when you have arbitrarily long input gets complicated very easily. I was originally skeptical when reading, it seemed ridiculous and arbitrary, until I realized that’s what they were going for.
- sitkack 7y ago
  It is not. Python already doesn't have a spec, it has the CPython interpreter. This is repainting the facade while you still have a sump pump that isn't working. There are a myriad of better ways to improve Python and this isn't it.
- matheusmoreira 7y ago
  > Correctness when you have arbitrarily long input gets complicated very easily. Indeed. Accepting arbitrary inputs frequently requires an arbitrary amount of resources. Even if there are no vulnerabilities to exploit, a denial of service attack may still be possible because processing untrusted input can result in massive memory allocations. A concrete example I've recently dealt with: https://github.com/multiformats/unsigned-varint/blob/master/README.md#practical-maximum-of-9-bytes-for-security https://github.com/multiformats/unsigned-varint/blob/master/... These variable length integers may consume an unbounded amount of memory when decoded. I think it's wise to constrain this by default and let the caller increase or turn off the limits if they want: decode(buffer) # max=9, per spec decode(buffer, max=64) decode(buffer, max=math.inf)

by wolfd 7y ago

toraobo 7y ago

From the article: > Picking an arbitrary limit less than 232 is certainly safer for many reasons, and very unlikely to impact real usage. We already have some real limits well below 106 (such as if/else depth and recursion limits). > A range of -1,000,000 to 1,000,000 could fit in 21 bits and that three of those values could be packed into a 64-bit word. In theory this could bring security and performance benefits. In practice if you claim to be limited by MAX_UINT you're likely to encounter issues if you try to close to that limit without very careful coding around overflow.

vallode 7y ago
Extended reading on this? I found myself chuckling at the absurdity of this at first, and then kept reading finding out that this is actually quite a good idea. What topics would this come under? General compiler architecture?
m463 7y ago
If we lowered the speed limit of highways to 25 mph, we would prevent many highway deaths, and could narrow the lanes to fit 4 lanes where previously there were 3 lanes.

allendoerfer 7y ago

Restricting memory usage of Python objects seems like a good idea.

swiley 7y ago

It’s about having a complete specification so that the compiler and VM can be correct. Correctness when you have arbitrarily long input gets complicated very easily. I was originally skeptical when reading, it seemed ridiculous and arbitrary, until I realized that’s what they were going for.

sitkack 7y ago
It is not. Python already doesn't have a spec, it has the CPython interpreter. This is repainting the facade while you still have a sump pump that isn't working. There are a myriad of better ways to improve Python and this isn't it.
matheusmoreira 7y ago
> Correctness when you have arbitrarily long input gets complicated very easily. Indeed. Accepting arbitrary inputs frequently requires an arbitrary amount of resources. Even if there are no vulnerabilities to exploit, a denial of service attack may still be possible because processing untrusted input can result in massive memory allocations. A concrete example I've recently dealt with: https://github.com/multiformats/unsigned-varint/blob/master/README.md#practical-maximum-of-9-bytes-for-security https://github.com/multiformats/unsigned-varint/blob/master/... These variable length integers may consume an unbounded amount of memory when decoded. I think it's wise to constrain this by default and let the caller increase or turn off the limits if they want: decode(buffer) # max=9, per spec decode(buffer, max=64) decode(buffer, max=math.inf)