[issue25455] Some repr implementations don't check for self-referential structures
Changes by Eli Bendersky : -- nosy: -eli.bendersky ___ Python tracker <http://bugs.python.org/issue25455> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25455] Some repr implementations don't check for self-referential structures
Eli Bendersky added the comment: As I've mentioned elsewhere, I'll have to temporarily take myself off these issues as I don't have the time to work on them (even review patches). I think Raymond may have gotten his Stefans mixed up and meant Stefan Behnel, who's also been looking at etree patches. -- ___ Python tracker <http://bugs.python.org/issue25455> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25455] Some repr implementations don't check for self-referential structures
Changes by Eli Bendersky : -- nosy: -eli.bendersky ___ Python tracker <http://bugs.python.org/issue25455> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19687] Fixes for elementtree integer overflow
Eli Bendersky added the comment: Serhiy, I'm truly sorry but for this and other issues you pinged -- I currently have zero bandwidth to invest in this. Feel free to ask around on pydev if there are other folks interested in reviewing patches and decisions w.r.t the etree module. I'm fine with your judgement otherwise. -- ___ Python tracker <http://bugs.python.org/issue19687> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19176] DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser
Eli Bendersky added the comment: I'm not sure. This is why I'm proposing asking on python-dev -- ___ Python tracker <http://bugs.python.org/issue19176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19176] DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser
Eli Bendersky added the comment: I don't know how important this is to really warrant removal. Removal means potentially breaking working code when trying to run it with Python 3.5, and my impression was that the core devs are somewhat alergic to this, at least while the transition to Python 3 is ongoing. Unless it has already been discussed (sorry if I missed it, haven't had much time for CPython recently, unfortunately), may be worth a quick check with python-dev -- ___ Python tracker <http://bugs.python.org/issue19176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23896] lib2to3 doesn't provide a grammar where exec is a function
New submission from Eli Bendersky: lib2to3 helpfully provides pygram.python_grammar_no_print_statement for parsing Python 3 ('print' has the semantics of an identifier, not a keyword) However, the same courtesy is not extended to 'exec', which also turns from a statement to an identifier in Python 3. I'd propose adding something like python_grammar_no_print_and_exec_statement The name's a handful, but it's explicit and I can't think of anything else, given that we don't want to change the lib2to3 API at this time to rename these grammars using some other convention. -- components: Library (Lib) messages: 240326 nosy: eli.bendersky priority: normal severity: normal stage: needs patch status: open title: lib2to3 doesn't provide a grammar where exec is a function type: behavior versions: Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue23896> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23894] lib2to3 doesn't recognize rb'...' as a raw byte string in Python 3
Changes by Eli Bendersky : -- stage: -> needs patch type: -> behavior ___ Python tracker <http://bugs.python.org/issue23894> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23894] lib2to3 doesn't recognize rb'...' as a raw byte string in Python 3
New submission from Eli Bendersky: lib2to3 tokenizes br'abc' as a single STRING token, but rb'abc' as two separate tokens (NAME "rb" and STRING 'abc') This is because pgen2/tokenize.py doesn't list rb'' as a viable prefix for a string, even though according to https://docs.python.org/3/reference/lexical_analysis.html it is -- keywords: easy messages: 240322 nosy: benjamin.peterson, eli.bendersky priority: normal severity: normal status: open title: lib2to3 doesn't recognize rb'...' as a raw byte string in Python 3 versions: Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue23894> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23549] heapq docs should be more precise about how to access the smallest element
Changes by Eli Bendersky : -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue23549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23549] heapq docs should be more precise about how to access the smallest element
Eli Bendersky added the comment: Raymond - gentle ping. Do you see a reason not to check this in? -- ___ Python tracker <http://bugs.python.org/issue23549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23549] heapq docs should be more precise about how to access the smallest element
Eli Bendersky added the comment: Good catch. Attaching a new version of the patch with the typo fixed. -- Added file: http://bugs.python.org/file38280/issue23549.2.patch ___ Python tracker <http://bugs.python.org/issue23549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23549] heapq docs should be more precise about how to access the smallest element
Eli Bendersky added the comment: Proposed patch (generated vs. the 3.4 docs) is attached -- keywords: +patch Added file: http://bugs.python.org/file38277/issue23549.1.patch ___ Python tracker <http://bugs.python.org/issue23549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23549] heapq docs should be more precise about how to access the smallest element
New submission from Eli Bendersky: The heapq documentation has this paragraph after the doc of nsmallest: The latter two functions perform best for smaller values of n. For larger values, it is more efficient to use the sorted() function. Also, when n==1, it is more efficient to use the built-in min() and max() functions. This is confusing as it suggests to use min() on a heap to find the minimal element. heap[0] is the minimal element, but this is only mentioned at the very top - so you need to read the doc of the entire module to find it. Nothing in the docs of methods suggests it. -- assignee: docs@python components: Documentation messages: 236895 nosy: docs@python, eli.bendersky priority: normal severity: normal status: open title: heapq docs should be more precise about how to access the smallest element type: behavior versions: Python 2.7, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue23549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17963] Deprecate the frame hack for implicitly getting module details
Eli Bendersky added the comment: I don't have time, unfortunately. So other folks can pick this up. I don't remember if I made any progress on this - will post whatever I have if I find something. -- ___ Python tracker <http://bugs.python.org/issue17963> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21793] httplib client/server status refactor
Changes by Eli Bendersky : -- nosy: -eli.bendersky ___ Python tracker <http://bugs.python.org/issue21793> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23292] Enum doc suggestion
Eli Bendersky added the comment: Georg, each library writer is entitled to do whatever she wants. Naturally, we can't prevent dumping contents of enums into the module namespaces, and yes, backwards compatibility makes sense for some modules. However, that's tangential to *encouraging* this un-Pythonic behavior by including the trick in the official documentation. After all, namespaces is a good idea (from the Zen of Python), and Enums as namespaces are also a good idea (self-documenting code). There's a huge amount of tricks we could add to the documentation, but we don't. There's wikis for that, blogs, Stack Overflow, Active Python recipes, what have you. I wouldn't spend too much time arguing about this, though. If you feel strongly that this belongs in the standard documentation, go ahead. I just wanted to provide an alternative view of the issue. -- ___ Python tracker <http://bugs.python.org/issue23292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23292] Enum doc suggestion
Eli Bendersky added the comment: I'm not sure why the current situation is annoying? Python explicitly does not pollute the enclosing namespace with an Enum's members. So when you: import A It's fairly natural that you have access to A.MyEnum and not its members, no? Some modules (like some stdlib modules) may choose to push the enum members up to the module's scope explicitly, but I wouldn't necessarily call it best practice. Namespacing is Pythonic, splashing contents of classes into enclosing namespaces isn't. So I guess what I'm trying to say is that I don't see a reason to explicitly suggest something that is, in general, against the spirit of Python, in the documentation. [P.S. Thanks for reporting, Mark, I love your books!] -- ___ Python tracker <http://bugs.python.org/issue23292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22505] Expose an Enum object's serial number
Eli Bendersky added the comment: >> I could continue the discussion about databases, but it feels like a waste >> of time to me. The main principle is: If something has an important property >> (in this case an enum object's numerical value), it should be publicly >> exposed. Period. No need to spend hours discussing if and how that property >> will be used. They always end up getting used somehow-- The only question is >> whether the people using them need to obtain them through private variables >> for years until the developers finally understand that the property needs to >> be exposed publicly. If you want to go through that, be my guest. This kind of attitude is not welcome in the core Python development community. Please keep the discussion courteous and stick to technical arguments. FWIW I fully agree with Barry and Ethan here. -- ___ Python tracker <http://bugs.python.org/issue22505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14910] argparse: disable abbreviation
Eli Bendersky added the comment: Ezio, could you see if your comments were addressed? Steven, do you want to take another look, or is this OK to commit? -- ___ Python tracker <http://bugs.python.org/issue14910> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14910] argparse: disable abbreviation
Eli Bendersky added the comment: No worries, Daniel. You should have received an email when comments were posted to the review, did you? If you you may want to check your settings in the bug tracker. I left a couple of additional comments on the documentation file, but other than that this LGTM. -- ___ Python tracker <http://bugs.python.org/issue14910> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14910] argparse: disable abbreviation
Eli Bendersky added the comment: Daniel, I left some comments in Rietveld. Also it doesn't seem that you addressed the previously left comments when you fixed up the patch. -- ___ Python tracker <http://bugs.python.org/issue14910> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18780] SystemError when formatting int subclass
Eli Bendersky added the comment: On Tue, Jun 24, 2014 at 3:18 PM, Ned Deily wrote: > > Ned Deily added the comment: > > It is described in the developer's guide. The current status is > summarized here: > > https://docs.python.org/devguide/devcycle.html#summary > > Excellent. Thanks Ned. -- ___ Python tracker <http://bugs.python.org/issue18780> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18780] SystemError when formatting int subclass
Eli Bendersky added the comment: On Tue, Jun 24, 2014 at 2:29 PM, Ned Deily wrote: > > Ned Deily added the comment: > > The 3.3 branch is now only open for security fixes so this issue doesn't > appear to warrant backporting there. > > -- > These questions keep popping up in various places, being asked even by core devs like here. Is there a place where this is described formally? I.e. 3.5 is trunk, 3.4 is bug fixes, 3.3 is security fixes, doc fixes good everywhere, and some info about 2.7? I imagine since this only changes once per 18 months or so, it should not be difficult to maintain and can just be part of the release manager's job. -- ___ Python tracker <http://bugs.python.org/issue18780> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
Eli Bendersky added the comment: [sorry, the first question mark shouldn't be - the patch indeed looks reasonable to me] Steven - how about launching a subprocess for stdin tests to avoid weird issues? -- ___ Python tracker <http://bugs.python.org/issue14156> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
Eli Bendersky added the comment: The patch looks reasonable? Is the only remaining problem with crafting the test? -- ___ Python tracker <http://bugs.python.org/issue14156> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
Eli Bendersky added the comment: Nosy-ing myself since I just ran into it. Annoying issue that precludes from using argparse's builtin '-' recognition for reading binary data. I'll try to carve some time later to look at the patches. -- nosy: +eli.bendersky versions: +Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue14156> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21706] Add base for enumerations (Functional API)
Eli Bendersky added the comment: Is it really worthwhile to complicate the API for the sake of providing a less flexible solution for rare cases that saves a few keystrokes? -- ___ Python tracker <http://bugs.python.org/issue21706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21480] A build now requires...
Eli Bendersky added the comment: Skip, PTAL at the devguide. https://docs.python.org/devguide/setup.html#avoiding-re-creating-auto-generated-files -- ___ Python tracker <http://bugs.python.org/issue21480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Eli Bendersky added the comment: This is also described in the Dev Guide: https://docs.python.org/devguide/setup.html -- ___ Python tracker <http://bugs.python.org/issue19655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Eli Bendersky added the comment: Stefan, you need to run `make touch` if you want to avoid rebuilding. See #15964 for more details. [all bots run `make touch` before building now] -- ___ Python tracker <http://bugs.python.org/issue19655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Changes by Eli Bendersky : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue19655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21403] cElementTree's Element creation handles attrib argument different from ET
Eli Bendersky added the comment: > Note that this has been fixed in Py3 already (Py3.3, I guess). The only > question is whether the behaviour will be changed in Py2.7. > I don't think this issue is acute enough to warrant fixes in 2.7; however, a documentation patch would be welcome. -- ___ Python tracker <http://bugs.python.org/issue21403> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Eli Bendersky added the comment: Updated patch attached: 1. Python 3.3+ supported (I suspect 3.2 will work too) 2. Incorporated Serhiy's suggestions (thanks for the review!) -- Added file: http://bugs.python.org/file34742/new-asdl-parser.issue19655.2.patch ___ Python tracker <http://bugs.python.org/issue19655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Eli Bendersky added the comment: Nick, it shouldn't be hard to drop to 3.3, but I'm curious why would the 3.4 requirement break Fedora, or anything for that matter? Does Fedora regenerate the C implementation of the AST for some reason on every build? AFAIU, building Python from source with "make" should not do that. -- ___ Python tracker <http://bugs.python.org/issue19655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Eli Bendersky added the comment: On Fri, Apr 4, 2014 at 6:10 AM, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > Now make fails when system Python is older than 3.4. > > This is why the .h & .c files are checked in - someone just building Python doesn't need them regenerated at all. Only if one wants to *modify the AST*, he'll need an up-to-date Python. Otherwise we'll have to stick to the "oldest Python possible" for every script we use internally. I think this was discussed on the mailing list(s) at some point. -- ___ Python tracker <http://bugs.python.org/issue19655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20375] ElementTree: Document handling processing instructions
Eli Bendersky added the comment: On Thu, Apr 3, 2014 at 1:19 PM, Nikolaus Rath wrote: > > Nikolaus Rath added the comment: > > Thanks for the commit! > > My intention is to fix the behavior itself for 3.5 (see issue 9521), so I > think adding testcases for the old behavior in the meantime isn't necessary. > Fair enough. So you can close this issue, then. -- ___ Python tracker <http://bugs.python.org/issue20375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Eli Bendersky added the comment: Since there has mostly been support for this, I'll wait a couple more days and commit it unless someones objects or asks for more time for review. -- ___ Python tracker <http://bugs.python.org/issue19655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20375] ElementTree: Document handling processing instructions
Eli Bendersky added the comment: Thanks. Doc patch committed with some slight rewording. Would you like to prepare a separate patch for the tests, default branch only this time? -- versions: -Python 3.4 ___ Python tracker <http://bugs.python.org/issue20375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21028] ElementTree objects should support all the same methods as Element objects
Eli Bendersky added the comment: > Do you have concrete suggestions? Make the tree iterable? > > Add all element methods to the tree, implicitly forwarding to the root? > > Yes, that is the feature request. Add all the element methods to the > elementtree object. > > Implicitly forwarding to the root would be a reasonable way to do it, but > that is just an implementation detail. Porting over all methods of Element to ElementTree sounds like an overkill to me. How about just making a sensibly-behaving __iter__ for ElementTree? This should be easy because ElementTree already has a iter() method that behaves as needed (goes over all elements including root). Would iteration + perhaps clearer documentation solve most of the problem? -- ___ Python tracker <http://bugs.python.org/issue21028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20375] ElementTree: Document handling processing instructions
Eli Bendersky added the comment: I left some comments in Rietveld. There shouldn't be a problem getting these into 3.4 too - doc changes are usually excempt from most restrictions. -- ___ Python tracker <http://bugs.python.org/issue20375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21028] ElementTree objects should support all the same methods as Element objects
Eli Bendersky added the comment: Raymond, you are right that the APIs presented by Element and ElementTree are somewhat different. As Stefan mentioned, they were really meant to represent different things, but with time some "convenience" features crept in and made the difference somewhat more moot. Note that some methods/functions in ET give you the root element directly, rather than the tree. For example the XML function, or fromstring function. Also, the tree implements the iter() method, which is morally equivalent to Element.iter() on the root node. However, the tree (unlike Element) is not iterable. Element implements __getitem__, the tree does not. Currently, the first code snippet in the official documentation shows: import xml.etree.ElementTree as ET tree = ET.parse('country_data.xml') root = tree.getroot() Which makes the distinction between the tree and its root. Whether this is a great API (making tree and root distinct), I can't say, but we can't change it now. Do you have concrete suggestions? Make the tree iterable? Add all element methods to the tree, implicitly forwarding to the root? Improve documentation? -- ___ Python tracker <http://bugs.python.org/issue21028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20375] ElementTree: Document handling processing instructions
Eli Bendersky added the comment: The patch appears to contain code (tests) along with the documentation. Is this intended? This issue is not tagged properly if it is. I'd suggest to split them to separate patches. -- versions: +Python 3.5 -Python 2.7, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue20375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Eli Bendersky added the comment: Attaching patch that implements this. To make it easier, the patch only replaces the ASDL parser - not touching anything else and leaving the output intact. With this patch applied, when the Makefile is rerun it regenerates the actual AST code in: Include/Python-ast.h Python/Python-ast.c However, as the new parser generates exactly the same files, the code above is identical to the originals (hg diff shows nothing). In practice this means that no one building Python should notice this change, unless she's playing with the ASDL input file itself. The Makefile will not even regenerate these files unless the parser or the ASDL file were modified. I have some additional ideas - to be delayed for subsequent patches: 1. The existing Spark-based parser didn't have tests, but my parser does. I'll do something similar to test_tools.py, as Benjamin suggested (to test the parser only in source builds). 2. The code of asdl_c.py could be modernized and be made even cleaner. 3. The same is true of the generated C code for the AST. -- keywords: +patch Added file: http://bugs.python.org/file34679/new-asdl-parser.issue19655.1.patch ___ Python tracker <http://bugs.python.org/issue19655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Eli Bendersky added the comment: There were no serious objections bar the pre-release timing. Now that we're safely in 3.5 territory, can I go ahead and create a patch? Note that for purposes of review, the Github project linked in the original message is more convenient, IMHO -- ___ Python tracker <http://bugs.python.org/issue19655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14332] Better explain "junk" concept in difflib doc
Eli Bendersky added the comment: Revised patch LGTM. -- ___ Python tracker <http://bugs.python.org/issue14332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20653] Pickle enums by name
Eli Bendersky added the comment: Can you upload the new patch? -- ___ Python tracker <http://bugs.python.org/issue20653> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20653] Pickle enums by name
Eli Bendersky added the comment: > Many comments, Eli's and Serhey's code changes incorporated. Looks better, thanks. I left some comments in Rietveld. -- ___ Python tracker <http://bugs.python.org/issue20653> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20679] 3.4 cherry-pick: 587fd4b91120 improve Enum subclass behavior
Eli Bendersky added the comment: The discussion in #20653 is ongoing but I have to say I don't feel confident about this issue at all. If anything, I'd prefer to explicitly mark "advanced pickling support" for enums as provisional in 3.4 - this is a simple documentation fix Larry should have no qualms accepting into the RC. We can say that unless folks do funky things, pickling enums should work. But as for support for defining all kinds of strange custom pickling behaviors, this is not supported at this point. I think we all need some time to think about the interaction of enums with pickling and properly document all the scenarios we want, and - more importantly - don't want to support. Enum internals are too complex. Interaction with pickles is even trickier. We don't have to make these decisions in a rush right now. In short, I'm -1 on cherry picking, with +1 on putting provisional disclaimers in strategic places within the enum doc to save us from backwards compatibility worries in this domain for the upcoming cycle. -- ___ Python tracker <http://bugs.python.org/issue20679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20653] Pickle enums by name
Eli Bendersky added the comment: If you were enlightened about how to use the pickle protocols, please explains this better in the code. Currently the code says: # check for a supported pickle protocols, and if not present sabotage +# pickling, since it won't work anyway. +# if new class implements its own __reduce_ex__, do not sabotage +if classdict.get('__reduce_ex__') is None: +if member_type is not object: +methods = ('__getnewargs_ex__', '__getnewargs__', +'__reduce_ex__', '__reduce__') +if not any(map(member_type.__dict__.get, methods)): +_make_class_unpicklable(enum_class) The comments aren't very useful since they rephrase in different words what the code does, rather than explaining *why* it's being done. Please provide a patch with improved comments that make the following explicit: 1. What's expected of subclasses that want custom pickling. 2. What __new__ does if subclasses don't provide (1) - this "sabotaging" thing and under what conditions - what is the significance of the "member type is not object" test and the significance of the next test. @@ -192,8 +194,9 @@ class EnumMeta(type): (i.e. Color = Enum('Color', names='red green blue')). When used for the functional API: `module`, if set, will be stored in -the new class' __module__ attribute; `type`, if set, will be mixed in -as the first base class. +the new class' __module__ attribute; `qualname`, if set, will be stored +in the new class' __qualname__ attribute; `type`, if set, will be mixed +in as the first base class. Is it only me, or this comment change is unrelated to the pickling change? Also, this lacks change in the documentation. Your patch makes it possible for subclasses to provide custom pickling, overriding Enum's pickling. Some place should say explicitly what's expected of such classes (e.g. you rely on __reduce_ex__ taking precedence over __reduce__? what if subclasses rather define __reduce__? is it disallowed?) I'm not sure why you reopened this issue and retagged it to 3.4 when you've already commiteed the change to default (which is 3.5 now?) and issue #20679 exists explicitly to discuss the cherrypick? Nits: if classdict.get('__reduce_ex__') is None: can be replaced by: if '__reduce_ex__' not in classdict: And: if not any(map(member_type.__dict__.get, methods)): Would be more Pythonic as: if not any(m in member_type.__dict__ for m in methods) -- ___ Python tracker <http://bugs.python.org/issue20653> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20679] 3.4 cherry-pick: 587fd4b91120 improve Enum subclass behavior
Eli Bendersky added the comment: I left some comments in #20653 As for cherry-picking this into 3.4, I'm not sure. Ethan - what is the worst scenario this patch enables to overcome? Someone getting locked in to by-value pickling with certain enums in 3.4? -- ___ Python tracker <http://bugs.python.org/issue20679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20653] Pickle enums by name
Eli Bendersky added the comment: Ethan, the patch you committed here seems obscure to me. Why __reduce_ex__ and not __reduce__? Where are the accompanying documentation changes? Can you clarify more how the full logic of pickling now works - preferably in comments withing the code? -- versions: +Python 3.5 -Python 3.4 ___ Python tracker <http://bugs.python.org/issue20653> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20386] socket.SocketType enum overwrites import of _socket.SocketType
Eli Bendersky added the comment: Yep, the overriding of the type name was inadvertent. Nothing sacred about it, so Ethan's SocketKind is just as good. -- ___ Python tracker <http://bugs.python.org/issue20386> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20001] pathlib inheritance diagram too large
Eli Bendersky added the comment: The source for the diagram is here: https://docs.google.com/drawings/d/1F8do-1WL1sIGkZuiufcxcpZRtS0w4SwAowq-Uamrwt8/edit?usp=sharing Anyone - feel free to copy that doc over and create a new diagram with smaller whitespacing. Let me know if there are any problem accessing the doc. -- ___ Python tracker <http://bugs.python.org/issue20001> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18986] Add a case-insensitive case-preserving dict
Changes by Eli Bendersky : -- nosy: -eli.bendersky ___ Python tracker <http://bugs.python.org/issue18986> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19687] Fixes for elementtree integer overflow
Eli Bendersky added the comment: Thanks. I left some comments in the code review tool -- ___ Python tracker <http://bugs.python.org/issue19687> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19814] Document prefix matching behavior of argparse, particularly for parse_known_args
Changes by Eli Bendersky : -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue19814> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19799] Clarifications for the documentation of pathlib
Eli Bendersky added the comment: Committed in 90b56ec318b6 -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: +Python 3.2 -Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue19799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19814] Document prefix matching behavior of argparse, particularly for parse_known_args
Eli Bendersky added the comment: If I don't see any further objections I'll go ahead and commit this by the end of the week -- ___ Python tracker <http://bugs.python.org/issue19814> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19815] ElementTree segmentation fault in expat_start_ns_handler
Eli Bendersky added the comment: Thanks for the report & patches. Fixed in all active branches. -- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue19815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19814] Document prefix matching behavior of argparse, particularly for parse_known_args
Eli Bendersky added the comment: I don't see how these implementation details are relevant. The patch adds a link to the existing abbreviations section, which mentions parse_args - so it's clear that this behavior exists in both. Yes, #14910 (to which I pointed in the original message in this issue) is the long term solution, but it's only for Python 3.5; until then, as the mailing discussion has demonstrated, the documentation is unclear on this matter and needs clarification. -- ___ Python tracker <http://bugs.python.org/issue19814> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19799] Clarifications for the documentation of pathlib
Eli Bendersky added the comment: > > STINNER Victor added the comment: > > Which tool did you use to draw this schema? You may attach also the source > if someone would like to modify it in the future. > Sorry, but there's no source. I drew it graphically. But since I did it with Google Drive's drawing program, I can just share out a link to the editor - https://docs.google.com/drawings/d/1F8do-1WL1sIGkZuiufcxcpZRtS0w4SwAowq-Uamrwt8/edit?usp=sharing I suppose if someone wants to edit it they can copy the document and do that. -- ___ Python tracker <http://bugs.python.org/issue19799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19799] Clarifications for the documentation of pathlib
Changes by Eli Bendersky : Added file: http://bugs.python.org/file32871/pathlib-inheritance.png ___ Python tracker <http://bugs.python.org/issue19799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19799] Clarifications for the documentation of pathlib
Eli Bendersky added the comment: On Wed, Nov 27, 2013 at 6:21 AM, STINNER Victor wrote: > > STINNER Victor added the comment: > > Could you please attach the picture separatly? > > Done -- ___ Python tracker <http://bugs.python.org/issue19799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19814] Document prefix matching behavior of argparse, particularly for parse_known_args
Eli Bendersky added the comment: Here's a patch for 3.3; if it looks ok i'll merge it to default and also to 2.7 -- keywords: +patch Added file: http://bugs.python.org/file32870/issue19814.doc33.patch ___ Python tracker <http://bugs.python.org/issue19814> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19814] Document prefix matching behavior of argparse, particularly for parse_known_args
New submission from Eli Bendersky: Prefix matching behavior can lead to bugs when combined with parse_known_args. See this thread for more details: https://mail.python.org/pipermail/python-dev/2013-November/130601.html Issue #14910 deals with making it optional, but until 3.5 we'll have to do with a documentation warning. -- assignee: eli.bendersky components: Documentation messages: 204584 nosy: bethard, eli.bendersky, r.david.murray priority: high severity: normal status: open title: Document prefix matching behavior of argparse, particularly for parse_known_args versions: Python 2.7, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue19814> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19799] Clarifications for the documentation of pathlib
Eli Bendersky added the comment: Just in case it isn't: https://dl.dropboxusercontent.com/u/15602400/images/pathlib-inheritance.png -- ___ Python tracker <http://bugs.python.org/issue19799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19799] Clarifications for the documentation of pathlib
Eli Bendersky added the comment: Attaching a new patch. Hopefully the image will be viewable in the code review tool -- Added file: http://bugs.python.org/file32869/issue19799.2.patch ___ Python tracker <http://bugs.python.org/issue19799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14910] argparse: disable abbreviation
Changes by Eli Bendersky : -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue14910> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19624] Switch constants in the errno module to IntEnum
Changes by Eli Bendersky : -- keywords: -easy ___ Python tracker <http://bugs.python.org/issue19624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19799] Clarifications for the documentation of pathlib
Changes by Eli Bendersky : -- keywords: +patch Added file: http://bugs.python.org/file32858/issue19799.initial.patch ___ Python tracker <http://bugs.python.org/issue19799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19799] Clarifications for the documentation of pathlib
New submission from Eli Bendersky: Following up from Issue #19673; The initial patch clarifies the use cases of pure vs. concrete paths a bit and adds explicit signatures for the path class constructors (moving the construction discussion under the parent class). Also, IMHO an inheritance diagram from PEP 428 is very relevant and useful. Would you mind if I add a .png for the pathlib rst doc? -- assignee: eli.bendersky components: Documentation messages: 204477 nosy: eli.bendersky, pitrou priority: normal severity: normal stage: patch review status: open title: Clarifications for the documentation of pathlib type: enhancement versions: Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue19799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19673] PEP 428 implementation
Eli Bendersky added the comment: Thanks for the clarifications, Antoine. I'll see if I can come up with a doc patch that will try to emphasize these points. I'll probably just open a new, doc-issue to stop overloading this one. -- ___ Python tracker <http://bugs.python.org/issue19673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Eli Bendersky added the comment: On Sun, Nov 24, 2013 at 2:58 PM, Larry Hastings wrote: > > Larry Hastings added the comment: > > The rule is, no new features. Bug and security fixes from now on. > > It isn't always clear whether or not something is a new "feature". In the > case of such ambiguity, the decision is up to the sole discretion of the > release manager. > > If you seriously want to check in this thing (*sigh*), I'll take a look at > it. But you'll have to point me at either a patch that applies cleanly to > trunk, or a repository somewhere online with the patch already applied to > trunk. > There really is no urgency here. I don't won't to add needless work onto your place, and am fine with just leaving it be until the 3.4 branch is cut and landing it on the default branch aimed for 3.5 after that. -- ___ Python tracker <http://bugs.python.org/issue19655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Eli Bendersky added the comment: Larry Hastings added the comment: > > Are the generated files *byte for byte* the same as produced by the > existing parser generation process? > Correct. The generator runs during the build (in the Makefile), but only if the files were out-of-date. It takes Python.asdl and produces Python-ast.h and Python-ast.c; the latter two are compiled into the CPython executable. The .h/.c files produced by my alternative generator are exactly identical to the ones in there now. I don't feel strongly about this, but I may need a refresher in the release process rules. From today and until Feb 23rd, 2014 - are we not supposed to be adding new features/PEPs or are we also not supposed to do any code refactorings and/or any changes at all unless those are directly related to fixing a specific bug/issue? -- ___ Python tracker <http://bugs.python.org/issue19655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19673] PEP 428 implementation
Eli Bendersky added the comment: > > > Antoine Pitrou added the comment: > > > Another question: What is the real purpose of pure paths? One thing I > > see is using them to, say, manipulate Windows paths on a Posix machine > > for some reason. > > Yes. Also, if some reason you want to be sure you're only doing path > computations, not I/O. > "Sure" in what sense, like accidentally? IIUC path manipulation/computation operations don't really call into the OS - only some methods do. > > Any others? Could this also be achieved with just having Paths? > > I don't see how having just Paths would achieve this, unless you think > it's sane to pretend to walk a Windows directory under Unix :-) > I mean, having Path, WindowsPath and PosixPath without the pure counterparts. You usually use Path, but say you want to manipulate Windows paths on a Linux box. So you instantiate a WindowsPath explicitly and do your thing on it. You can't (NotImplementedError) call any methods that would call into the OS, and that's it. I'm just trying to look at the module from the POV of someone who sees it for the first time, wondering "why do I have two kinds of things here, and when would I want to use each? could I just use Path 99.9% of the time and forget about the other options?". If that's true, we may want to reflect it in the documentation explicitly - I believe this will make the module easier to understand. -- ___ Python tracker <http://bugs.python.org/issue19673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19673] PEP 428 implementation
Eli Bendersky added the comment: It's just a matter of looking for a familiar pattern while going over an unfamiliar doc page, I guess. I'll give it a try and see if it helps. Another question: What is the real purpose of pure paths? One thing I see is using them to, say, manipulate Windows paths on a Posix machine for some reason. Any others? Could this also be achieved with just having Paths? [sorry for coming long after the party ended; my motivation here is mainly curiosity - maybe by looking at it from a newbie point of view I can improve the documentation in a way that will be friendlier for people unfamiliar with the new library] -- ___ Python tracker <http://bugs.python.org/issue19673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19673] PEP 428 implementation
Eli Bendersky added the comment: Yes, I've seen that. What I mean is that there's no clear signature defined with each argument explained, as the other stdlib documentation usually does. Section 11.1.2.1 uses a more descriptive approach, while I was also expecting a formal specification. I can propose a patch to improve this, if you don't object. -- ___ Python tracker <http://bugs.python.org/issue19673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19673] PEP 428 implementation
Eli Bendersky added the comment: Antoine, am I missing something - I don't see documentation for the construction of Path/PurePath? -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue19673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Eli Bendersky added the comment: Does anyone have comments on the code or can I prepare a patch for default? Would it make sense to wait with this until the 3.4 branch is created or can I just commit to default? Note that this change is not a new feature and is essentially a no-op as far as the resulting CPython executable - it's just tweaking the build process to generate the same data in a different way. -- ___ Python tracker <http://bugs.python.org/issue19655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13633] Automatically convert character references in HTMLParser
Changes by Eli Bendersky : -- nosy: -eli.bendersky ___ Python tracker <http://bugs.python.org/issue13633> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Eli Bendersky added the comment: Larry, ease your worries: note that I only tagged this on version 3.5! That said, this parser runs during the build and produces a .h file and .c file - these partake in the build; I verified that the generated code is *identical* to before, so there's not much to worry about. Still, I don't see a reason to land this before the beta branches. I'll do it onto the default branch after this weekend (assuming the reviews come through). -- ___ Python tracker <http://bugs.python.org/issue19655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Eli Bendersky added the comment: FWIW, asdl_c.py could use some "modernization", but I'll defer this to a later cleanup in order to do things gradually. The same can be said for the Makefile rules - they can be simpler and more efficient (no need to invoke asdl_c / parse the ASDL twice, for example). Incidentally, where would be a good place to put the ASDL tests? Can/should we reach into the Parser/ directory when running the Python regression tests (will this even work in an installed Python)? Or should I just plop asdl_test.py alongside asdl.py and mention that it should be run when asdl.py changes? -- ___ Python tracker <http://bugs.python.org/issue19655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
Changes by Eli Bendersky : -- nosy: +eric.snow ___ Python tracker <http://bugs.python.org/issue19655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19655] Replace the ASDL parser carried with CPython
New submission from Eli Bendersky: It was mentioned in one of the recent python-dev threads that making the Python code-base simpler to encourage involvement of contributors is a goal, so I figured this may be relevant. I've recently written a new parser for the ASDL specification language from scratch and think it may be beneficial to replace the existing parser we use: * The existing parser uses an external parser-generator (Spark) that we carry around in the Parser/ directory; the new parser is a very simple stand-alone recursive descent, which makes it easier to maintain and doesn't require a familiarity with Spark. * The new code is significantly smaller. ~400 LOC for the whole stand-alone parser (asdl.py) as opposed to >1200 LOC for the existing parser+Spark. * The existing asdl.py is old code and was only superficially ported to Python 3.x - this shows, and isn't a good example of using modern Python techniques. My asdl.py uses Python 3.4 with modern idioms like dict comprehensions, generators and enums. For a start, it may be easier to review the parser separately and not as a patch file. I split it to a stand-alone project here: https://github.com/eliben/asdl_parser The asdl.py there is a drop-in replacement for Parser/asdl.py; asdl_c.py is for Parser/asdl_c.py - with tiny modifications to interface the new parser (mainly getting rid of some Spark-induced quirks). The AST .c and .h files produced are identical. The repo also has some tests for the parser, which we may find useful in adding to the test suite or the Parser directory. -- assignee: eli.bendersky components: Build messages: 203376 nosy: brett.cannon, eli.bendersky, ncoghlan priority: normal severity: normal stage: patch review status: open title: Replace the ASDL parser carried with CPython type: enhancement versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue19655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19176] DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser
Eli Bendersky added the comment: Thanks for the report, Martin. I'll take a look once I get some time -- ___ Python tracker <http://bugs.python.org/issue19176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16425] minidom replaceChild(new_child, old_child) removes new_child even if in another document
Changes by Eli Bendersky : -- nosy: -eli.bendersky ___ Python tracker <http://bugs.python.org/issue16425> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19452] ElementTree iterparse documentation
Changes by Eli Bendersky : -- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue19452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19452] ElementTree iterparse documentation
Changes by Eli Bendersky : -- stage: -> needs patch ___ Python tracker <http://bugs.python.org/issue19452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19452] ElementTree iterparse documentation
Eli Bendersky added the comment: Thanks for the report, Peter. This is indeed a documentation fix for Python 3.3; note that in 3.4 (default branch), the restriction was lifted and iterparse now accepts any iterable sequence. The documentation also reflects that (saying that 'events' is a sequence). I'll update the 3.3 docs to address this issue. -- ___ Python tracker <http://bugs.python.org/issue19452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's doctype() method missing
Eli Bendersky added the comment: On Mon, Oct 28, 2013 at 6:00 AM, Martin Panter wrote: > > Martin Panter added the comment: > > The best way to work around it for me is just to ignore the warning. It > doesn’t really worry me that much, I only noticed it while porting a > program to Python 3 anyway. So if you don’t want to touch the 2.7 branch I > can live with that :) > I'd rather not. 2.7.x is in maintenance mode - we'll fix serious bugs and may change trivial things. But in this case, since the effects are hardly serious we should consider the danger of mucking with code in a very stable maintenance branch. While this issue may seem simple at the surface, it's not. That's because ET in 3.3+ is quite different from ET in 3.2- (including 2.7-). In 3.3 ET underwent major changes, and its testing infrastructure was greatly improved too. Back-porting across the 3.3 boundary is risky because it's hard to foresee the effects (i.e. interactions between the C accelerator and the Python module). -- ___ Python tracker <http://bugs.python.org/issue14007> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's doctype() method missing
Eli Bendersky added the comment: Martin, do you see a way to work around the problem? I'm not sure it's serious enough to warrant committing to the 2.7.x branch at this point. -- ___ Python tracker <http://bugs.python.org/issue14007> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16817] test___all__ affects other tests by doing too much importing
Eli Bendersky added the comment: This is superceded by: http://bugs.python.org/issue18906 -- superseder: -> Create a way to always run tests in subprocesses within regrtest ___ Python tracker <http://bugs.python.org/issue16817> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14332] Better explain "junk" concept in difflib doc
Eli Bendersky added the comment: Tim, any suggestions? -- ___ Python tracker <http://bugs.python.org/issue14332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9398] Unify sys.settrace and sys.setprofile tests
Changes by Eli Bendersky : -- nosy: -eli.bendersky ___ Python tracker <http://bugs.python.org/issue9398> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8957] strptime(.., '%c') fails to parse output of strftime('%c', ..) in some locales
Changes by Eli Bendersky : -- nosy: -eli.bendersky ___ Python tracker <http://bugs.python.org/issue8957> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9317] Incorrect coverage file from trace test_pickle.py
Changes by Eli Bendersky : -- nosy: -eli.bendersky ___ Python tracker <http://bugs.python.org/issue9317> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15964] SyntaxError in asdl when building 2.7 with system Python 3
Changes by Eli Bendersky : -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue15964> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19106] Prepare .hgtouch and Tools/hg/hgtouch.py to run on the bots
Eli Bendersky added the comment: I think this issue can be closed, since Martin's touch step runs on the bots successfully, and the ASDL dependencies in .hgtouch were fixed. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue19106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19106] Prepare .hgtouch and Tools/hg/hgtouch.py to run on the bots
Eli Bendersky added the comment: +nick,guido,benjamin: in case you're interested in the discussion that takes place in the most recent messages of this issue -- nosy: +benjamin.peterson, gvanrossum, ncoghlan ___ Python tracker <http://bugs.python.org/issue19106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com