When compiling with --feature nightly, we now use specialization to optimize extract::<Vec<PrimititeType>>() from an object implementing the buffer protocol.
The symbols are instead kept unresolved, so that they can be used with
any compatible python interpreter, even if the target system uses a
statically linked python and lacks pythonX.Y.so altogether.
We keep the #[link] attributes in #[cfg_attr(windows)] so that we don't require a nightly Rust build on non-Windows platforms.
This can be simplified once RFC 1717 is available in a stable rust version.
This commit also increases the minimum Rust version to 1.13.
Warning: to use rust-cpython with --feature nightly, you now must use 'rustc 1.13.0-nightly (e9bc1bac8 2016-08-24)' or newer; or you'll get segfaults due to the drop flags.
Use of rust-cpython with stable rust is not affected.
* FromPyObject for all conversions that don't need to borrow temporaries
* RefFromPyObject for extracting references out of temporaries
(currently only used for extracting `&str`)
* Introduce py_argparse_parse_plist!() to allow a more flexible
param list syntax.
* py_fn!() syntax changed
* Remove py_method!() / py_class_method!() macros.
These are of limited use when building dynamic types,
and not useful for py_class!() static types.
We now use the generic <DUMMY> hack to avoid duplicate extern "C" symbols.
See rust-lang/rust#26201.
py_module_initializer!() calls now need to manually concatenate the module
name with the prefixes "init" and "PyInit_".
Since the `Python` token no longer is a part of `PyObject`,
lots of methods now require the token as additional argument.
This [breaking-change] breaks everything!
These macros now support specifying an argument list:
`py_fn!(myfn(myarg: i32))`
will expect `myfn` to be a function with the signature:
`fn myfn<'p>(py: Python<'p>, myarg: i32) -> PyResult<'p, _>`
It can called from python as `myfn(1)`
or using keyword arguments: `myfn(myarg=1)`.
If no parameter list is specified (`py_fn!(myfn)`), the expected signature
now includes the keyword arguments:
`fn run<'p>(py: Python<'p>, args: &PyTuple<'p>, kwargs: Option<&PyDict<'p>>)`
Due to the additional `kwargs` argument, this is a [breaking-change].
This is a [breaking-change] and makes the trait more difficult to implement.
The usage through PyObject::extract() is unchanged.
This change allows extracting a `&str` through a temporary `Cow<str>`
without having to copy the string data from python to rust
(at least in cases where the python string is UTF-8 encoded).
This is preparation in hope I'll be able to make py_fn!()
automatically extract the function arguments.
* Add python3-sys to rust-cpython as an optional feature, and
make python27-sys also optional, but still the default
* Parametrise python27-sys/build.rs so that it is python
version independent, and clone it into python3-sys/build.rs.
Hopefully this can continue to be maintained as an identical
file.
* python27-sys and python3-sys gain features for explicitly
selecting a python version to link to. for python27-sys,
there's currently only python27; for python3-sys there's
python 3.4 and 3.5.
* explicitly tell travis to use nightlies (seems to have
started trying to use 1.0.0)
* fix ucs4 build broken by bb13ec
* add utf16 decoding to unicode.from_py_object for
narrow unicode builds
* change unicode narrow/wide cfg flag to be
Py_UNICODE_SIZE_4 not Py_UNICODE_WIDE, which doesn't
appear in sysconfig
* support framework builds on os x
* python27-sys exports compilation flags as cargo vars,
and rust-python resurrects them as cfg flags
* travis runs against local python27-sys
* rust-cpython depends on git python27-sys, because
the one on cargo is now incompatible with it (since bb13ec)
replace PyPtr<'p, PyObject<'p>> with PyObject<'p>
Borrowed python pointers stay &PyObject<'p>.
Note: this means the internal representation of borrowed python pointers
changes from "*mut PyObject" to "&*mut PyObject".
