Eli Bendersky eli...@gmail.com added the comment:
Stefan, frankly I'm not familiar enough with either xml.dom or xml.dom.minidom
to have a solid opinion at this point.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11379
Eli Bendersky eli...@gmail.com added the comment:
I can confirm that this indeed fails for the C implementation, while succeeding
for the Python implementation.
The C implementation doesn't appear to support extended slices for getting and
setting items. Looking
Eli Bendersky eli...@gmail.com added the comment:
Correction: extended slices are supported. The problem appears to be just with
'del', because element_ass_subscr doesn't treat it specially and thinks we just
want to assign a 0-len value to a non-0-len slice
Changes by Eli Bendersky eli...@gmail.com:
--
nosy: +eli.bendersky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14065
___
___
Python-bugs-list
Eli Bendersky eli...@gmail.com added the comment:
John, thanks for the contribution, however this is not a valid fix.
See the Wikipedia page for floating point:
http://en.wikipedia.org/wiki/Floating_point
No dash!
There is no need to go over the Python docs fixing such mistakes. If you
Changes by Eli Bendersky eli...@gmail.com:
--
nosy: +eli.bendersky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14165
___
___
Python-bugs-list
Eli Bendersky eli...@gmail.com added the comment:
IMHO just leave it. The documentation is mainly for reference, i.e. describing
in the best way possible what's available *now*. If you want to mention an
upgrade path, write a blog :)
--
___
Python
Eli Bendersky eli...@gmail.com added the comment:
Committed to 2.7, 3.2 and 3.3
I suppose this issue can be closed now?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11379
Eli Bendersky eli...@gmail.com added the comment:
I'm attaching a patch for Doc/library/xml.dom.minidom.rst
It adds the note as phrased by Stefan, with a tiny wording change to make the
first sentence less ambiguous.
--
keywords: +patch
Added file: http://bugs.python.org/file24686
Eli Bendersky eli...@gmail.com added the comment:
I’m not sure I would use note markup, though (cf. Raymond’s aversion to
littering the doc with note and warning boxes).
I also dislike box littering, but this one seems like a really good fit for
a note, since it's completely outside
Eli Bendersky eli...@gmail.com added the comment:
Patch attached
--
keywords: +patch
stage: - patch review
Added file: http://bugs.python.org/file24663/issue_14129.1.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14129
Eli Bendersky eli...@gmail.com added the comment:
Thanks for the review. I'm going to do the commit now. Feel free to just fix it
if any obvious mistakes remain.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14129
Eli Bendersky eli...@gmail.com added the comment:
Regarding the use of the name variable, could it be replaced by just name ?
That might make sense since the error for undefined names is usually
NameError. However, note that the current documentation has a /huge/ amount of
mentions
New submission from Eli Bendersky eli...@gmail.com:
Element, XMLParser and TreeBuilder are types in ElementTree, but factory
functions in _elementtree. The latter should be modified to be consistent with
the former.
--
assignee: eli.bendersky
components: Library (Lib)
messages: 154317
Eli Bendersky eli...@gmail.com added the comment:
In the pydev discussion once Martin raised this problem it was agreed that this
is a regression in 3.3 that should be fixed, since there is code out there that
relies on subclassing Element. This would make the Python and C implementations
New submission from Eli Bendersky eli...@gmail.com:
I'm now carefully reading through the extending documentation pages. This
issue will record various problems I find on the way, with the intention of
fixing them eventually.
--
assignee: eli.bendersky
components: Documentation
Eli Bendersky eli...@gmail.com added the comment:
extending.html has a reference to Demo/embed/demo.c which no longer exists in
the source distribution
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14129
Eli Bendersky eli...@gmail.com added the comment:
Florent,
The deprecation should be probably raised separately on pydev. From the recent
discussions on this and similar topics, I doubt that removal of these methods
will be accepted.
--
___
Python
Eli Bendersky eli...@gmail.com added the comment:
in this case, nothing more than every Python object contains
There's a grammar error lurking somewhere in there...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14129
Eli Bendersky eli...@gmail.com added the comment:
A PyObject is not a very magnificent object - it just contains the refcount
and a pointer to the object’s “type object”.
Too chatty and should be replaced by a more pragmatic explanation, or shortened.
--
nosy: +docs@python
Eli Bendersky eli...@gmail.com added the comment:
This is not strictly in the extending doc, but linked from it:
http://docs.python.org/dev/c-api/type.html#PyType_GenericNew
The PyType_GenericNew API function is not documented
--
___
Python tracker
Eli Bendersky eli...@gmail.com added the comment:
Let’s expend
Typo
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14129
___
___
Python-bugs
Eli Bendersky eli...@gmail.com added the comment:
The new method calls the tp_alloc slot to allocate memory
tp_alloc needs formatting here, similarly to the way it's done in other places
--
___
Python tracker rep...@bugs.python.org
http
Eli Bendersky eli...@gmail.com added the comment:
Noddy_name in the full code listing (included from noddy2.c) is different from
the Noddy_name that is actually explained later
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Eli Bendersky eli...@gmail.com added the comment:
but in this cased
Typo
[this and the past couple of comments refer to the newtypes.html doc]
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14129
Eli Bendersky eli...@gmail.com added the comment:
On Sun, Feb 26, 2012 at 23:49, Florent Xicluna rep...@bugs.python.orgwrote:
Yes, these suggestions sound reasonable to me. Moving toward two more
consistent implementations of the API, while not disabling existing
features is the way to go
Eli Bendersky eli...@gmail.com added the comment:
There are some:
XXX Need to ...
Paragraphs scattered across the doc. These have no place in the official
documentation. For placeholders, an issue can be created that lists all the
things that need to be done
Eli Bendersky eli...@gmail.com added the comment:
Adding the documentation experts.
I plan to apply a fix for these soon. If you guys have any objections, let me
know.
--
nosy: +eric.araujo, ezio.melotti, georg.brandl
___
Python tracker rep
Eli Bendersky eli...@gmail.com added the comment:
Ezio, your fix for 8 is definitely good. Space makes it cleaner, as well as
compliant to PEP 8, which explicitly recommends to surround operators with
spaces.
Note, however, that this should be applied in other places as well, not only
Eli Bendersky eli...@gmail.com added the comment:
Comments on some of the suggestions:
1) Agreed
2) Can be combined with (3), I think. Just show the number example with the
explanatory comments. They speak for themselves. No need for the SPAM and
STRING assignments.
5) Yep. Can be replaced
Eli Bendersky eli...@gmail.com added the comment:
If you want to collect additional feedback, you may want to add some
other
people to the Nosy list :-)
I did not want more feedback, I wanted to leave time for interested
parties to find this bug for themselves and eventually comment
Eli Bendersky eli...@gmail.com added the comment:
Florent, I can reproduce the problem by leaving just the last
import_fresh_module in test_fresh_import.py
And your patch fixes it, although as Nick says it's problematic in terms of ref
leaks.
What I'm not sure about is why the extra
Eli Bendersky eli...@gmail.com added the comment:
Emitting a deprecation warning on importing cElementTree has been rejected in
the pydev list. The other remaining tasks have new issues on them, so this
issue is done now.
--
___
Python tracker rep
Eli Bendersky eli...@gmail.com added the comment:
Éric, indeed it clarifies the usage, but my concern is that it also moves the
first mention of the module further down.
There's no real reason for someone using CPython 2.7 or 3.2 *not* to use cET.
So, some mention should appear in the opening
Eli Bendersky eli...@gmail.com added the comment:
Also, I must add that I absolutely hate the opening paragraph of the
documentation in this module. Once 14006 is implemented, parts of it should be
backported to 2.7 and 3.2
That would be an orthogonal change to what we're discussion here
Changes by Eli Bendersky eli...@gmail.com:
--
nosy: +eli.bendersky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14023
___
___
Python-bugs-list
Eli Bendersky eli...@gmail.com added the comment:
If you want to collect additional feedback, you may want to add some other
people to the Nosy list :-) Alternatively, since it's a small doc change you
can just commit it and it can be fixed later if someone strongly objects
New submission from Eli Bendersky eli...@gmail.com:
The documentation of xml.etree.ElementTree has to be improved. The first, very
obvious step, would be to start the documentation page with a general overview
of the module + some simple examples. The current opening section makes no
sense
Eli Bendersky eli...@gmail.com added the comment:
I would add to the TODO - improve the documentation of the module. Opened issue
14006 for this.
--
resolution: fixed -
stage: committed/rejected - needs patch
status: closed - open
___
Python
Changes by Eli Bendersky eli...@gmail.com:
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
Eli Bendersky eli...@gmail.com added the comment:
I started going over the deprecated methods in ElementTree and ran into a more
serious problem. XmlParser.doctype() is listed as deprecated, and indeed
ElementTree (the Python version) issues a deprecation warning. However, the C
New submission from Eli Bendersky eli...@gmail.com:
Although documented, the C accelerator of xml.etree.ElementTree (used by
default since issue 13988) does not use or define the doctype() methods of the
XMLParser and TreeBuilder classes, although this method is documented.
As far as I can
Eli Bendersky eli...@gmail.com added the comment:
The doctype() problem is deeper, since neither does TreeBuilder implement it
(although for this class it's not even deprecated). Since this appears to be a
problem in 3.2 as well, I'm opening a new issue - 14007, to track
Changes by Eli Bendersky eli...@gmail.com:
--
Removed message: http://bugs.python.org/msg153325
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
New submission from Eli Bendersky eli...@gmail.com:
The C accelerator of xml.etree.ElementTree (used by default since issue 13988)
does not use or define or use the doctype() methods of the XMLParser and
TreeBuilder classes, although this method is documented.
As far as I can tell
Changes by Eli Bendersky eli...@gmail.com:
--
Removed message: http://bugs.python.org/msg153327
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
Eli Bendersky eli...@gmail.com added the comment:
Opened issue 14007 to track the doctype() problem
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
Eli Bendersky eli...@gmail.com added the comment:
Opened issue 14007 to track the doctype() problem
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
Changes by Eli Bendersky eli...@gmail.com:
--
Removed message: http://bugs.python.org/msg153324
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14007
Eli Bendersky eli...@gmail.com added the comment:
The problem is deeper. _elementtree does not expose XMLParser and TreeBuilder
as types at all, just as factory functions.
XMLParser: not sure if it was meant to be subclassed. If not, it should at
least be documented. In any case
Eli Bendersky eli...@gmail.com added the comment:
Florent,
Your updated patch looks good. I think that the explicit import of
_namespace_map into cElementTree is just to satisfy some weird magic in the
tests and can probably be removed as well (along with the weird magic :-), but
that's
Eli Bendersky eli...@gmail.com added the comment:
By the way, I see that if the explicit import of _namespace_map is commented
out, the test_xml_etree_c test fails because it's not in the __all__ list. So
the test can just import it directly with:
from xml.etree.ElementTree import
Eli Bendersky eli...@gmail.com added the comment:
OK, so if I got it correctly, I should document
multiprocessing.queue.SimpleQueue in 2.7 and 3.1 [...]
and 3.2, we're no longer updating 3.1 with such changes
--
___
Python tracker rep
Changes by Eli Bendersky eli...@gmail.com:
--
Removed message: http://bugs.python.org/msg153224
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11836
Eli Bendersky eli...@gmail.com added the comment:
OK, so if I got it correctly, I should document
multiprocessing.queue.SimpleQueue in 2.7 and 3.1 [...]
s/3.1/3.2/
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11836
Eli Bendersky eli...@gmail.com added the comment:
Alright, it's not really important at this point and can be cleaned up
later.
I will probably commit code and documentation at once. It makes things
easier regarding traceability.
Sounds good
Eli Bendersky eli...@gmail.com added the comment:
The more I think about it, the more the bootstrap code in _elementtree.c annoys
me. It's the only instance of calling PyRun_String in Modules/ !
It's hackish and causes ugly import problems. If the C code needs stdlib
functionality like
Eli Bendersky eli...@gmail.com added the comment:
I find it perfectly legitimate to run Python code from a C module.
Certainly not a hack. We all know that most non-trivial functionality can
be expressed much easier in Python than in C, that's why we use Python
after all. In particular
Eli Bendersky eli...@gmail.com added the comment:
Another random cleanup idea:
ElementTree.py has this code:
try:
from . import ElementPath
except ImportError:
ElementPath = _SimpleElementPath()
Since in the stdlib ElementPath.py is always there, this is meaningless, so I'd
say
Eli Bendersky eli...@gmail.com added the comment:
I was referring to one of the points raised in the email thread: the docs
don’t tell people that they can import a faster ET version, cET.
Well, they *do*, but very modestly :-) I agree that should be improved and
emphasized a bit, perhaps
Eli Bendersky eli...@gmail.com added the comment:
Florent,
The issue13988_fold_cET_behind_ET.diff patch looks good to me. Unless there are
objections from others, you can commit! Even the tests became simpler now,
that's awesome ;-)
Now, what's left for this issue:
1. Update
Eli Bendersky eli...@gmail.com added the comment:
Attaching a patch for Doc/library/xml.etree.elementtree.rst and Misc/NEWS.
The doc notice is modeled after a similar notice in the doc of 'pickle'. Note
that I've also removed the mention that effbot's site is the home of the
development
Eli Bendersky eli...@gmail.com added the comment:
Florent,
Just something minor I noticed in the new cElementTree.py:
# Wrapper module for _elementtree
from xml.etree.ElementTree import *
# Not in __all__
from xml.etree.ElementTree import ElementPath, XMLID, register_namespace
Eli Bendersky eli...@gmail.com added the comment:
Would not adding a new keyword arg to open() be less intrusive and more
consistent?
I.e. open(fname, asciionly=True) or something similar.
--
nosy: +eli.bendersky
___
Python tracker rep
Eli Bendersky eli...@gmail.com added the comment:
Éric,
Could you please open a new issue (with a dependency on this one) and explain
there clearly what you want/mean?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13988
Eli Bendersky eli...@gmail.com added the comment:
If the concept is accepted. I see no better place for this than the
Unicode HOWTO. If it's too long, then a TL;DR; section should be added
in the beginning detailing the bare minimum. No need to scatter such
information in bits and pieces around
Changes by Eli Bendersky eli...@gmail.com:
--
nosy: +eli.bendersky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13987
___
___
Python-bugs-list
New submission from Eli Bendersky eli...@gmail.com:
Following the discussion on python-dev [1], this issue will track the
re-organization of Lib/xml/etree to expose the C implementation (_elementtree)
by default when importing ElementTree. The test suite will also have to be
updated - it's
Eli Bendersky eli...@gmail.com added the comment:
Oh, and not to forget: the documentation has to be updated to just not mention
cElementTree any longer. For the user, the fact that a fast C library is
invoked underneath should be invisible
Eli Bendersky eli...@gmail.com added the comment:
Hmm, that may be PEP 399:
If an acceleration module is provided it is to be named the same as the
module it is accelerating with an underscore attached as a prefix, e.g.,
_warnings for warnings. The common pattern to access the accelerated
Eli Bendersky eli...@gmail.com added the comment:
IIRC, there is a well specified way how accelerator modules should be used
by Python modules. I recall a lengthy discussion on python-dev (or the py3k
list?) back in the old pre-3.0 days, maybe there's even a PEP?
If there's a convention, I'll
Eli Bendersky eli...@gmail.com added the comment:
If possible I would avoid pyElementTree,
I suppose it's possible, but I'm genuinely interested in a technical reason for
doing so. The approach suggested in PEP 399 is useful for module in which part
of the functionality is implemented in C
Eli Bendersky eli...@gmail.com added the comment:
From a performance point of view, consider the (by far) common case
- where _elementtree *is* successfully imported.
... for each invocation, the whole import of the Python code has
to be done, just to reach the overriding import * at the end
Eli Bendersky eli...@gmail.com added the comment:
Oops, in last message:
s/there will be circular dependencies/there will not be circular dependencies/
--
stage: needs patch -
type: performance -
___
Python tracker rep...@bugs.python.org
http
Eli Bendersky eli...@gmail.com added the comment:
What I had in mind is more like:
- ElementTree: defines the python code and if _elementtree is available
overrides part of it with the functions imported from it;
The problem with this is the bootstrap Python code executed by
_elementtree
Eli Bendersky eli...@gmail.com added the comment:
Ezio,
We are assuming that _elementtree might be missing, but what are the cases
where this might actually happen? Other implementations like PyPy? Exotic
platforms that can't compile _elementtree?
I guess both. To make the stdlib work
Eli Bendersky eli...@gmail.com added the comment:
Florent, thanks for the patch - at this point code is more useful than talk :-)
Anyhow, I tried to apply it and a few tests in test_xml_etree_c fail, because
it can't find fromstring and fromstringlist. This gets fixed when I import
Eli Bendersky eli...@gmail.com added the comment:
I strongly feel that existing code importing ElementTree or cElementTree
should not be broken. Let’s add transparent import from _elementtree to
ElementTree without breaking existing uses of cET.
AFAICS there's currently no disagreement
Eli Bendersky eli...@gmail.com added the comment:
I have to say that the non-obvious subtleties you point out in your rglob
make me think I personally would probably opt to use Nick's module directly
instead, so that I was sure what I was getting.
--
+1
Eli Bendersky eli...@gmail.com added the comment:
It looks more useful to me to have a consistent behavior between C and
Python version.
I agree, especially is we now consider to expose the C API by default, leaving
the Python API as a fallback
Eli Bendersky eli...@gmail.com added the comment:
Terry, I agree with 3. The regression here is insignificant enough in my view
to warrant mucking with already released versions.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Eli Bendersky eli...@gmail.com added the comment:
file_paths(filtered_walk('.', included_files=['*.py'])) is a lot longer than
rglob('*.py').
It is, but is that a good enough reason to have both? It can also be achieved
with just a bit more code using the simple `os.walk`. I suppose
Eli Bendersky eli...@gmail.com added the comment:
It is. globbing is a well-known operation that many people expect to be
easily done.
According to Wikipedia (http://en.wikipedia.org/wiki/Glob_%28programming%29) -
The noun glob is used to refer to a particular pattern, e.g. use the glob
Eli Bendersky eli...@gmail.com added the comment:
IOW, globbing is usually understood as the act of expanding a pattern
to the files it matches. Nothing in that implies recursive traversal
of a directory tree.
Still, that's a common need. I want all Python files in a subtree.
On the other
Eli Bendersky eli...@gmail.com added the comment:
Google walk directory. First hit is a Rosetta code page with
*recursive* walking implemented in various languages. So I guess it
does have this connotation. Regardless, os.walk has been in Python for
ages, and it's always been the go-to tool
Eli Bendersky eli...@gmail.com added the comment:
Oops, Éric, sorry about the title. I didn't even notice :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13968
Eli Bendersky eli...@gmail.com added the comment:
Martin, do you find the wording I quoted (*without* the reference to a more
Pythonic API) acceptable?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11379
Eli Bendersky eli...@gmail.com added the comment:
Well, if glob() already lived in shutil, this decision would be a
no-brainer :) Having glob() in the glob module and globtree() in the
shutil module, though, looks a bit weird.
(I agree having a separate module for glob isn't ideal)
Would
Eli Bendersky eli...@gmail.com added the comment:
Eric,
Thanks for checking. I agree that this behavior is acceptable, but a
documentation fix would be appropriate. The documentation of iterparse should
mention the events it accepts, also saying that those are strings.
The events are listed
Eli Bendersky eli...@gmail.com added the comment:
Changing the target version(s) and adding some documentation experts to the
nosy list
--
nosy: +eric.araujo, ezio.melotti, sandro.tosi
versions: +Python 3.2, Python 3.3 -Python 3.1
___
Python tracker
Eli Bendersky eli...@gmail.com added the comment:
ISTM that part of the doc specifically deals with Unix, so this issue can be
closed as completed.
Windows is a different issue. Perhaps the documentation should have a new
section on embedding on Windows, similarly to the Building C and C
Eli Bendersky eli...@gmail.com added the comment:
Sandro, can you commit, taking Antoine's note into account?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11836
Eli Bendersky eli...@gmail.com added the comment:
IMHO this wording proposed by Stefan:
[[Note: The xml.dom.minidom module provides an implementation of the W3C-DOM
whose API is similar to that in other programming languages. Users who are
unfamiliar with the W3C-DOM interface or who would
Changes by Eli Bendersky eli...@gmail.com:
--
nosy: +eli.bendersky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13782
___
___
Python-bugs-list
Eli Bendersky eli...@gmail.com added the comment:
At this point, 3.1 won't be fixed with such changes any longer.
Is this fixed in 3.2/3.3?
--
nosy: +eli.bendersky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9257
Eli Bendersky eli...@gmail.com added the comment:
And while we're at it, I would consider revising both sentences in a more
fundamental way, since they're too chatty for the official docs.
--
nosy: +eli.bendersky
___
Python tracker rep
New submission from Eli Bendersky eli...@gmail.com:
I've decided to study the multiprocessing module a bit, and carefully went over
the docs (for 2.7). Some small fixes I will commit myself, but a few issues
came up on which I'd like some opinion from others. In rough order of
appearance
Eli Bendersky eli...@gmail.com added the comment:
10. Unless I'm missing something entirely obvious, except in the examples it
says that Value has a value attribute for actual data access. One is expected
to look in the docs of ctypes to find
Changes by Eli Bendersky eli...@gmail.com:
--
nosy: +eli.bendersky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13574
___
___
Python-bugs-list
Changes by Eli Bendersky eli...@gmail.com:
--
nosy: +eli.bendersky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13530
___
___
Python-bugs-list
701 - 800 of 1226 matches
Mail list logo
