[Python-Dev] TextIO seek and tell cookies (original) (raw)

Ben Leslie benno at benno.id.au
Mon Sep 26 09:10:58 EDT 2016

It was pointed out in private email that technically JSON can represent very large integers even if ECMAScript itself can't.

But the idea of transmitting these offsets outside of a running process is not something that I had anticipated. It got me thinking: is there a guarantee that these opaque values returned from tell() is stable across different versions of Python? My reading of opaque is that it could be subject to change, but that possibly isn't the intent.

It seems that since the sizeof(int) and sizeof(Py_off_t) could be different in different builds of Python even off the same version, then the opaque value returned is necessarily going to be different between builds of even the same version of Python.

It seems like it would be prudent to discourage the sharing of these opaque cookies (such as via a database or interchange formats) as you'd have to be very sure that they would be interpreted correctly in any receiving instance.

Cheers,

Ben

On 26 September 2016 at 02:30, Ben Leslie <benno at benno.id.au> wrote:

I think the case of JSON or SQL database is even more important though.

tell/seek can return 129-bit integers (maybe even more? my maths might be off here). The very large integers that can be returned by tell() will break serialization to JSON, and storing in a SQL database (at least for most database types). What is the value of comparing these to plain integers? Unless you happen to know the magic encoding it isn't going to be very useful I think? Cheers, Ben On 25 September 2016 at 21:18, Guido van Rossum <guido at python.org> wrote: Be careful though, comparing these to plain integers should probably be allowed, and we also should make sure that things like serialization via JSON or storing in an SQL database don't break. I personally think it's one of those "learn not to touch the stove" cases and there's limited value in making this API idiot proof.

On Sun, Sep 25, 2016 at 9:05 PM, Nick Coghlan <ncoghlan at gmail.com> wrote: On 26 September 2016 at 10:21, MRAB <python at mrabarnett.plus.com> wrote: On 2016-09-26 00:21, Ben Leslie wrote:

Are there any downsides to this? I've made some progress developing a patch to change this functionality. Is it worth polishing and submitting?

An alternative might be a subclass of int. It could make sense to use a subclass of int that emitted deprecation warnings for integer arithmetic, and then eventually disallowed it entirely. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org

-- --Guido van Rossum (python.org/~guido)

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/benno%40benno.id.au

More information about the Python-Dev mailing list