<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 25 September 2016 at 21:18, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank" class="cremed">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Be careful though, comparing these to plain integers should probably<br>
be allowed, </blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">There's a good reason why it's "opaque" ... why would you want to make it less opaque?</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">And I'm curious why Python didn't adopt the fgetpos/fsetpos style that makes the data structure completely opaque (fpos_t). IIRC, this was added to C when the ANSI standard was first written, to allow cross-platform compatibility in cases where ftell/fseek was difficult (or impossible) to fully implement. Maybe those reasons don't matter any more (e.g., dealing with record-oriented or keyed file systems) ...</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">and we also should make sure that things like<br>
serialization via JSON or storing in an SQL database don't break. I<br>
personally think it's one of those "learn not to touch the stove"<br>
cases and there's limited value in making this API idiot proof.<br>
<span class=""><br>
On Sun, Sep 25, 2016 at 9:05 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" class="cremed">ncoghlan@gmail.com</a>> wrote:<br>
> On 26 September 2016 at 10:21, MRAB <<a href="mailto:python@mrabarnett.plus.com" class="cremed">python@mrabarnett.plus.com</a>> wrote:<br>
>> On 2016-09-26 00:21, Ben Leslie wrote:<br>
>>> Are there any downsides to this? I've made some progress developing a<br>
>>> patch to change this functionality. Is it worth polishing and<br>
>>> submitting?<br>
>>><br>
>> An alternative might be a subclass of int.<br>
><br>
> It could make sense to use a subclass of int that emitted deprecation<br>
> warnings for integer arithmetic, and then eventually disallowed it<br>
> entirely.<br>
><br>
> Cheers,<br>
> Nick.<br>
><br>
> --<br>
> Nick Coghlan | <a href="mailto:ncoghlan@gmail.com" class="cremed">ncoghlan@gmail.com</a> | Brisbane, Australia<br>
> ______________________________<wbr>_________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org" class="cremed">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank" class="cremed">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
</span>> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank" class="cremed">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>guido%40python.org</a><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
--Guido van Rossum (<a href="http://python.org/~guido" rel="noreferrer" target="_blank" class="cremed">python.org/~guido</a>)<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" class="cremed">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank" class="cremed">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/pludemann%40google.com" rel="noreferrer" target="_blank" class="cremed">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>pludemann%40google.com</a><br>
</div></div></blockquote></div><br></div></div>