[Python-Dev] TextIO seek and tell cookies

[Ben Leslie]

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