[Numpy-discussion] Removing datetime support for 1.4.x series ?

[Pauli Virtanen]

pe, 2010-02-05 kello 11:09 +0900, David Cournapeau kirjoitti:
[clip]
> I think a py3k buildbot would help for this, right ? Another thing is
> that the py3k changes do not work at all with Visual Studio compilers,
> but that's mostly cosmetic things (like #warning not being supported
> and things like that).

There's a Py3 buildbot at

        http://buildbot.scipy.org/builders/Linux_x86_Ubuntu/builds/319/steps/shell_1/logs/stdio

It also runs 2.4, 2.5 and 2.6 -- the 3.1 results are at the end.

> > Most C code that works on Py2 works also on Py3. Py3 mainly means not
> > using PyString, but choosing between Unicode + Bytes + UString (=Bytes
> > for Py2 & Unicode for Py3). Also, it may be necessary to avoid FILE*
> > pointers in the API (on Py3 those are no longer as easily obtained), and
> > be wary when working with buffers.
> 
> So once the py3k support is in place, should we deprecate those
> functions so that people interested in porting to py3k can plan in
> advance?

For Py3 users APIs with FILE* pointers are somewhat awkward since you
need to dup and fdopen to get FILE* pointers, and remember to fclose the
handles afterward.

> Getting rid of FILE* pointers and file descriptor would also helps
> quite a bit on windows. I know that at some point, there were some
> discussions to make the python C API safe to multiple C runtimes, but
> I cannot find any recent discussion on that fact. I should just ask on
> python-dev, I guess. This would be a great relief if we don't have to
> care about those issues anymore.

Python 3 does have some functions for reading/writing data from PyFile
objects directly, but these are fairly inadequate,

        http://docs.python.org/3.1/c-api/file.html

so I guess we're stuck with the C runtime in any case.

> > I assume the rewrite will be worked on a separate SVN branch? Also, is
> > there a plan yet on what needs changing to make Numpy's ABI more
> > resistant?
> 
> There are two issues:
>  - What we currently means by ABI, that is the ABI for a given python
> version. The main issue is the binary layout of the structures (I
> think the function ordering is pretty solid now, it is difficult to
> change it inadvertently). The only way to fix this is to hide the
> content of those structures, and define the structures in the C code
> instead (opaque pointer, also known as the pimpl idiom). This means a
> massive break of the C API, both internally and externally, but that's
> something that is really needed IMO.
>  - Higher goal: ABI across python versions. This is motivated by PEP
> 384. It means avoiding calls to API which are not "safe". I have no
> idea whether it is possible, but that's something to keep in mind once
> we start a major overhaul.

Making structures opaque is a bit worrying. As far as I understand, so
far the API has been nearly compatible with Numeric. Making the
structures opaque is going to break both our and many other people's
code. This is a bit worrying...

How about a less damaging route: add reserved space to critical points
in the structs, and keep appending new members only at the end? The
Cython issue will probably be mostly resolved by new Cython releases
before the Numpy 2.0 would be out.

-- 
Pauli Virtanen