Changes by Stefan Behnel <stefan...@behnel.de>:
--
keywords: +patch
pull_requests: +3607
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Hi all,
Cython 0.27 is nearing completion, so here's an alpha release to get
feedback on the many new feature that went in.
https://github.com/cython/cython/archive/0.27a1.tar.gz
These are the major new features:
- PEP 484/526 annotation typing
- PEP 525/530 async generators
- automatic
Stefan Behnel added the comment:
I'm working on a PR for this, but after changing all usages and fixing up some
error handling here and there, it results in an interpreter crash for me. I'll
try to debug it during the next days.
--
nosy: +pitrou, serhiy.storchaka
Stefan Behnel added the comment:
One more thing: the fact that the lookup does not propagate exceptions leaves
some space for ambiguity. If, in a chain of MRO lookups, one would fail and a
later one would succeed, is it correct to keep trying? What if the first
failure actually failed to see
New submission from Stefan Behnel:
Follow-up to issue 31336:
The fact that _PyType_Lookup() does not propagate exceptions leaves some space
for ambiguity. If, in a chain of MRO lookups, one would fail and a later one
would succeed, is it correct to keep trying? What if the first failure
Jason H schrieb am 13.09.2017 um 17:54:
> I'm rather surprised that there isn't a Iterable class which dict and list
> derive from.
> If that were added to just dict and list, I think it would cover 98% of
> cases, and adding Iterable would be reasonable in the remaining scenarios.
Would you
Stefan Behnel added the comment:
> Is it correct to call _PyType_Lookup() with an exception set?
The general rule of thumb is that it's not safe to call any user code with a
live exception set, and lookups can call into user code.
I quickly looked through all occurrences (there are
Stefan Behnel added the comment:
Feel free to provide a separate pull request. These issues seem independent of
the exception handling problem that I wrote a fix for.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/i
Changes by Stefan Behnel <stefan...@behnel.de>:
--
keywords: +patch
pull_requests: +3542
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Stefan Behnel:
The "XMLParser.__init__()" method in "_elementtree.c" contains this code:
self->handle_start = PyObject_GetAttrString(target, "start");
self->handle_data = PyObject_GetAttrString(target, "data");
se
Hi!
Current master is starting to feel feature complete for 0.27. If nothing
else is pending, I'll prepare an alpha this weekend to collect some
feedback on the changes we made.
Stefan
___
cython-devel mailing list
cython-devel@python.org
Lukasz Langa schrieb am 11.09.2017 um 21:25:
> I remember mostly Stefan Behnel's concerns about Cython's annotations,
I'm currently reimplementing the annotation typing in Cython to be
compatible with PEP-484, so that concern is pretty much out of the way.
This PEP still has an impact on Cython,
Ryan Gonzalez schrieb am 11.09.2017 um 19:16:
> One thing I want to point out: there are a lot of really useful Python
> libraries that have come to rely on annotations being objects, ranging
> from plac to fbuild to many others. I could understand something that
> delays the evaluation of
Stefan Behnel added the comment:
No, that one was addressed. I think only Victor's comment is still open, that's
why I asked back.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/i
Stefan Behnel added the comment:
Any more comments on the proposed implementation? 13-15% seem worth it to me.
@Victor, or are you saying "PyId, or no change at all"?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.py
Robert Bradshaw schrieb am 06.09.2017 um 08:28:
> On Tue, Sep 5, 2017 at 10:44 PM, Stefan Behnel wrote:
>> Robert Bradshaw schrieb am 06.09.2017 um 07:21:
>>> I'm not a huge fan of behaving differently depending on what syntax
>>> was used to annotate the return t
Robert Bradshaw schrieb am 08.09.2017 um 06:36:
> On Wed, Sep 6, 2017 at 3:53 AM, Stefan Behnel wrote:
>> consider this code:
>>
>> cdef np.ndarray[int32, ndim=1] a
>> a = new_int32_buffer()
>> a = new_float32_buffer()
>>
>> This fails
Stefan Behnel added the comment:
I'm a bit torn on this. On the one hand, it's basically saying, "Cython is
probably going to do it right anyway, so let's just assume it does". That's
nice, and might be applicable to other cases as well. But that also feels like
it could need
Stefan Behnel added the comment:
I was kinda guessing that modifying the slot list wasn't a good idea. ;)
My current use case is that I implement the "create" slot because it makes it
very easy to intercept the spec and its configuration. It is not passed into
"exec"
Stefan Behnel added the comment:
Marcel proposed to disallow main-execution if the extension *might* return
anything but a real object (not only if it actually does), but that seems
excessive to me. The actual problem is that we consider it unsafe if the module
is executed more than once
Stefan Behnel added the comment:
OTOH, if the created "module" is not a module object, then we could argue that
the extension implementation is on its own with that case, and has to do its
own re-execution safety checks.
--
___
Python tr
Stefan Behnel added the comment:
BTW, it seems that Yury's dict copy optimisation would also help here. When I
use a benchmark scenario with a simple non-empty method/attribute dict (from
Cython this time), almost 10% of the creation time is spent copying that dict,
which should essentially
Robert Bradshaw schrieb am 06.09.2017 um 07:21:
> I'm not a huge fan of behaving differently depending on what syntax
> was used to annotate the return type--I'd rather they be 100% aliases
> of each other.
Regarding this bit - I already chose to implement some differences for
annotation typing.
Stefan Behnel added the comment:
Since I'm getting highly reproducible results on re-runs, I tend to trust these
numbers.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Behnel added the comment:
I updated the pull request with a split version of _PyType_Lookup() that
bypasses the method cache during slot updates. I also ran the benchmarks with
PGO enabled now to get realistic results. The overall gain is around 15%.
Original:
$ ./python -m timeit
Stefan Behnel added the comment:
Since the number of applications that get along without any file access is
probably close to irrelevant, "os" and "io" feel like sufficiently widely used
modules to merit being part of a "usual Python startup" bench
Hi all,
since PEP 484 type annotations are scheduled for the next release now, I
wonder if we should take the opportunity to change the defaults for the
exception handling of typed cdef functions.
Currently, if you define a function like this:
cdef int func():
raise ValueError()
It
Stefan Behnel added the comment:
> I would prefer to use the _Py_IDENTIFIER API rather than using
> _PyDict_GetItem_KnownHash().
Do you mean for the table of slot descriptions? I'm not sure that the effect
would be comparable.
> Maybe there are other opportunities for optimization?
Daniel Veillard schrieb am 04.09.2017 um 15:56:
> It's out ! I tagged the release in git and pushed the signed tarball
> and rpms to the usual place:
>
> ftp://xmlsoft.org/libxml2/
>
> This is mostly a a security and bug fixes, most of the credit goes to Nick
> who wrote or reviewed most
Stefan Behnel added the comment:
It's the slot names in "slotdefs". See "update_one_slot()".
The time that is saved is mostly the overhead of calling PyDict_GetItem(). I
actually tried PyDict_GetItemWithError() first, which is faster due to the
lower error handling overhe
Stefan Behnel added the comment:
Comparing against CPython master as of 122e88a8354e3f75aeaf6211232dac88ac296d54
I rebuilt my CPython to get clean results, and that still gave me almost 15%
overall speedup.
Original:
$ ./python -m timeit 'class Test: pass'
2 loops, best of 5: 9.55 usec
Stefan Behnel added the comment:
I literally just ran timeit on "class Test: pass", but I'll see if I can
provide proper numbers.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
New submission from Stefan Behnel:
The method lookup fast path in _PyType_Lookup() does not apply during type
creation, which is highly dominated by the performance of the dict lookups
along the mro chain. Pre-calculating the name hash speeds up the creation of an
empty class (i.e. "
Changes by Stefan Behnel <stefan...@behnel.de>:
--
pull_requests: +3322
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31336>
___
Petr Sumbera schrieb am 30.08.2017 um 14:00:
> anyone seen following error when running Python regression tests? This is
> just with Python 3.5. Pythons 2.7 and 3.4 are ok (I haven't tested Python
> 3.6).
>
> ## running Python regression tests
> TypeError: 'NoneType' object is not callable
>
>
Hi all,
I've uploaded the final 0.26.1 release to PyPI. It fixes several issues
with the last release 0.26. Here is the changelog:
https://github.com/cython/cython/blob/0.26.1/CHANGES.rst
Have fun,
Stefan
PS: I accidentally used the wrong key to sign the files, ID F39A065B. All
files are
Hi,
I'm aware that the current implementation is not final, but I already
adapted the coroutine changes for Cython to allow for some initial
integration testing with real external (i.e. non-Python coroutine) targets.
I haven't adapted the tests yet, so the changes are currently unused and
mostly
Stefan Behnel schrieb am 25.08.2017 um 22:14:
> Hi all,
>
> the release branch still builds ok with Python 3.2, but master doesn't, and
> I'd rather not spend my time on fixing that. Python 3.2 has reached its
> final end-of-life in February 2016, so it's really dead for good
Hi all,
the release branch still builds ok with Python 3.2, but master doesn't, and
I'd rather not spend my time on fixing that. Python 3.2 has reached its
final end-of-life in February 2016, so it's really dead for good now.
https://www.python.org/dev/peps/pep-0392/
I'm not really expecting
Hi all,
I've tagged a release candidate for the 0.26.1 bug fix release. Please give
it some final testing.
https://github.com/cython/cython/archive/0.26.1rc1.tar.gz
Here is the changelog:
https://github.com/cython/cython/blob/0.26.1rc1/CHANGES.rst
Stefan
Robert Bradshaw schrieb am 25.08.2017 um 17:43:
> On Thu, Aug 17, 2017 at 5:18 AM, Stefan Behnel wrote:
>> I think we're ready for a release candidate
>> then, or is there anything still open?
>
> Any updates on this?
Sorry, was heavily occupied with fixing things up for t
Nathaniel Smith schrieb am 16.08.2017 um 09:18:
> On Tue, Aug 15, 2017 at 4:55 PM, Yury Selivanov wrote:
>> Here's the PEP 550 version 2.
> Awesome!
+1
>> Backwards Compatibility
>> ===
>>
>> This proposal preserves 100% backwards compatibility.
>
> While this is mostly true
Stefan Behnel schrieb am 02.08.2017 um 11:44:
> Given the current set of bugs and regressions in 0.26, I think we should
> start preparing a 0.26.1 release. I've already updated the release branch
> with recent fixes. It's currently the same as master, but I'd like to
> separate the b
Stefan Behnel schrieb am 02.08.2017 um 11:44:
> Given the current set of bugs and regressions in 0.26, I think we should
> start preparing a 0.26.1 release. I've already updated the release branch
> with recent fixes. It's currently the same as master, but I'd like to
> separate the b
Soni L. schrieb am 08.08.2017 um 01:56:
> On 2017-08-07 08:35 PM, Steven D'Aprano wrote:
>> Hi Soni, and welcome!
>>
>> On Mon, Aug 07, 2017 at 04:30:05PM -0300, Soni L. wrote:
>>
>>> What if, (x for x in integers if 1000 <= x < 100), was syntax sugar
>>> for (x for x in range(1000, 100))?
Stefan Behnel added the comment:
Regarding the user side of the problem, you might(!) be able to work around the
crash by merging nested if-conditions into and-expressions if they have no
elif/else. That's also why the split into multiple files doesn't help, it's the
depth of the nesting
Stefan Behnel added the comment:
I've looked at the file and it contains a huge amount of deeply nested
if-statements. Given that parsers and compilers are typically recursive, I can
well imagine that this is a problem, and my guess is that it's most likely just
the different C level stack
Stefan Behnel added the comment:
Wouldn't this be a typical case where we'd expect a module to evolve and gain
usage on PyPI first, before adding it to the stdlib?
Searching for "grapheme" in PyPI gives some results for me. Even if they do not
cover what this ticket asks for, they
Am 3. August 2017 20:10:14 MESZ schrieb Matthew Brett:
>OK - I have set that up, wheels building on the "daily" branch here:
>
>https://travis-ci.org/MacPython/cython-wheels/branches
Nice.
>But, I'm a bit worried by the pre-release naming scheme, because the
>built wheel has name of form
Ian Henriksen schrieb am 03.08.2017 um 18:16:
> On Thu, Aug 3, 2017 at 10:05 AM Matthew Brett wrote:
>> On Thu, Aug 3, 2017 at 2:12 PM, Andy wrote:
>>> One more thing: If there was a nightly wheel like for scipy and numpy,
>>> we could run CI with Cython master. That might lead to finding issues
Stefan Behnel added the comment:
1) Is this reproducible?
2) Getting a crash in compile.c indicates that this is happening at
parse/compile time and not when your Python code is executing. Can you confirm
that? Does it generate a .pyc file on import that would indicate a successful
byte code
Stefan Behnel added the comment:
Looks like the switch from PyObject_IsSubclass() to PyType_IsSubtype() was made
during the original Py3 development cycle. It should thus be safe to assume
that the semantics are "as designed". :)
What about applying the patch also to 3.6
New submission from Stefan Behnel:
PyObject *exception, *value, *tb;
PyErr_Fetch(, , );
/* PyObject_IsSubclass() can recurse and therefore is
not safe (see test_bad_getattr in test.pickletester). */
res = PyType_IsSubtype((PyTypeObject *)err, (PyTypeObject
Ben Finney schrieb am 31.07.2017 um 04:24:
> You might be looking for a different compiler, maybe one which compiles
> not to Python byte code but instead to CPU machine code. There isn't
> such a thing;
The Python wiki lists several compilers for Python, although with varying
levels of language
Ben Finney schrieb am 25.07.2017 um 08:34:
> Ethan Furman writes:
>
>> Something like:
>>
>> try:
>>
>> except ZeroDivisionError as dead_exc:
>> exc = dead_exc
>>
>>
>> print(text_template.format(exc=exc)
>
> That strikes me as busy-work;
Stefan Behnel added the comment:
This has been resolved by PEP 489, issue 24268.
The module initialisation process receives the complete ModuleSpec now,
starting with CPython 3.5, and can do with it whatever it likes, before
executing any user code.
--
resolution: -> duplicate
st
Hi all!
Here's a question to cython-users. Is anyone of you using the "public"
modifier to export symbols to external code? And are you calling the module
init function from them directly, e.g. when embedding a Cython module in a
C/C++ application? I'd like to get some feedback on how people use
Stefan Behnel added the comment:
FYI, I've finally managed to find the time for implementing PEP 489 style
module initialisation in Cython. It was so easy that I'm sorry it took me so
long to get started. Cython 0.26 is fresh out, so the feature should go into
0.27.
https://github.com/cython
Nick Coghlan schrieb am 21.07.2017 um 08:23:
> I'll also note that in these cases where the import overhead is
> proportionally significant for always-imported modules, we may want to look
> at the benefits of freezing them (if they otherwise remain as pure Python
> modules), or compiling them as
Robert Bradshaw schrieb am 20.07.2017 um 08:07:
> The release is out. Thanks everyone for the feedback on and off list.
Thanks, Robert, for preparing it and fixing and reviewing heaps of bugs and
code along the way.
Stefan
___
cython-devel mailing list
Ivan Levkivskyi schrieb am 20.07.2017 um 13:24:
> I agree the start-up time is important. There is something that is related.
> ABCMeta is currently implemented in Python.
> This makes it slow, creation of an ABC is 2x slower than creation of a
> normal class.
> However, ABCs are used by many
Robert Bradshaw schrieb am 16.07.2017 um 01:19:
> On Sat, Jul 15, 2017 at 2:44 AM, Jeroen Demeyer wrote:
>> Do you intend to do something about the speed regression due to
>> https://github.com/cython/cython/pull/1719
>>
>> I'm happy with a yes/no answer just to know what to expect.
>>
> Had a
Stefan Behnel added the comment:
> Are all uses of internal CPython details optional?
Well, what classifies as a "CPython detail" sometimes just becomes clear when
other implementations don't have it. ;-)
But yes, the C code that Cython generates selects alternative implement
Stefan Behnel added the comment:
For future reference, this change is supported by Cython 0.26 (which is
currently close to release).
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Victor Stinner schrieb am 11.07.2017 um 12:19:
> Split the ``Include/`` directory of CPython:
>
> * ``python`` API: ``Include/Python.h`` remains the default C API
> * ``core`` API: ``Include/core/Python.h`` is a new C API designed for
> building Python
> * ``stable`` API:
Stefan Behnel added the comment:
Sorry for not responding, missed the message, it seems.
Cython has to support old-style relative imports also in Py3 because that's how
the user code was originally written, using Py2-style syntax and semantics.
Most Cython code has not been converted to Py3
Adrien Guinet schrieb am 17.06.2017 um 11:39:
> As everyone is making his "wishlist" for the next Cython release, I
> think it could be nice if https://github.com/cython/cython/pull/1607
> (Pythran support for Numpy operation) could be integrated. I just pushed
> a commit that makes the usage
Stefan Behnel added the comment:
Can the PR be applied then? It looks good to me.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Robert Bradshaw schrieb am 12.06.2017 um 19:35:
> On Sat, Jun 10, 2017 at 10:34 AM, Julian Rüth wrote:
>> some people over at conda-forge would like to use features that are
>> already in master but have not been released yet
>> (https://github.com/conda-forge/cython-feedstock/pull/20). We would
Stefan Behnel added the comment:
I do not see this as a matter of performance but as a matter of usability.
Basically, CPython could do just fine with just a single catch-all calling
convention that packs all pos/kw arguments into C arguments and passes them
over, leaving it entirely
Serhiy Storchaka schrieb am 11.06.2017 um 07:11:
> 10.06.17 15:54, Steve D'Aprano пише:
>> Larry Hastings is working on removing the GIL from CPython:
>>
>> https://lwn.net/Articles/723949/
>>
>> For those who don't know the background:
>>
>> - The GIL (Global Interpreter Lock) is used to ensure
Serhiy Storchaka schrieb am 03.06.2017 um 18:25:
> Yet about braces. PEP 7 implicitly forbids breaking the line before an
> opening brace. An opening brace should stay at the end the line of the
> outer compound statement.
>
> if (mro != NULL) {
> ...
> }
> else {
>
Stefan Behnel added the comment:
I looked up this change again and was surprised that it still wasn't applied.
It feels to me that it makes sense already for reasons of consistency. Any time
frame for changing it? I'd like to use METH_FASTCALL in Cython in a
future-proof way
New submission from Stefan Behnel:
I'm seeing doctest failures in Cython's test suite with Py3.7 due to the change
of an error message:
Failed example:
func1(arg=None)
Expected:
Traceback (most recent call last):
...
TypeError: func1() takes no keyword arguments
Got
Stefan Behnel added the comment:
Patch replaced by pull request.
https://github.com/python/cpython/pull/1823
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Stefan Behnel <sco...@users.sourceforge.net>:
Removed file: http://bugs.python.org/file46906/lxml_elpath_empty_prefix.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Stefan Behnel added the comment:
Agreed that this should be added. I think the key should be None, though, not
the empty string. I attached a quick patch for lxml's corresponding file. It's
mostly the same for ET.
--
keywords: +patch
Added file: http://bugs.python.org/file46906
Stefan Behnel added the comment:
Thanks for bringing me in. The PoC implementation looks nice. Whether I'd like
to support this in Cython? Absolutely. Requires some work, though, since Cython
still doesn't implement PEP 489. But it shouldn't be hard, if I remember the
discussions from back
Stefan Behnel added the comment:
Looks good to me (didn't test it).
Note that getchildren() is not deprecated in lxml because it's actually the
fastest way to build a list of the children. It's faster than list(element)
because it avoids the Python (C-level) iteration overhead. However
Hi all!
Adrien Guinet implemented a Pythran backend for NumPy array operations in
Cython.
https://github.com/cython/cython/pull/1607
I'm forwarding his explanations to cython-users as I really like this as a
feature and would like to get some feedback by some more people to make
sure it works
Hi!
Germany has three major Python events planned this year:
- PyCon-Web in München (May 27-28th)
- Python-Camp in Köln (April 8-9th)
- PyCon-DE in Karlsruhe (October, dates TBA).
http://pyconweb.org/
https://python-verband.org/informieren/events/pythoncamp-2017
Stefan
Stephane Wirtel via
Stefan Behnel added the comment:
Thanks for asking. Cython doesn't use METH_FASTCALL yet, so this doesn't
introduce any problems.
Generally speaking, if Cython generated user code stops working with a new
CPython version, we expect people to regenerate their code with the newest
Cython
Stefan Behnel added the comment:
I'm ok with the deprecations.
Regarding the cElementTree module, this is a bit problematic. The idiomatic
import has lost its use in Py2.5 when ET and cET were added to the stdlib, so
code that was written for Py2.5 or later (e.g. because it uses generators
Stefan Behnel added the comment:
Actually, it seems that calling urlcleanup() is sufficient as a work-around.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Behnel added the comment:
This bug makes the installation of lxml fail on many systems (especially MacOS)
when pip installs from sources, because it tries to download its library
dependencies from FTP and crashes due to the FTP "error". I guess the current
fix is to not
Robert Bradshaw schrieb am 05.01.2017 um 19:12:
> On Thu, Jan 5, 2017 at 2:31 AM, Stefan Behnel wrote:
>> Robert Bradshaw schrieb am 04.01.2017 um 07:46:
>>> By default a cdef (or cpdef) function returning C type suppresses all
>>> exceptions, which is quite surpri
Hi Robert!
Robert Bradshaw schrieb am 04.01.2017 um 07:46:
> By default a cdef (or cpdef) function returning C type suppresses all
> exceptions, which is quite surprising to new (and old) users, and
> makes debugging difficult. I would propose that we make exception
> propagation the default.
>
Hi!
Sayth Renshaw schrieb am 20.12.2016 um 12:53:
> I have been trying to get a script to work on windows that works on mint. The
> key blocker has been utf8 errors, most of which I have solved.
>
> Now however the last error I am trying to overcome, the solution appears to
> be to use the
Hi Matti!
Matti Picus schrieb am 24.11.2016 um 06:48:
> I am trying to get cython to work better with PyPy. I am sort of documenting
> my
> progress and failures at
> https://bitbucket.org/pypy/pypy/wiki/edit/cpyext_2_-_cython
Thanks for working on that.
> So far I can run the test suite on
Peter Otten schrieb am 19.09.2016 um 14:55:
> In [7]: %%cython
> def omega(int n):
> cdef long i
> cdef long result = 0
> for i in range(n): result += i
> return result
>...:
>
> In [8]: %timeit omega(10)
> 1 loops, best of 3: 91.6 µs per loop
Note that this is the
אלעזר schrieb am 19.09.2016 um 17:59:
> If at all, it should be function.bind(). It was discussed and dropped; I
> don't remember why, but one problem is that it looks like an in-place
> modification.
IMHO, the main drawback of that solution is that it only works for
functions and not for any
Stefan Behnel schrieb am 10.09.2016 um 11:45:
> Robert Bradshaw schrieb am 09.09.2016 um 10:11:
>> I'd like to put out another Cython release shortly. Is anyone aware of
>> anything that we should try to get in before then?
>
> I'm seeing these test failures in travis under l
Stefan Behnel added the comment:
Removing HAVE_LONG_LONG entirely causes breakage of third party code that uses
this macro to enable PY_LONG_LONG support. Could you please always define it
instead of removing it?
--
nosy: +scoder
___
Python tracker
Stefan Behnel added the comment:
Raymond, you might have meant me when assigning the ticket and not Stefan Krah,
but since I'm actually not a core dev, I can't commit the patch myself.
See my last comment, though, I reviewed the patch and it should get committed
Robert Bradshaw schrieb am 09.09.2016 um 10:11:
> I'd like to put out another Cython release shortly. Is anyone aware of
> anything that we should try to get in before then?
I'm seeing these test failures in travis under latest Py3.6 now. Does
anyone have a quick idea what might cause them?
Stefan Behnel added the comment:
Definitely not a bug since this isn't required by the XML spec. As said in
issue 2647, you shouldn't rely on exact lexical characteristics of an XML byte
stream, unless you request canonical serialisation (C14N
Robert Bradshaw schrieb am 09.09.2016 um 10:11:
> I'd like to put out another Cython release shortly.
Exactly my thoughts.
The next release could use some extra good testing as I reworked some of
the fused-/cy-function internals last month and might not have found all
kinds of code that could
Erik Bray schrieb am 25.04.2016 um 17:18:
> As some of you already know I've been doing some work on Cython on
> Cygwin [in the process I I'm constantly mixing the two up in speech,
> but maybe in writing I'll do better :)].
>
> There are several issues with the tests on Cygwin, and that's one
>
Stefan Behnel added the comment:
Let's close this as outdated. New bugs for the new project should be reported
in github anyway.
--
resolution: -> out of date
status: open -> closed
___
Python tracker <rep...@bugs.python.o
Stefan Behnel added the comment:
> By the way, I'm surprised that the special encoding "unicode" relies on the
> *current* locale encoding when the XML declaration is requested.
That seems a weird choice. Since it serialises to a Unicode string, it
shouldn't have any XML de
901 - 1000 of 7113 matches
Mail list logo
