I agree in almost all points with Robert
On Sat, Sep 12, 2009 at 2:29 PM, Robert
Bradshaw<[email protected]> wrote:
>
> It already does out of necessity.
>
> a = 10
> b = 1000000000000000000000000000
> type(a) == type(b) # depends on the environment
>
Nice example to make your point...
>
> If one always wants bytes, one can do b"something." If one always
> wants unicode, one can do u"something." There's currently no
> (obvious, clean) way to get str.
>
Long ago I've asked to have a s"abc" prefix, were the type match the
Python-side 'str' type.. And I would like to see this working that way
despite any -2 or -3 flags...
> Clearly Dominic has a usecase.
>
> I have a simple usecase too. Often in Sage one has functions like
>
> def charpoly(self, algorithm='default'):
>
> This will break if I run it in Python 3.
The same happens to me in for example petsc4py.. In order to create a
linear solver and select the iterative method, I have to write (in
Python code):
from petsc4py import PETSc
solver = PETSc.KSP().create()
solver.setType("gmres") # this calls C function KSPSetType(KSP ksp,
const char *type_name)
Having to handle the bytes/unicode thing by hand (I mean, using Python
C-API) for such a simple thing is REALLY annoying...
> Specifically would mean we have to get everyone who writes code of
> the above form to use 'u' despite the fact that the existence of
> unicode is *completely* irrelevant to the task at hand.
That the case in all my projects... These codes are not related to
string handling; string are just used for setting a few options and
selecting algorithms, and ALL of them fits in ASCII...
> These are
> just strings, I don't want to have to think about (or, more to the
> point, explain) byte strings, encodings, unicode, etc. unless one is
> actually dealing with byte strings, encodings, etc.
>
Indeed.
> Perhaps the difference in opinion comes from my perspective that, at
> a high level, str just got changed (for the better) in Py3.
>
I second this view. I see Python 3 is a improved language, but not so
radically different to Python 2 as to justify a stricter semantics
adherence to one or another language version...
Moreover, I do consider Cython/Pyrex a new language targeting two
different runtimes: Py2 and Py3. How to handle the slightly different
semantics of these two runtimes? We use a sensible default blesssed
for our BDLF, but let USERS decide with semantics to follow when their
Cython code endup running in a Py2 or Py3 runtime...
>>> import this
...
In the face of ambiguity, refuse the temptation to guess.
Why should Cython enforce which of Py2/Py3 semantics should a *.pyx
file have? That is a just VILE guess from the Cython team...
In short, Cython has to deal with Py2/Py3 runtimes, and they are
different. Please, do not ENFORCE semantics.. Let´s use sensible
defaults but let end users decide what they want/need for getting
their job done...
--
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
