Stefan Behnel added the comment:
IMHO, it makes sense to support this. My intuition tells me that lxml also
handles this as expected, by accident through iteration.
Not sure how to do this correctly in ET, though. Special case dict? Or special
case OrderedDict? Both would leave some
Stefan Behnel added the comment:
> My intuition tells me that lxml also handles this as expected, by accident
> through iteration.
And, obviously, it doesn't. It sorts, too. :)
I'm ok with switching for both libraries.
--
___
Pytho
New submission from Stefan Behnel:
in the XMLPullParser ticket
http://bugs.python.org/issue17741
specifically here:
http://bugs.python.org/msg196177
it says:
"""
* [The pull parser] will *not* accept a "parser" argument in the constructor.
Rationale: the parser
Changes by Stefan Behnel :
--
nosy: +eli.bendersky, scoder
___
Python tracker
<http://bugs.python.org/issue9521>
___
___
Python-bugs-list mailing list
Unsub
Stefan Behnel added the comment:
When you write "XML PI", do you mean the XML declaration? At least that's what
Mark used in his original example.
ET avoids writing them out when they are not necessary, i.e. for UTF-8
compatible encodings. IMHO that's perfectly ok a
Stefan Behnel added the comment:
> As for backwards compatibility: yes, this is a concern. The keyword argument
> would be a solution. On the other hand, I'm not sure that the default should
> be something that causes dataloss...?
It's a matter of use cases. How often
Stefan Behnel added the comment:
> Unless there are objections, I'll try to work on a patch that either
> documents that PIs are lost, or optionally adds them to the tree when parsing
> (depending on how difficult that turns out to be).
Please do. It should not be difficult at a
Stefan Behnel added the comment:
Yes, the situation didn't change.
--
___
Python tracker
<http://bugs.python.org/issue17159>
___
___
Python-bugs-list m
Stefan Behnel added the comment:
I stumble over this because I had already adapted our doctests in Cython to the
changed Py3.4 behaviour, so they started failing now because the automatic
signature extraction was essentially reverted in CPython.
I had started to consider it a feature that
Stefan Behnel added the comment:
LGTM, thanks!
And works nicely with Cython:
"""
import inspect
def test_isfunction():
"""
>>> test_isfunction()
True
"""
return inspect.isfunction(test_isfunction)
def test_sig
Stefan Behnel added the comment:
pretty please? :)
--
___
Python tracker
<http://bugs.python.org/issue17159>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
Tried it, works for me.
Explicitly rejecting classes is a good idea, IMHO, as is requiring that any
function-like object must be callable, obviously.
--
___
Python tracker
<http://bugs.python.org/issue17
Stefan Behnel added the comment:
Thanks a lot!
--
___
Python tracker
<http://bugs.python.org/issue17159>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
Hmm, I now notice that I was mistaken about this working:
'''
import inspect
def test_isfunction():
"""
>>> test_isfunction()
True
"""
return inspect.isfunction(test_isfunction)
'
Stefan Behnel added the comment:
> I'm not sure I like the idea that Cython functions are "chimeras" of
> some sort, i.e. they have a type of python builtin functions, hence,
> logically, Signature.from_builtin should work on them (and they have to
> follow __text_s
Stefan Behnel added the comment:
Attached is a minimal patch that does what I think you meant.
--
Added file: http://bugs.python.org/file33846/divert_from_builtin.patch
___
Python tracker
<http://bugs.python.org/issue17
Stefan Behnel added the comment:
I tried the third patch and it works, but when I write this into a docstring:
def func(x, *, y=None):
"""sig=(a,b)"""
then it fails to extract the signature again and returns (a,b) instead.
I also tried putting in so
Stefan Behnel added the comment:
I tried this in Cython and ISTM that the C level parser is a bit too forgiving:
def sig(a, b):
"""sig=(a*b)"""
return a * b
--
___
Python tracker
<
Stefan Behnel added the comment:
> I assumed that anything that had a __text_signature__ wasn't going
> to have any other kind of signature information. Therefore, if the
> object had a __text_signature__ attribute, then I already knew that's
> the best approach and i
Stefan Behnel added the comment:
Ok, I think I figured it out now.
Essentially, Cython's functions type, despite starting with the same struct
layout as PyCFunction, must not visibly inherit from PyCFunction. Consequently,
inspect.isbuiltin() returns False, as does inspect.isfun
Stefan Behnel added the comment:
> Also, PEP 8 forbids using annotations in the CPython library, which
> includes all of CPython's builtins. So using annotations in any way
> for this was off the table.
Interesting, wasn't aware of that. Then let's wait what will
Stefan Behnel added the comment:
>> inspect.isbuiltin() returns False
> Are you absolutely sure about this?
Yes. The "inheritance" of Cython's function type from PyCFunction is a pure
implementation detail of the object struct layout that is not otherwise
visible in any
Stefan Behnel added the comment:
> What "existing function introspection API"? I wasn't aware there was an
> existing mechanism to provide signature metadata for builtin functions.
Not for builtin functions, but it's unclear to me why the API of builtin
functions sho
Stefan Behnel added the comment:
Python 3.4.0b3+ (default:19d81cc213d7, Feb 1 2014, 10:38:23)
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def test(a,b,c=None): pass
>>> set(dir(t
Stefan Behnel added the comment:
"""
>>> test.__code__.co_varnames
()
>>> test.__code__.co_varnames
()
>>> test.__code__.co_varnames
('a', 'b', 'c')
"""
copy&pasto, please ignore the first two... :o)
Stefan Behnel added the comment:
> [...] a "builtin code object" (PyCFunctionObject) [...] doesn't have any of
> the metadata you cited.
That exactly is the bug.
I think we should take the further discussion offline, or mov
Stefan Behnel added the comment:
> I understand Stefan to (reasonably) want 1 api instead of 2.
Absolutely. However, I guess the underlying reasoning here is that there
are other callables, too, so it's not worth making just two kinds of them
look the same, even if both are functions
Changes by Stefan Behnel :
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue20485>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
>>> inspect.isbuiltin() returns False
>> Are you absolutely sure about this?
> Yes.
Oh, well...
isbuiltin(cyfunction) *does* return False. However,
ismethoddescriptor(cyfunction) returns True, because Cython's functions bind as
Stefan Behnel added the comment:
BTW, ismethoddescriptor() is an exceedingly broad test, IMHO. I wonder if it
should even be relied upon for anything in inspect.py.
--
___
Python tracker
<http://bugs.python.org/issue17
Stefan Behnel added the comment:
> Since this is a problem in Cython, not in CPython, maybe you can fix it in
> Cython?
I'm actually considering that. Now that Signature.from_function() allows
function-like types, it appears like it's the easiest solution to add a
"__sig
Stefan Behnel added the comment:
> Oh, sound like a big hack.
Well, it's certainly a bunch of overhead (even assuming that "inspect" will
most likely be imported already - just looked it up in import.c, there's
lots of useless generic code there), with a lot of potent
Changes by Stefan Behnel :
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue20632>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
I tested it and it works, so I could take the simple route now and say "yes, it
fixes the problem", but it's actually no longer required because I already
added a "__signature__" property to Cython's functions. However, as Yury
Stefan Behnel added the comment:
My latest status is that a decision on the future of the "parser" argument is
still pending. See #20219.
It's correctly deprecated in the sense that passing any previously existing
parser isn't going to be supported anymore, but passing an
New submission from Stefan Behnel :
Here's a simple coroutine that works perfectly in Python 2.6 but seems
to let Py3.1 enter an infinite loop that ends up eating all memory.
-
def printing_sink():
"A simple sink that prints the received values."
Stefan Behnel added the comment:
Hmm, ok, so this is actually an anticipated bug? And I assume this has
been discussed before and was decided to get solved by doing... what?
Is it documented somewhere why this happens and what one must avoid to
not run into this kind of pitfall
Changes by Stefan Behnel :
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue6673>
___
___
Python-bugs-list mailing list
Unsubscri
Stefan Behnel added the comment:
Very good argumentation, thanks Nick!
I think this is worth being fixed in the 3.1 series.
--
___
Python tracker
<http://bugs.python.org/issue6
New submission from Stefan Behnel :
Running the Cython compiler under Python 3.1.1 and 3.2 (SVN) corrupts
PyThreadState->exc_value by leaving a dead reference. Printing the value
then leads to a crash.
This bug is about plain Python code, no Cython built extension modules
involved.
Steps
Stefan Behnel added the comment:
I should add that the crash doesn't necessarily happen during the first
test run, which also converts the Cython source to Py3 using 2to3.
However, once that's done, running the test a second time crashe
Stefan Behnel added the comment:
I hadn't, but it looks like the 2to3-ed Cython also runs on 3.0 now, so
I tested that, but I failed to get the procedure below to crash for me.
And that's both in 3.0 *and* 3.1.1! :-/
But I can still provoke the crash in 3.0, 3.0.1, 3.1.1 and the
Stefan Behnel added the comment:
The patch is supposed to apply near the end of the class
TreeAssertVisitor at the end of the file Cython/TestUtils.py, not in the
class NodeTypeWriter.
And the test doesn't run (or even import) the extension, it just buil
New submission from Stefan Behnel :
PyUnicode_FromEncodedObject() currently calls PyObject_AsCharBuffer() to
get the buffer pointer and length of a buffer supporting object. It
should be changed to support the buffer protocol correctly instead.
I filed this as a crash bug as the buffer protocol
New submission from Stefan Behnel :
When compiling a C extension (lxml in this case) in Py3.1, calling the
"build_ext -i" distutils target duplicates the package path when writing
the dynlib. In this case, I get "lxml/lxml/etree.so" instead of
"lxml/etree.so". O
Stefan Behnel added the comment:
I actually am no longer interested (after 5 years), but if the patch solves the
problem, it'd be good to apply it. Lacks a docs patch, though.
--
___
Python tracker
<http://bugs.python.org/issu
New submission from Stefan Behnel :
Subject says it all:
Python 2.7 (r27:82500, Jul 5 2010, 13:37:06)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.etree.ElementTree as ET
&
Changes by Stefan Behnel :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue9375>
___
___
Python-bugs-list mailing list
Unsubscri
Stefan Behnel added the comment:
The parser actually starts with this code:
def iterfind(elem, path, namespaces=None):
# compile selector pattern
if path[-1:] == "/":
path = path + "*" # implicit all (FIXME: keep this?)
IMHO, the 'F
Changes by Stefan Behnel :
--
nosy: +effbot, flox
___
Python tracker
<http://bugs.python.org/issue9375>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
I think it makes sense to keep input and output separate. After all, the part
of the software that outputs a document doesn't necessarily know how it came
in, so having the default output encoding depend on the input sounds error
prone. Encoding should a
Stefan Behnel added the comment:
I would suggest fixing the tostring() behaviour also in a future 3.1.x bug fix
release. After all, the current behaviour means that 3.0 and 3.1 would behave
different from any other (released or future) Python version here
Changes by Stefan Behnel :
--
nosy: -scoder
___
Python tracker
<http://bugs.python.org/issue4617>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 use
Stefan Behnel added the comment:
Actually, it seems that calling urlcleanup() is sufficient as a work-around.
--
___
Python tracker
<http://bugs.python.org/issue27
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 gener
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 newe
Stefan Behnel added the comment:
Etree patch looks straight forward to me, feel free to apply it.
--
___
Python tracker
<http://bugs.python.org/issue25
Stefan Behnel added the comment:
Here is a proposed patch for a new function "strip_namespaces(tree)" that
discards all namespaces from tags and attributes in a (sub-)tree, so that
subsequent processing does not have to deal with them.
The "__all__" test is failing (have
Stefan Behnel added the comment:
On second thought, I think it should be supported (also?) in the parser.
Otherwise, using it with an async parser would be different from (and more
involved than) one-shot parsing. That seems wrong.
--
___
Python
New submission from Stefan Behnel:
I noticed that quite some time during number formatting is spent parsing the
format spec. The attached patch speeds up float formatting by 5-15% and integer
formatting by 20-30% for me overall when using f-strings (Ubuntu 16.04, 64bit).
--
components
Stefan Behnel added the comment:
You can easily see it by running timeit on fstrings, e.g. patched:
$ ./python -m timeit 'f"{34276394612:15}"'
100 loops, best of 3: 0.352 usec per loop
$ ./python -m timeit 'f"{34.276394612:8.6f}"'
100 loops, best
Changes by Stefan Behnel :
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue27128>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Behnel :
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue27810>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
I agree that this would be cool. There is a tiny bit of a backwards
compatibility concern as the new function signature would be incompatible with
anything we had before, but I would guess that any code that chooses to bypass
PyObject_Call() & friends woul
Stefan Behnel added the comment:
Extensive callback interfaces like map() come to mind, where a large number of
calls becomes excessively time critical and might thus have made people
implement their own special purpose calling code.
However, I don't know any such code (outside of Cython
Stefan Behnel added the comment:
FYI: I copied your (no-kwargs) implementation over into Cython and I get around
17% faster calls to Python functions with 2 positional arguments.
--
___
Python tracker
<http://bugs.python.org/issue27
Stefan Behnel added the comment:
> What do you mean by "I copied your (no-kwargs) implementation"?
I copied what you committed into CPython for _PyFunction_FastCall():
https://github.com/cython/cython/commit/8f3d3bd199a3d7f2a9fdfec0af57145b3ab363ca
and then enabled its usage i
Stefan Behnel added the comment:
I like the oneArg/noArg etc. macros. We use something similar in Cython. You
can even use them to inline the METH_O and METH_NOARGS call cases (although I
use inline functions for that in Cython).
--
___
Python
Stefan Behnel added the comment:
I just took a quick look at the fastcall_kwargs-2.patch for now. It looks ok in
general, but it also adds quite some special code for the dict-to-locals
mapping. Is the keyword argument calling case really that important? I mean, it
requires creating a dict
Stefan Behnel added the comment:
If you care so much about C stack space, you could also try to create two or
three entry point functions that keep (say) a 4, 8 and 16 items array on the
stack respectively, and then pass the pointer (and the overall length if you
need it) of that array on
New submission from Stefan Behnel:
The current documentation says:
"""
PyObject* PyUnicode_Format(PyObject *format, PyObject *args)
Return value: New reference.
Return a new string object from format and args; this is analogous to
format % args. The args argument
Changes by Stefan Behnel :
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue16612>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
Updated patch to also fix a little typo in the docstring (lower case "python").
--
Added file: http://bugs.python.org/file29096/inspect_sig_3.patch
___
Python tracker
<http://bugs.python.o
Stefan Behnel added the comment:
Let me throw in a quick reminder that Cython has substantially faster argument
parsing than the C-API functions provide because it translates function
signatures like
def func(int a, b=1, *, list c, d=2):
...
into tightly specialised unpacking
Stefan Behnel added the comment:
Cython does that in general, sure. However, this ticket is about a specific
case where string methods (which are implemented in C) are slow when called
from Python. Antoine found out that the main overhead is not so much from the
method lookup itself but from
Stefan Behnel added the comment:
I still can't see a reference to Cython in the PEP. Larry, I don't really mind
adding a newly designed DSL for this, but regarding the implementation of the
actual argument parser, could you at least add a short paragraph to the PEP
that mentions i
Stefan Behnel added the comment:
I mentioned it in a couple of places during the discussion, you might just have
missed them.
The code that generates the unpacking C code starts here:
https://github.com/cython/cython/blob/4ebc647c2fa54179d25335b2dcf5d845e7fc9a79/Cython/Compiler/Nodes.py#L3068
New submission from Stefan Behnel:
The functionality of dict.setdefault() is not currently available through the
C-API. Specfically, there is no way to test for a key and insert a fallback
value for it without evaluating the hash function twice.
The attached patch adds a new C-API function
New submission from Stefan Behnel:
While writing the patch for issue 17327, I noticed that there is a double
reference leak in dict_setdefault() under the rare condition that resizing
fails. I'm not 100% sure that it's ok to move the increfs behind the resizing,
but considerin
Stefan Behnel added the comment:
I agree with basically all counter-arguments that were brought up so far. While
I would eventually like to use the available length hints in the special case
of Cython's list comprehensions, I'm far from seeing a general applicability
for this. The
Stefan Behnel added the comment:
The problem with 'default' is that it is a reserved word in C. I changed it to
"defaultobj", except for the docs page, where "default" should work. I also
removed the "register" declaration from the "mp" ar
Stefan Behnel added the comment:
I had originally considered that name. However, what it really does is
PyDict_GetItem(). In a specific special case, it sets a default value and
*then* returns that. So it's still PyDict_GetItem(), just with a preceding
modification. Also, the interface m
Stefan Behnel added the comment:
Well, guess what, I kind-of figured that. So, what's wrong with
PyDict_GetItemSetDefault()? That mimics the Python method name, too, while at
the same time making it clear what actually happens and how the C-API function
be
Stefan Behnel added the comment:
To me, PyDict_SetDefault() sounds like it's supposed to set a default value
that PyDict_GetItem() would return instead of NULL on lookup failure. Basically
a defaultdict-like extension to normal dicts.
--
___
P
Stefan Behnel added the comment:
I'm fine with PyDict_GetItemOrSetDefault() as well.
--
___
Python tracker
<http://bugs.python.org/issue17327>
___
___
Pytho
Stefan Behnel added the comment:
Ok (shrug), since everyone seems to agree, PyDict_SetDefault() it is. I
wouldn't be surprised if the same kind of discussion lead to the original
naming of dict.setdefault()...
--
Added file: http://bugs.python.org/file29345/pydict_setitemdefault.
Stefan Behnel added the comment:
If you decide to refactor a well tested patch, you might want to give it
another test run before committing it.
Objects/dictobject.c: In function 'dict_setdefault':
Objects/dictobject.c:2266:5: warning: passing argument 1 of 'PyDict_Se
Stefan Behnel added the comment:
I'm totally ok with your changes, though. The only real difference is an
aditional type check in the slot function path, and that's not going to make
any difference right after the costly operation of unpacking python function
Stefan Behnel added the comment:
Benjamin, I hadn't noticed that you also changed the documentation in dict.rst
from what I originall wrote. Ezio already fixed one of your typos, but there's
another one in the description of the "defaultobj" behaviour: it says
"inser
Stefan Behnel added the comment:
Please use either of the following wordings in the documentation:
"""
If the key is not in the dict, it is inserted with value *defaultobj* and
*defaultobj* is returned.
"""
or
"""
If the key is not in the dict,
Stefan Behnel added the comment:
... and it's called "defaultobj", not "defautobj".
--
___
Python tracker
<http://bugs.python.org/issue17327>
___
_
Stefan Behnel added the comment:
Thanks!
--
___
Python tracker
<http://bugs.python.org/issue17327>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Behnel:
Here is an artificial but pretty broad ElementTree benchmark, testing the
modules xml.etree.ElementTree, xml.etree.cElementTree and lxml.etree (if
importable). Please add it to the benchmark suite.
--
components: Benchmarks, XML
files
Changes by Stefan Behnel :
--
nosy: +brett.cannon, pitrou
___
Python tracker
<http://bugs.python.org/issue17573>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
I considered lxml.etree support more of a convenience feature, just for
comparison. Given that it's a binary package that doesn't run reliably on other
Python implementations apart of CPython, I don't think it's really interesting
to
Stefan Behnel added the comment:
Ok, but an lxml benchmark is independent from this patch then. I updated it to
only use cElementTree, with the additional "--etree-module" option and also a
"--no-accelerator" option for advanced usage.
Another thing I did is to split the a
Changes by Stefan Behnel :
--
nosy: +eli.bendersky, scoder
___
Python tracker
<http://bugs.python.org/issue22622>
___
___
Python-bugs-list mailing list
Unsub
Stefan Behnel added the comment:
FWIW, LZ4HC compression sounds like an obvious choice for write-once-read-many
data like .pyc files to me. Blosc shows that you can achieve a pretty major
performance improvement just by stuffing more data into less space (although it
does it for RAM and CPU
Changes by Stefan Behnel :
Removed file: http://bugs.python.org/file31421/faster_PyEval_SliceIndex.patch
___
Python tracker
<http://bugs.python.org/issue18813>
___
___
1001 - 1100 of 1287 matches
Mail list logo
