Cython and defines - cython-users

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Cython and defines
Received-SPF: pass (google.com: domain of rober...@gmail.com designates 209.85.212.45 as permitted sender) client-ip=209.85.212.45;
MIME-Version: 1.0
In-Reply-To: <db0f6915-b227-42b6-9893-9d2d49493f39@googlegroups.com>
References: <cf20cd60-a4fa-4ca8-94f6-735fe3f23e60@googlegroups.com>
 <CAGRiapMwea0f0FjOpZHdvh+1Oj0WQ8EB4Eww-hzFE5YEcrv...@mail.gmail.com>
 <CADiQ+QBRWEBxnAfEwy4oGWgXkzHSpdHGZERm84bsaVx5Ynr...@mail.gmail.com>
 <CAGRiapPSjtqW1uFkoOvRpGHw3kMKb+LTsOy2Z8OoWDsrVGR...@mail.gmail.com>
 <CADiQ+QBd934zynXivjqqvM2hSTma3yPVPQ9F0Bdatq1imHk...@mail.gmail.com>
 <CAGRiapNQ0qvu26F2rzDdKiJ8Uo-=KbAssfM=wCz6TLQdad_...@mail.gmail.com>
 <CADiQ+QDooisMACBy_vKYi9vr-+T4wNa86oWmPQQ1we2DhnU...@mail.gmail.com>
 <CAGRiapOOPv3wssCfyr75BgVeC9bR9qyAUQ4YwB4POncHuiK...@mail.gmail.com>
 <61d2b06e-f782-42ca-bf24-640d5ae290df@googlegroups.com> <CADiQ+QCaxhfHHuvYx4WbNY6OM+7xXeJcAK_fWOK=fWuc1Ak...@mail.gmail.com>
 <db0f6915-b227-42b6-9893-9d2d49493f39@googlegroups.com>
From: Robert Bradshaw <rober...@gmail.com>
Date: Wed, 25 Jul 2012 23:29:48 -0700
Message-ID: <CADiQ+QCmAh+-sdmW_MmyUtjFcX0fL90wcMMfhT-n7isePCG...@mail.gmail.com>
Subject: Re: [cython-users] Cython and defines
To: cython-users@googlegroups.com
Content-Type: text/plain; charset=UTF-8

On Tue, Jul 24, 2012 at 6:09 AM, Dan Speed <d...@ccpgames.com> wrote:
> We don't support writing to the runtime resource packages (which is
> prevented by the UAC anyway), so the abstraction would either conceal
> something that's only going to work in some cases (ie. open with mode 'w'
> suddenly throws exceptions once we make a full build), or would remove
> functionality that you need during the development process.

I would consider moving such functionality to a clearly marked
"development-only" module.

> If I see someone using open() in client/server code, I can very quickly
> identify that they're probably doing it wrong. If they use a normal filepath
> in our resfiles, they're also doing it wrong. Obfuscating it merely helps to
> conceal errors in assumption about the environment or a reduction to the
> minimum mutually supported feature set, which are substantive and important.
> Our programmers are paid a salary to have to deal with some of these things.

Fair enough, but as a salaried tool producer and consumer I bet they
wouldn't complain if you made it even easier. :-)

> While I understand your point that abstracting platform specific
> peculiarities away is useful, this is what we do by providing a more limited
> interface that is guaranteed to work correctly on all platforms that is
> clearly the one that you're supposed to use in a particular context, rather
> than having an abstraction with parts that work inconsistently in different
> environments, which you have to wait to have a build to see if it behaves
> correctly in that particular environment.

Clearly I can only speak in abstractions, as I only have scant
information about the project you're working on. I was thinking the
problem you were trying to solve was "My module now looks the same in
all cases to python but can play nice with platform specific
requirements." In particular, I thought you wanted the Python-level
API to map to several possible C APIs (providing the same high-level
behavior) depending on the compile-time environment. This is why I
suggested a C-written shim to allow these decisions to be more easily
and explicitly made at C compile time (and conditionally invoke
functions that only exist on certain platforms).

It sounds like you're trying to do this with your limited interface.

I agree that writing an abstraction that works inconsistently is a
horrible idea. It's almost the definition of leaky and broken.

- Robert
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
