A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2006-November/070045.html below:

[Python-Dev] PyFAQ: thread-safe interpreter operations

[Python-Dev] PyFAQ: thread-safe interpreter operations [Python-Dev] PyFAQ: thread-safe interpreter operationsJason Orendorff jason.orendorff at gmail.com
Mon Nov 27 17:00:57 CET 2006
Way back on 11/22/06, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> Nick Coghlan schrieb:
> > Martin v. Löwis wrote:
> >> I personally consider it "good style" to rely on implementation details
> >> of CPython;
> >
> > Is there a 'do not' missing somewhere in there?
>
> No - I really mean it. I can find nothing wrong with people relying on
> reference counting to close files, for example. It's a property of
> CPython, and not guaranteed in other Python implementations - yet it
> works in a well-defined way in CPython. Code that relies on that feature
> is not portable, but portability is only one goal in software
> development, and may be irrelevant for some projects.

It's not necessarily future-portable either.  Having your software not
randomly break over time is relevant for most nontrivial projects.

> Similarly, it's fine when people rely on the C type "int" to have
> 32-bits when used with gcc on x86 Linux.

Relying on behavior that's implementation-defined in a particular way
for a reason (like int being 32 bits on 32-bit hardware) is one thing.
 Relying on behavior that even the implementors might not be
consciously aware of (or consider important to retain across versions)
is another.

-j
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4