Stefan Behnel added the comment:
Given that PEP-489 has landed in Py3.5, which is already retired and has been
for more than a year, I think we can just close this issue as outdated.
--
resolution: -> out of date
stage: needs patch -> resolved
status: open -&g
Change by Stefan Behnel :
--
nosy: +scoder
___
Python tracker
<https://bugs.python.org/issue45711>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
FYI, we track the Cython side of this in
https://github.com/cython/cython/issues/4500
--
___
Python tracker
<https://bugs.python.org/issue45
Stefan Behnel added the comment:
New changeset e18d81569fa0564f3bc7bcfd2fce26ec91ba0a6e by Sebastian Pipping in
branch 'main':
bpo-45321: Add missing error codes to module `xml.parsers.expat.errors`
(GH-30188)
https://github.com/python/cpython/commit/e18d81569fa0564f3bc7bcfd2fce26
Change by Stefan Behnel :
--
components: +XML
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> enhancement
versions: -Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tra
Stefan Behnel added the comment:
I'd like to ask for clarification regarding issue 45321, which adds the missing
error constants to the `expat` module. I consider those new features – it seems
inappropriate to add new module constants in the middle of a release series.
However, in
Stefan Behnel added the comment:
Cython should be happy with whatever CPython uses (as long as CPython's header
files agree with CPython's build ;-) ).
I saw the RasPi benchmarks on the ML. That would have been my suggested trial
platform as well.
https://mail.python.org/archives/l
Stefan Behnel added the comment:
This is a backwards incompatible change, but unlikely to have a wide impact.
I was thinking for a second if it's making the change in the right direction
because it's not unreasonable to pass "None" for saying "I want no target".
Stefan Behnel added the comment:
> Any reasons the PR still not merged?
There was dissent about whether these constants should be added or not. It
doesn't help to merge a PR that is not expected to provide a benefit.
--
___
Python tracker
Stefan Behnel added the comment:
The question here is simply, which is considered more important: the default
provided by the document, or the default provided by Python. I don't think it's
a clear choice, but the way it is now does not seem unreasonable. Changing it
would mean
Stefan Behnel added the comment:
Makes sense. That list hasn't been updated in 10 years.
--
versions: -Python 3.10, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/is
Stefan Behnel added the comment:
> IMHO if the developer doesn't manage the XML itself it is VERY unreasonable
> to use the document value and not the developer one.
I disagree. If the document says "this is the default if no explicit value if
given", then I consider
Stefan Behnel added the comment:
I haven't looked fully into this yet, but I *think* that Cython can get rid of
most of the direct usages of PyFrameObject by switching to the new
InterpreterFrame struct instead. It looks like the important fields have now
been moved over to that.
Stefan Behnel added the comment:
Possibly also related, so I though I'd mention it here (sorry if this is
hijacking the ticket, seems difficult to tell). We're also seeing None values
in f_lineno in Cython's test suite with 3.11a5:
File "", line 1, in
Stefan Behnel added the comment:
New changeset 345572a1a0263076081020524016eae867677cac by Jannis Vajen in
branch 'main':
bpo-46786: Make ElementTree write the HTML tags embed, source, track, wbr as
empty tags (GH-31406)
https://github.com/python/cpyt
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Stefan Behnel :
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue46798>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Behnel added the comment:
I gave two reasons why this function can fail, and one turns out to be
assumed-to-be-dead code. So, no, there are two issues now, one with the
documentation, one with the code.
--
___
Python tracker
<h
New submission from Stefan Behnel :
Starting at line 1223 in classobject.c, you can find this code:
if (item == NULL)
arg = PyInt_FromSsize_t(i);
else
arg = Py_BuildValue("(nO)", i, item);
if (arg == NULL) {
Py_DECREF(func);
return -1;
Stefan Behnel added the comment:
Florent, thanks for the notification.
Nekmo, note that you are misusing this feature. The _namespace_map is meant to
provide "well known namespace prefixes" only, so that common namespaces end up
using the "expected" prefix. This is al
Stefan Behnel added the comment:
Reading the proposed patch, I must agree that it makes more sense in
ElementTree to support this as a serialiser feature. ET's tree model doesn't
have a notion of prefixes, whereas it's native to lxml.etree.
Two major advantages of puttin
New submission from Stefan Behnel :
In Python modules, the top-level module code sees the __file__ variable and can
use it to refer to resources in package subdirectories, for example. This is
not currently possible in extension modules, because __file__ is only set after
running the module
Changes by Stefan Behnel :
--
keywords: +patch
nosy: +loewis
Added file: http://bugs.python.org/file23725/ext_module_init_file_path.patch
___
Python tracker
<http://bugs.python.org/issue13
Stefan Behnel added the comment:
Here is an extension to the patch that implements the protocol also for
extension module reinitialisation, so that the module creation can also set
__file__ and the proper package in that case. Currently without tests (and
users, I guess).
--
Added
Stefan Behnel added the comment:
Updated single slice caching patch for latest Py3.3 hg tip.
--
Added file: http://bugs.python.org/file23727/slice-object-cache.patch
___
Python tracker
<http://bugs.python.org/issue10
Stefan Behnel added the comment:
I don't know how the import lock applies here. Would it have to be protected by
it? The lifetime is restricted to the call of the extension module init
function, and its value is saved recursively if the init function triggers
further imports.
It
Stefan Behnel added the comment:
... and the module init function could create and register a different module
first, and ...
Well, yes, it's a best effort thing. It's rather unlikely that the GIL would
get released in between the call to the init function and the creation of t
Stefan Behnel added the comment:
I'm aware that these things happen, that's why I said it. Actually, wouldn't it
rather be *correct* for __file__ to be set to the same file path for all
modules that an extension module creates in its init function? That woul
Stefan Behnel added the comment:
Updated patch that does not reset _Py_ModuleImportContext after use.
--
Added file: http://bugs.python.org/file23728/ext_module_init_file_path_2.patch
___
Python tracker
<http://bugs.python.org/issue13
New submission from Stefan Behnel :
This is a follow-up to issue 13429, which deals with setting __file__ on newly
created extension modules earlier than it is currently the case.
Currently, the module init function of extension modules lacks a way to find
out the context in which it is being
Stefan Behnel added the comment:
Replying to myself:
> I think the right fix for Python 4 would be to simply pass
> a context struct into the module init function.
Actually, this doesn't have to wait for Python 4. Changing the module init
function to take a parameter should b
Stefan Behnel added the comment:
Yes, that's unfortunate. I found the same paragraph in section 6.5.2.2p6 of the
C99 standard now, so it seems that this idea isn't suitable for the Py3.x
series.
There's no Python 4 target version in the b
Stefan Behnel added the comment:
The problem with having that information "internally" is that it's currently
stored in local variables in the call chain from the dynamic library loader.
Passing that information on into a callable function, without passing it as an
argumen
Stefan Behnel added the comment:
As MvL noted in his response to issue 13431, simply adding a parameter to the
module init function cannot safely be done before Python 4. So we are back to
the idea of passing the information through to the module creation function,
i.e. this very issue.
A
Stefan Behnel added the comment:
Ok, so, what do we make of this? I proposed improvements to the wording in the
documentation, which make it much clearer for users what they are buying into
when they start using minidom. I still think that "factually correct" but
clearly
Stefan Behnel added the comment:
I find a factor of an order of magnitude worth mentioning, because it prevents
certain kinds of usages.
--
___
Python tracker
<http://bugs.python.org/issue11
Stefan Behnel added the comment:
I don't think "FUD" is a suitable term for the rather minidom-friendly wording
in my last proposal. Seriously, minidom is widely known for being extremely
slow and extremely memory hungry. And that is backed by basically any benchmark
that has
Stefan Behnel added the comment:
Ezio Melotti, 29.11.2011 16:26:
>> Seriously, minidom is widely known for being extremely slow and
>> extremely memory hungry. And that is backed by basically any benchmark
>> that has ever been done on the subject.
>
> Do you have any l
Stefan Behnel added the comment:
Given that the links were generally somewhat dated and used Py2.x instead of
the post-PEP393 Py3.3, here is another little benchmark, comparing the parser
performance of minidom to lxml.etree (latest), ElementTree and cElementTree
(stdlib) in a recent Py3.3
Stefan Behnel added the comment:
Hmm, looks like I messed up the last example. I accidentally left in the
formatting whitespace, thus growing the file to 6.2 MB. Removing that, I get
this for the (now really) 4.5 MB XML file with lots of structure and very
little data:
Memory usage: 11600
Changes by Stefan Behnel :
--
nosy: +effbot
___
Python tracker
<http://bugs.python.org/issue13378>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
Given that this is a major new feature for the serialiser in ElementTree, I
think it's worth asking Fredrik for any comments.
--
___
Python tracker
<http://bugs.python.org/is
New submission from Stefan Behnel :
The ElementC14N.py module by Fredrik Lundh implements XML canonicalisation for
the ElementTree serialiser. Given that the required API hooks to use it are
already in xml.etree.ElementTree, this would make a nice, simple and straight
forward addition to the
Stefan Behnel added the comment:
I started a mailing list thread on the same topic:
http://thread.gmane.org/gmane.comp.python.devel/127963
Especially see
http://thread.gmane.org/gmane.comp.python.devel/127963/focus=128162
where I extract a proposal from the discussion. Basically, there
Stefan Behnel added the comment:
Any comments on the last patch?
--
___
Python tracker
<http://bugs.python.org/issue13429>
___
___
Python-bugs-list mailin
Stefan Behnel added the comment:
I don't see this having much to do with the DRY principle. It's "explicit is
better than implicit" and "better safe than sorry" that applies here.
--
___
Python tracker
<
New submission from Stefan Behnel :
As is obvious from the code, PyModule_GetDict() can fail if being passed a
non-module object, and when the (unlikely) dict creation at the end fails. The
documentation of the C-API function should be fixed to reflect that, i.e. it
should state that NULL is
New submission from Stefan Behnel :
In Py3, PyCode_New() takes a new argument "kwonlyargcount". The signature
change is not currently in the Py3 C-API documentation.
http://docs.python.org/dev/c-api/code.html
PyCodeObject *
PyCode_New(int argcount, int kwonlyargcount,
i
Stefan Behnel added the comment:
lxml.etree has encapsulated this in a 'docinfo' property which also holds the
XML 'version', the 'standalone' state and the DOCTYPE (if available).
Note that this information is readily available in lxml.etree for any parsed
El
Stefan Behnel added the comment:
That's why I mention it here to prevent future incompatibilities between the
two libraries.
--
___
Python tracker
<http://bugs.python.org/i
Stefan Behnel added the comment:
Here's a patch against the latest py3k. The following will call the new code,
for example:
str(memoryview(b'abc'), 'ASCII')
whereas bytes and bytesarray continue to use their own special casing code
(which has also changed a bi
Stefan Behnel added the comment:
Doesn't the GIL protect the bytearray buffer? Or does decoding free the GIL?
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/i
Stefan Behnel added the comment:
Regardless of the answer, I think Antoine is right, special cases aren't
special enough to break the rules, and this is a special case that's more
safely handled as part of the normal buffer case.
Updated patch uploaded.
--
Added f
Stefan Behnel added the comment:
... and another complete patch that refactors the complete function to make it
clearer what happens. Includes a small code duplication for the bytes object
case, which I think it acceptable.
--
Added file:
http://bugs.python.org/file18588
Changes by Stefan Behnel :
Removed file:
http://bugs.python.org/file18588/unicodeobject-PyUnicode_FromEncodedObject-buffer-refactored.patch
___
Python tracker
<http://bugs.python.org/issue7
Stefan Behnel added the comment:
Another updated patch with a readability fix (replacing the last one).
--
Added file:
http://bugs.python.org/file18589/unicodeobject-PyUnicode_FromEncodedObject-buffer-refactored.patch
___
Python tracker
<h
Stefan Behnel added the comment:
When I read the comments and exception texts in the function, it didn't occur
to me that "char buffer" could have been used as a name for the old Py2 buffer
interface. From the context, it totally makes sense to me that the function
(which
New submission from Stefan Behnel :
PySequence_GetSlice() in Objects/abstract.c contains the following code:
mp = s->ob_type->tp_as_mapping;
if (mp->mp_subscript) {
This crashes when the type's "tp_as_mapping" is NULL. The obvious fix is to
simply write
if
Stefan Behnel added the comment:
I find it a lot easier to appreciate patches that implement a single change
than those that mix different changes. There are three different things in your
patch, which I would like to see in at least three different commits. I'd be
happy if you
New submission from Stefan Behnel :
Lib/test/test_unicode_file.py contains dead code:
def _test_equivalent(self, filename1, filename2):
remove_if_exists(filename1)
self.assertTrue(not os.path.exists(filename2))
f = file(filename1, "w")
f.close()
Stefan Behnel added the comment:
I agree that this is annoying, we get the same thing in Cython's test suite all
over the place. Any foreign warning that doesn't get triggered helps in
debugging your own code. And this one is easy to avoid.
--
nos
New submission from Stefan Behnel :
http://docs.python.org/library/xml.dom.minidom.html
presents MiniDOM as a "Lightweight DOM implementation". The word "lightweight"
is easily misunderstood as meaning "efficient" or "memory friendly". MiniDOM is
w
Stefan Behnel added the comment:
Well, I'm not aware of many people who use 4DOM these days, and if that's what
it's meant to refer to, maybe that should be made more obvious, because it
currently is not at all. Even cDomlette uses only half of the memory according
to
http://
Stefan Behnel added the comment:
It's the tree based API most python users are parsing XML with, though. So I do
not agree that it's comparing apples and oranges, not at all. It's comparing
tree based XML libraries, only one of which is worth being called "light
weight&
Stefan Behnel added the comment:
> If that is a real concern, I'd rather reduce the memory footprint of
> minidom than put actual performance figures into the documentation
> that will likely outdate over time.
Personally, I do not think it's worth putting much work into M
New submission from Stefan Behnel :
In test file test_logging.py, around line 2359, list.append() is called with
two arguments instead of one. I suppose it is meant to be called with a tuple.
class ModuleLevelMiscTest(BaseTest):
[...]
def _test_log(self, method, level=None
Changes by Stefan Behnel :
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue12131>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
File checked with ClamAV under Linux, no findings.
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue10
Stefan Behnel added the comment:
I've extracted and fixed the part of this patch that implements the slice
object cache. In particular, PySlice_Fini() was incorrectly implemented. This
patch applies cleanly for me against the latest py3k branch.
--
Added file: http://bugs.pytho
Stefan Behnel added the comment:
> Any benchmark numbers for the slice cache?
I ran the list tests in pybench and got this:
Test minimum run-timeaverage run-time
thisother diffthisother d
Stefan Behnel added the comment:
There's a "PyObject_Del(obj)" in all code paths.
--
___
Python tracker
<http://bugs.python.org/issue10227>
___
___
Stefan Behnel added the comment:
Here are some real micro benchmarks (note that the pybench benchmarks actually
do lots of other stuff besides slicing):
base line:
$ ./python -m timeit -s 'l = list(range(100)); s=slice(None)' 'l[s]'
100 loops, best of 3: 0.464 usec pe
Stefan Behnel added the comment:
Here's another base line test: slicing an empty list
patched:
$ ./python -m timeit -s 'l = []' 'l[:]'
1000 loops, best of 3: 0.0847 usec per loop
original:
$ ./python -m timeit -s 'l = []' 'l[:]'
1000 l
Stefan Behnel added the comment:
> of course, this will not help for other common cases such as l[x:x+2]
... which is exactly what this slice caching patch is there for. ;-)
--
___
Python tracker
<http://bugs.python.org/issu
Stefan Behnel added the comment:
A quick test against the py3k stdlib:
find -name "*.py" | while read file; do egrep '\[[-0-9]*:[-0-9]*\]' "$file";
done | wc -l
This finds 2096 lines in 393 files.
--
___
Python tr
New submission from Stefan Behnel :
Follow-up to ticket 10227. The following facts seem to indicate that it would
be worth caching constant instances of the slice type, such as in [:] or [:-1].
with cached slice instance:
$ ./python -m timeit -s 'l = list(range(100)); s=slice(None)&
Stefan Behnel added the comment:
Created follow-up issue 11107 for caching constant slice objects.
--
___
Python tracker
<http://bugs.python.org/issue10
Stefan Behnel added the comment:
Erm, issue 10227.
--
___
Python tracker
<http://bugs.python.org/issue11107>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
Hmm, ok, but AFAICT, your patch was rejected rather because of the way it
approached the problem, not so much because of the issue itself.
Plus, the fact that Python 3 requires slices in more places than Python 2
(which had the lower level getslice protocol
New submission from Stefan Behnel :
During installation of Python packages (setup.py install or bdist), distutils
puts .pyc files into the installed source directory, instead of moving them
into __pycache__. This may mean that they are not getting used after
installation (with potentially no
Stefan Behnel added the comment:
Here's a patch. I basically copied over the way py_compile determines the .pyc
file name.
It works for me for a "normal" installation. However, I couldn't test it with
"-O", as 2to3 crashes for me when I enable it during i
New submission from Stefan Behnel :
When running a distutils installation of Cython (which uses lib2to3) as
"python3.2 -O setup.py bdist", I get this:
Skipping implicit fixer: buffer
Skipping implicit fixer: idioms
Skipping implicit fixer: set_literal
Skipping implicit fixer
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
The following fails in Py3.0a5:
>>> import re
>>> re.search(b'(\d+)', b'-2.80 98\n')
I get a TypeError: "Can't convert 'int' object to str implicitly&
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
Using 3.0a5, the following code crashes in vgetargskeywords (getargs.c:1542)
>>> d = {b"encoding": "abc"}
>>> str(b"abc", **d)
It should raise a TypeError instead, i.e. line 1535 s
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
While porting the code that Cython generates to Py3a5 (almost completed,
BTW), I noticed a problem with class creation. We are currently using
this call to create a new class in Py3:
PyObject_CallFunctionObjArgs((PyObject *)&P
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
Ah, I now see what the actual problem is. Byte strings return the byte
value on indexing.
Changing the title accordingly.
--
title: re module fails to handle digits in byte strings -> re module fails to
handle byt
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
Sorry, the bug was in Cython, which didn't call InstanceMethod().
Please ignore.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
The method cache is deactivated in current Py3. As Lisandro Dalcín
noticed, the following code in typeobject.c always returns false for a
Py3 identifier:
#define MCACHE_CACHEABLE_NAM
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
Here is a fix for Objects/classobject.c in Py3.0a5 that fixes a ref
count crash for classmethods.
--
components: Interpreter Core
files: instancemethod-fix.patch
keywords: patch
messages: 67334
nosy: scoder
severity: normal
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
Here is a patch that fixes this.
--
keywords: +patch
Added file: http://bugs.python.org/file10435/py3k-method-cache-fix.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
Here is a patch that makes this function public. This allows C code to
correctly taint a type after updating its attributes or base classes.
--
components: Interpreter Core
files: pytype_modified.patch
keywords: patch
me
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
Similar to the "decref before set" issue solved by Py_CLEAR(), the code
in typeobject.c calls DECREF in the middle of a cache update. This
leaves one cache entry in an invalid state during the DECREF call, which
might r
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
Here is a patch that removes three unused fields from the
PyNumberMethods struct in Py3. Since two fields were already removed
(one even before the ones this patch removes), there is no way existing
Py2 C code that uses this struct ca
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
Ok, I buy that argument. The patch may be considered a code uglification
then.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
This seems to have been applied in current SVN.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
Running a doctest with Py2 syntax in Py3 currently involves either
running the 2to3 tool by hand or writing code to convert the doctest
using lib2to3, and then running the modified version. This basically
pushes the burden of automatin
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
Here is a patch against the current PEP 3118 that removes the LOCK flag.
It follows this discussion on the Py3k mailing list:
http://comments.gmane.org/gmane.comp.python.python-3000.devel/13409?set_lines=10
It has not yet been ap
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
As a quick summary of the problems with the current PEP:
1) Many use cases will not require any locking at all, either because
they run single-threaded with a short-read/short-write pattern, or
because they do not write at all.
2)
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
:) sorry, that's the problem when you don't have commit rights and leave
the changes in your local copy.
So this is still an open issue that should be fixed before beta1, thanks.
___
Python
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
Here is a patch that removes all occurrences of the locking protocol
from the current py3k branch code base.
There are still some issues in memoryobject.c:
- there was an occurrence of PyBUF_SHADOW that might have to be h
1 - 100 of 1287 matches
Mail list logo
