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 <be...@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 <gu...@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 <ncogh...@gmail.com> wrote: >>> On 26 September 2016 at 10:21, MRAB <pyt...@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 | ncogh...@gmail.com | Brisbane, Australia >>> _______________________________________________ >>> Python-Dev mailing list >>> Python-Dev@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@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/benno%40benno.id.au _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
