[issue13280] argparse should use the new Formatter class
Changes by paul j3 ajipa...@gmail.com: -- nosy: +paul.j3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13280 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18694] getxattr on Linux ZFS native filesystem happily returns partial values
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18694 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18690] memoryview not considered a sequence
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +mark.dickinson, skrah type: behavior - enhancement versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18690 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18685] Restore re performance to pre-PEP393 level
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +tim_one ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18226] IDLE Unit test for FormatParagrah.py
Terry J. Reedy added the comment: I got rid of the shutdown warning by replacing EditorWindow with a simple mock, as explained in the test file. Doing so also reduced the running time from about .40 seconds to .25 (it was 1.0+ before I reduced the redundancy of the tests). All the asserts passed after the substitution except for the last. For some reason, the 2nd line of the comment block looses its \n so that lines 2 and 3 get pasted together. I am baffled since the block is almost the same as the previous one. For the moment, I just commented out that test. -- Added file: http://bugs.python.org/file31204/18226FormatPara9.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18226 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18381] unittest warnings counter
Michael Foord added the comment: Looks good to me, except the backslash continuation is unneeded. Needs documentation. -- assignee: - michael.foord ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17974] Migrate unittest to argparse
Michael Foord added the comment: The patch looks like an improvement. Does it maintain the ability to pass the discovery arguments positionally and by keyword? If so then it can go in. I like the improved error reporting for nonsenical input to unittest.main. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17974 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17974] Migrate unittest to argparse
Serhiy Storchaka added the comment: Does it maintain the ability to pass the discovery arguments positionally and by keyword? Yes, of course. Only such command line are not supported more: ./python Lib/test/test_colorsys.py discover -v Lib/test/test_json/ or ./python -m test.test_colorsys discover -v Lib/test/test_json/ But this looks as an unintentional and senseless ability. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17974 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Stefan Behnel added the comment: Here is a patch that cleans up the current implementation to avoid making the result of iterparse() an IncrementalParser (with all of its new API). Please note that the tulip mailing list is not an appropriate place to discuss additions to the XML libraries, and ElementTree in particular. -- nosy: +scoder Added file: http://bugs.python.org/file31205/iterparse_cleanup.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18688] Document undocumented Unicode object API
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18688 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Changes by Stefan Behnel sco...@users.sourceforge.net: -- components: +XML ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Stefan Behnel added the comment: Copying the discussion between Antoine and me from python-dev: IMO it should mimic the interface of the TreeBuilder, which calls the data reception method feed() and the termination method close(). There is no reason to add yet another set of methods names just to do what others do already. Well, the difference here is that after calling eof_received() you can still (and should) call events() once to get the last events. I think it would be weird if you could still do something useful with the object after calling close(). Also, the method names are not invented, they mimick the PEP 3156 stream protocols: http://www.python.org/dev/peps/pep-3156/#stream-protocols I see your point about close(). I assume your reasoning was to make the IncrementalParser an arbitrary stream end-point. However, it doesn't really make all that much sense to connect an arbitrary data source to it, as the source wouldn't know that, in addition to passing in data, it would also have to ask for events from time to time. I mean, you could do it, but then it would just fill up the memory with parser events and loose the actual advantages of incremental parsing. So, in a way, the whole point of the class is to *not* be an arbitrary stream end-point. Anyway, given that there isn't really the One Obvious Way to do it, maybe you should just add a docstring to the class (ahem), reference the stream protocol as the base for its API, and then rename it to IncrementalStreamParser. That would at least make it clear why it doesn't really fit with the rest of the module API (which was designed some decade before PEP 3156) and instead uses its own naming scheme. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Stefan Behnel added the comment: Actually, let me take that last paragraph back. There is an Obvious Way to do it, and that's the feed() and close() methods. They are the existing and established ElementTree interface for incremental parsing. The fact that close() doesn't clean up all state is IMHO a minor issue. The state will be cleaned up automatically once the iteration terminates, and that's the normal behaviour of iterators. So it actually fits both protocols quite nicely. I'd just leave the stream protocol out completely here. For one, the implementation isn't complete anyway (the connection_*() methods don't make much sense), and as I said, it's not very useful to consider the parser a general end-point to that protocol. I'd also suggest returning the iterator over the remaining events from close(), just like the TreeBuilder returns the tree. That covers the (less common) use case of first parsing everything and then processing the events. I'll add another patch that does that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Changes by Stefan Behnel sco...@users.sourceforge.net: Added file: http://bugs.python.org/file31206/iterparse_api_cleanup.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18606] Add statistics module to standard library
Oscar Benjamin added the comment: One small point: I think that the argument `m` to variance, pvariance, stdev and pstdev should be renamed to `mu` for pvariance/pstdev and `xbar` for variance/stdev. The doc-strings should carefully distinguish that `mu` is the true/population mean and `xbar` is the estimated/sample mean and refer to this difference between the function variants. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18606 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18695] os.statvfs() not working well with unicode paths
New submission from Giampaolo Rodola': From: https://code.google.com/p/psutil/issues/detail?id=416 # -*- coding: utf-8 -*- from __future__ import unicode_literals import os, errno name = ƒőő try: os.mkdir(name) except OSError as err: if err.errno != errno.EEXIST: raise os.statvfs(name) The script above works fine on Python 3.3 but on 2.7 you'll get: Traceback (most recent call last): File foo.py, line 10, in module os.statvfs(name) UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128) Patch in attachment fixes the issue. -- components: Unicode files: statvfs.patch keywords: needs review, patch messages: 194726 nosy: ezio.melotti, giampaolo.rodola priority: normal severity: normal status: open title: os.statvfs() not working well with unicode paths versions: Python 2.7 Added file: http://bugs.python.org/file31207/statvfs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18695 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18685] Restore re performance to pre-PEP393 level
Antoine Pitrou added the comment:
I get the same kind of results as Serhiy:
$ python3.2 -m timeit -s import re; f = re.compile(b'abc').search; x =
b'x'*10 f(x)
1 loops, best of 3: 81.7 usec per loop
$ python3.2 -m timeit -s import re; f = re.compile('abc').search; x =
'x'*10 f(x)
1 loops, best of 3: 31.1 usec per loop
$ python3.2 -m timeit -s import re; f = re.compile('abc').search; x =
'\u20ac'*10 f(x)
1 loops, best of 3: 31.1 usec per loop
Unpatched 3.4:
$ ./python -m timeit -s import re; f = re.compile(b'abc').search; x =
b'x'*10 f(x)
1 loops, best of 3: 81.6 usec per loop
$ ./python -m timeit -s import re; f = re.compile('abc').search; x =
'x'*10 f(x)
1 loops, best of 3: 163 usec per loop
$ ./python -m timeit -s import re; f = re.compile('abc').search; x =
'\u20ac'*10 f(x)
1 loops, best of 3: 190 usec per loop
Patched 3.4:
$ ./python -m timeit -s import re; f = re.compile(b'abc').search; x =
b'x'*10 f(x)
1 loops, best of 3: 54.4 usec per loop
$ ./python -m timeit -s import re; f = re.compile('abc').search; x =
'x'*10 f(x)
1 loops, best of 3: 54.2 usec per loop
$ ./python -m timeit -s import re; f = re.compile('abc').search; x =
'\u20ac'*10 f(x)
1 loops, best of 3: 54.5 usec per loop
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18685
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Stefan Behnel added the comment: Thinking about the original patch some more - I wonder why it doesn't use a wrapper for TreeBuilder to process the events. Antoine, is there a reason why you had to add this _setevents() method to the XMLParser, instead of making the IncrementalParser an IncrementalTreeBuilder? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Stefan Behnel added the comment: Oh, and could we reopen this ticket, please? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Antoine Pitrou added the comment: Antoine, is there a reason why you had to add this _setevents() method to the XMLParser, instead of making the IncrementalParser an IncrementalTreeBuilder? The point is not to build a tree of potentially unbounded size (think XMPP). The point is to yield events in a non-blocking way (iterparse() is blocking, which makes it useless for non-blocking applications). An IncrementalTreeBuilder wouldn't have much point IMO. It is not more costly to accumulate a string and parse it at the end, than to progressively build a growing XML tree. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Changes by Antoine Pitrou pit...@free.fr: -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Antoine Pitrou added the comment: About the patch: I think changing the API names now that alpha1 has been released is a bit gratuitous. I would like to keep the encapsulation part but ditch the naming changes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Stefan Behnel added the comment: The point is not to build a tree of potentially unbounded size (think XMPP). The point is to yield events in a non-blocking way (iterparse() is blocking, which makes it useless for non-blocking applications). Ok, but that's the only difference. Instead of getting the events from the parser, you could equally well get them from the TreeBuilder, also in a non-blocking way. Sticking this functionality into a parser target object has the advantage that the parser interface wouldn't have to change. So, instead of introducing an entirely new parser interface, we'd just add a class that can be used as a parser target and provides an additional events() method. That's a substantially less invasive API change. An IncrementalTreeBuilder wouldn't have much point IMO. It is not more costly to accumulate a string and parse it at the end, than to progressively build a growing XML tree. I don't think I understand what you mean. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Stefan Behnel added the comment: About the patch: I think changing the API names now that alpha1 has been released is a bit gratuitous. Sorry for being late, but I can't see it being my fault. A change in an alpha release is still way better than a change after a final release. Eventually, lxml will have to go on par here, so it's better to get it right now, before any harm is done. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Antoine Pitrou added the comment: The point is not to build a tree of potentially unbounded size (think XMPP). The point is to yield events in a non-blocking way (iterparse() is blocking, which makes it useless for non-blocking applications). Ok, but that's the only difference. Instead of getting the events from the parser, you could equally well get them from the TreeBuilder, also in a non-blocking way. But your TreeBuilder is also growing a tree internally, and therefore eating more and more memory, right? I don't see the point of stuffing different kinds of functionality inside a single class. It makes the intended use less obvious, and errors more likely. Right now, IncrementalParser has a simple API, and there's a single way to use it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Antoine Pitrou added the comment: A change in an alpha release is still way better than a change after a final release. But worse than no change at all. Arguing about API naming is a bit futile, *especially* when the ship has sailed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Stefan Behnel added the comment: But worse than no change at all. Arguing about API naming is a bit futile, *especially* when the ship has sailed. rantIt's easy to say that as a core developer with commit rights who can simply hide changes in a low frequented bug tracker without notifying those who have to know about these changes./rant It's pure luck I noticed this change during the alpha release cycle. I'm also not arguing about naming. I'm questioning the design, trying to get it into a shape that fits the existing APIs. Why do we need two incremental parsing interfaces in one and the same library that use completely different method names, although doing otherwise exactly the same? Why should the type of the *result* of the parsing process change the method name that you need to call to *insert* data into the parser? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Stefan Behnel added the comment: But IncrementalParser uses an XMLParser internally, which in turn uses a TreeBuilder internally. So what exactly is your point? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Antoine Pitrou added the comment: But IncrementalParser uses an XMLParser internally, which in turn uses a TreeBuilder internally. So what exactly is your point? Well, I would rather like to understand yours. Whatever IncrementalParser uses internally needn't impact what API it exposes to the user. (as a matter of fact, iterparse() doesn't expose a TreeBuilder-like API, either) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Stefan Behnel added the comment: Well, I would rather like to understand yours. My point is that the IncrementalParser uses a TreeBuilder that builds an XML tree in the back. So I'm wondering why you are saying that it doesn't build a tree. Whatever IncrementalParser uses internally needn't impact what API it exposes to the user. And in fact, we don't even need an IncrementalParser, because XMLParser already *has* an incremental parsing interface. All that's missing is the bit that collects and exposes the events. And my point is that we shouldn't duplicate the existing *data entry* interface for that, especially not under different names for identical functionality, but only add an interface to access those events as *output*, i.e. to add the bit of the API that's actually missing. As an analogon, what would you say if I asked for adding a new, separate Mapping interface to Python that uses the method name set_value() instead of __setitem__() because I want it to read data from the hard drive and not from memory? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Antoine Pitrou added the comment: rantIt's easy to say that as a core developer with commit rights who can simply hide changes in a low frequented bug tracker without notifying those who have to know about these changes./rant It's pure luck I noticed this change during the alpha release cycle. It is the rule for most stdlib improvements that they go directly through the bug tracker. Most core developers and outsiders would feel swamped by the traffic if all feature additions went through the mailing-list. I'm honestly baffled that you think I am trying to hide things. Why do you think I would feel guilty about proposing an addition, or try to sneak things inside xml.etree? (yes, we could theoretically run polls for every addition we propose, collect and discuss the results, and iterate several times until the outcome is successful; I don't think any of us has the bandwidth to do that, which is why that practice is only used for game-making changes (i.e. PEP material)) I'm also not arguing about naming. I'm questioning the design, trying to get it into a shape that fits the existing APIs. Why do we need two incremental parsing interfaces in one and the same library that use completely different method names, although doing otherwise exactly the same? Well, unless I'm missing something, TreeBuilder doesn't do parsing, it takes already parsed data: it has a start() method to open a tag, and a data() method to add raw text inside that tag. IncrementalParser, OTOH, has a data_received() method to which you pass a piece of non-parsed XML string. The other incremental parsing API is actually iterparse(). The reason I proposed IncrementalParser is that iterparse() is useless for non-blocking applications. IncrementalParser produces the same kind of output as iterparse(), but control of when to feed it data is transferred to the user of the API. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Stefan Behnel added the comment: TreeBuilder doesn't do parsing, it takes already parsed data: it has a start() method to open a tag, and a data() method to add raw text inside that tag. That is correct. However, the XMLParser has a feed() method that sends new data into the parser, and a close() method that tells the parser that it's done. So there already is an incremental parsing interface, and your change is duplicating that interface under a different name. Specifically, IncrementalParser has exactly the same interface as XMLParser when it comes to entering data, but uses different method names for it. This is a Bad Design because it introduces an unnecessary inconsistency in the API. However, what you are trying to change is not the way data is *entered* into the parser. What you are after is to change the way the *parsed* data is *presented* to the user. That is not the responsibility of the parser, it's the responsibility of the TreeBuilder. In your code, the TreeBuilder builds a tree, and the new interface *additionally* collects parse events in a list. So, the right way to do it would be to change the parser *target* to do both, i.e. to build a tree and collect events at the same time. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Antoine Pitrou added the comment: Well, I would rather like to understand yours. My point is that the IncrementalParser uses a TreeBuilder that builds an XML tree in the back. So I'm wondering why you are saying that it doesn't build a tree. Unless I'm reading it wrong, when _setevents() is called, the internal hooks are rewired to populate the events list, rather than call the corresponding TreeBuilder methods. So, yes, there's a TreeBuilder somewhere, but it stands unused. (the _setevents() method already existed on the C impl, by the way. I added it to the Python impl to make things more regular and avoid two separate iterparse() implementations) And my point is that we shouldn't duplicate the existing *data entry* interface for that, especially not under different names for identical functionality, but only add an interface to access those events as *output*, i.e. to add the bit of the API that's actually missing. What difference would that make? In the end, you mustn't mix event-driven/non-blocking and cumulative/blocking styles of programming, so having two separate APIs doesn't strike me as a problem (it may be a good thing actually, for clarity reasons). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Stefan Behnel added the comment: Unless I'm reading it wrong, when _setevents() is called, the internal hooks are rewired to populate the events list, rather than call the corresponding TreeBuilder methods. So, yes, there's a TreeBuilder somewhere, but it stands unused. Yes, you *are* reading it wrong. For example, the start callback calls self._start_list, which in turn calls self.target.start(), thus calling into the TreeBuilder. That's the thing that constructs the elements that the IncrementalParser collects in its events list. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Eli Bendersky added the comment: rantIt's easy to say that as a core developer with commit rights who can simply hide changes in a low frequented bug tracker without notifying those who have to know about these changes./rant It's pure luck I noticed this change during the alpha release cycle. What *are* you talking about? Who is trying to hide anything? Don't you see the history of the bug? Antoine opened it very... openly... and we discussed it. Also, committing to pre-alpha trunk is not a sailed ship - if there are problems, things can be easily fixed. Please stop complaining and learn to use the tools properly. Here's one tip: http://mail.python.org/mailman/listinfo/python-bugs-list - subscribe to it and use your mail client's filtering to see new bugs on topics that interest you. It isn't very hard. Another tip: http://mail.python.org/mailman/listinfo/python-checkins - subscribe to it and use your mail client's filtering to see new checkins on topics that interest you. It isn't hard either. Tip #3: ask to be added to the experts list for ET. No one would object to that, and it would increase the likelihood that people add you to the nosy list directly for ET-related issues (particularly added features). Now back to a productive discussion please... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Stefan Behnel added the comment: ask to be added to the experts list for ET Already done, see the corresponding python-dev thread. Now back to a productive discussion please... I think we already are. Keep reading through the rest of the posts. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Eli Bendersky added the comment: On Fri, Aug 9, 2013 at 8:44 AM, Stefan Behnel rep...@bugs.python.orgwrote: Stefan Behnel added the comment: ask to be added to the experts list for ET Already done, see the corresponding python-dev thread. Done. 747970502b23 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Antoine Pitrou added the comment: Unless I'm reading it wrong, when _setevents() is called, the internal hooks are rewired to populate the events list, rather than call the corresponding TreeBuilder methods. So, yes, there's a TreeBuilder somewhere, but it stands unused. Yes, you *are* reading it wrong. For example, the start callback calls self._start_list, which in turn calls self.target.start(), thus calling into the TreeBuilder. That's the thing that constructs the elements that the IncrementalParser collects in its events list. Ah, indeed, my bad. That said, using a custom TreeBuilder-alike would necessitate changes in the C implementation of XMLParser. (which, I suppose, is why the _setevents hack exists in the first place) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18696] In unittest.TestCase.longMessage doc remove a redundant sentence
New submission from py.user: http://docs.python.org/3/library/unittest.html#unittest.TestCase.longMessage If set to True then any explicit failure message you pass in to the assert methods will be appended to the end of the normal failure message. The normal messages contain useful information about the objects involved, for example the message from assertEqual shows you the repr of the two unequal objects. Setting this attribute to True allows you to have a custom error message in addition to the normal one. the last sentence duplicates the first one -- assignee: docs@python components: Documentation files: issue.diff keywords: patch messages: 194748 nosy: docs@python, py.user priority: normal severity: normal status: open title: In unittest.TestCase.longMessage doc remove a redundant sentence type: enhancement versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file31208/issue.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18696 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18685] Restore re performance to pre-PEP393 level
Matthew Barnett added the comment: @Antoine: Are you on the same OS as Serhiy? IIRC, wasn't the performance regression that wxjmfauth complained about in Python 3.3 apparent on Windows, but not on Linux? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18696] In unittest.TestCase.longMessage doc remove a redundant sentence
R. David Murray added the comment: I think the text is OK as it stands. The first sentence is a technical description of the result of setting the attribute, the last sentence is a conceptual discussion of why you would want to set the attribute. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18696 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18670] Using read_mime_types function from mimetypes module gives resource warning
R. David Murray added the comment: Since the TESTFN file is created only in this test, rather than use a tearDown method, it would be better to use addCleanup in the test method itself. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18670 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Stefan Behnel added the comment: Ok, finally. ;) Can we agree on discarding the current implementation for now and then rewriting it based on a tree builder instead of a parser wrapper? Because we'd need to change internal code is not a good argument for adding a new API, IMHO. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18655] GUI apps take long to launch on Windows
Terry J. Reedy added the comment: This tracker is for patching CPython, not Windows or 3rd-party C libraries. Ramchandra is right, Python does not display windows. In the cases you mention, this is done by 3-rd party cross-platform graphics libraries interacting with Windows' native graphics system. The fact that you have noticed the slow first launch with all 3 suggests that the problem is generic to Windows and how it initializes dlls that connect to Windows graphics system. I have the impression that this phenomenon is limited neither to Python nor to gui apps. One 'remedy' used by some apps is to load a 'quickstart' background process as part of startup. But that makes the boot or login process longer. In the absence of evidence that there is anything specifically wrong and fixable in CPython, I am closing this. Tim or Brian, if either of you think me mistaken, please re-open. -- nosy: +brian.curtin, terry.reedy, tim.golden resolution: - invalid stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18655 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Stefan Behnel added the comment: What about this idea: instead of changing the internal C implementation, we could provide a simple parser target wrapper class (say, EventBuilder) that the parser would simply recognise with isinstance(). Then it would unpack the wrapped target and configure itself as it currently does. So you'd use it like this: target = EventBuilder(TreeBuilder()) parser = XMLParser(target=target) parser.feed(some_xml_data) print list(target.events()) I mean, it doesn't really matter if the implementation is a fake, as long as the API is right. And the only API that the EventBuilder has is its events() method that returns the iterator. The EventBuilder implementation would then be class EventBuilder: def __init__(self, target=None): if target is None: target = TreeBuilder() self._target = target self._events = [] def events(self): # existing code for distructive iteration over self._events goes here ... and the rest would be done by the XMLParser() constructor, i.e. it would register the _events list in the expat callbacks. What do you think? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18697] Unify arguments names in Unicode object C API documentation
New submission from Serhiy Storchaka: In declarations of Unicode object C API functions in Doc/c-api/unicode.rst the first Unicode object argument has different names: unicode, str, u, s. It will be good to unify these names. Of course there is no need to change reasonable argument names for such functions as PyUnicode_Concat() or PyUnicode_CopyCharacters(). -- assignee: docs@python components: Documentation, Unicode keywords: easy messages: 194755 nosy: docs@python, ezio.melotti, haypo, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Unify arguments names in Unicode object C API documentation type: enhancement versions: Python 2.7, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18697 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18688] Document undocumented Unicode object API
Serhiy Storchaka added the comment: It will be good first resolve issue18697. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18688 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18685] Restore re performance to pre-PEP393 level
Antoine Pitrou added the comment: @Antoine: Are you on the same OS as Serhiy? I don't know, I'm under Linux with gcc (on a x86-64 machine) :-) IIRC, wasn't the performance regression that wxjmfauth complained about in Python 3.3 apparent on Windows, but not on Linux? I don't know, but I'm not willing to give any attention to something reported by jmfauth. He's very far in the trollzone, as far as I'm concerned. However, if you are under Windows and can give it a try, it would be nice to have performance numbers for Serhiy's patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Antoine Pitrou added the comment: Can we agree on discarding the current implementation for now and then rewriting it based on a tree builder instead of a parser wrapper? Only if it actually brings something (feature-wise, performance-wise, maintenance-wise, whatever) that the current implementation doesn't have. Otherwise, I'd rather check in the simple inheritance-to-composition change. I'm sorry that you noticed this after the alpha. I would have had a lower threshold for changes if you had manifested when I proposed the feature. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18600] email.policy doc example passes 'policy' to as_string, but that doesn't work
R. David Murray added the comment: Turns out even with as_string accepting a policy keyword, the example still failed. It needs to be generating a bytes object, not a string. Before I even realized that, though, I decided I wanted to add as_bytes (and __bytes__). So the attached patch does that: adds policy to as_string, and adds new methods as_bytes and __bytes__ to Message. This patch is only for 3.4. The 3.3 patch will just delete that part of the policy example, so I'm not going to bother to upload it. -- keywords: +patch stage: needs patch - patch review Added file: http://bugs.python.org/file31209/as_string_policy.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18600 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18685] Restore re performance to pre-PEP393 level
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18685] Restore re performance to pre-PEP393 level
Matthew Barnett added the comment:
With the patch the results are:
C:\Python34\python.exe -m timeit -s import re; f = re.compile(b'abc').search;
x = b'x'*10 f(x)
1 loops, best of 3: 113 usec per loop
C:\Python34\python.exe -m timeit -s import re; f = re.compile('abc').search; x
= 'x'*10 f(x)
1 loops, best of 3: 113 usec per loop
C:\Python34\python.exe -m timeit -s import re; f = re.compile('abc').search; x
= '\u20ac'*10 f(x)
1 loops, best of 3: 113 usec per loop
I'm most impressed! :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18685
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18683] Core dumps on CentOS
STINNER Victor added the comment: It might be related to #14432. Could you try patch Python with a patch of the issue #14432? -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18683 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18685] Restore re performance to pre-PEP393 level
Serhiy Storchaka added the comment: I'm under 32-bit Linux with gcc 4.6.3. The above test is only one example for which I expect largest difference. I suppose other tests will show a gain too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15301] os.chown: OverflowError: Python int too large to convert to C long
Antoine Pitrou added the comment: The Windows buildbots are broken: == ERROR: test_chown_uid_gid_arguments_must_be_index (test.test_os.MakedirTests) -- Traceback (most recent call last): File E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\test\test_os.py, line 875, in test_chown_uid_gid_arguments_must_be_index self.assertRaises(TypeError, os.chown, support.TESTFN, value, gid) AttributeError: 'module' object has no attribute 'chown' -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15301 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18685] Restore re performance to pre-PEP393 level
Antoine Pitrou added the comment: Ok, here are some results from the benchmarks suite: Report on Linux fsol 3.8.0-27-generic #40-Ubuntu SMP Tue Jul 9 00:17:05 UTC 2013 x86_64 x86_64 Total CPU cores: 4 ### regex_effbot ### Min: 0.058952 - 0.054367: 1.08x faster Avg: 0.059060 - 0.054378: 1.09x faster Significant (t=132.69) Stddev: 0.8 - 0.1: 5.9597x smaller ### regex_v8 ### Min: 0.063401 - 0.050701: 1.25x faster Avg: 0.066147 - 0.053530: 1.24x faster Significant (t=3.22) Stddev: 0.00608 - 0.00630: 1.0363x larger The following not significant results are hidden, use -v to show them: regex_compile. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18695] os.statvfs() not working well with unicode paths
Serhiy Storchaka added the comment: Functions such as rename(), popen(), mkfifo(), mknod(), etc have the same issue. -- nosy: +haypo, serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18695 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18675] Daemon Threads can seg fault
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18675 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18600] email.policy doc example passes 'policy' to as_string, but that doesn't work
Roundup Robot added the comment: New changeset 53287858e71f by R David Murray in branch 'default': #18600: add policy to add_string, and as_bytes and __bytes__ methods. http://hg.python.org/cpython/rev/53287858e71f New changeset 8fbaf4e649af by R David Murray in branch '3.3': #18600: In 3.3, as_string does not accept a policy keyword. http://hg.python.org/cpython/rev/8fbaf4e649af New changeset b9a5b7e3b32f by R David Murray in branch 'default': Null merge related to #18600. http://hg.python.org/cpython/rev/b9a5b7e3b32f -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18600 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18600] email.policy doc example passes 'policy' to as_string, but that doesn't work
R. David Murray added the comment: Committed with changes pointed out by Antoine (thank you Antoine). -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18600 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18583] Idle: enhance FormatParagraph
Phil Webster added the comment: In the case of no selection would it make sense to only format if the cursor is in a string/comment? If not in a string or comment, the single line that the cursor is in could be formatted with a line ending backslash or not at all. Otherwise Format Paragraph will probably just be mangling code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18583 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18673] Add and use O_TMPFILE for Linux 3.11
STINNER Victor added the comment: use O_TEMPFILE in tempfile module when it's supported by the current kernel How do you detect that a kernel does not support the flag? Try to use the flag and handle the error? -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18673 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18643] implement socketpair() on Windows
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18643 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Eli Bendersky added the comment: On Fri, Aug 9, 2013 at 12:34 PM, Antoine Pitrou rep...@bugs.python.orgwrote: Antoine Pitrou added the comment: Can we agree on discarding the current implementation for now and then rewriting it based on a tree builder instead of a parser wrapper? Only if it actually brings something (feature-wise, performance-wise, maintenance-wise, whatever) that the current implementation doesn't have. Otherwise, I'd rather check in the simple inheritance-to-composition change. I'm sorry that you noticed this after the alpha. I would have had a lower threshold for changes if you had manifested when I proposed the feature. Antoine, I'm not yet very well versed in the release process, but ISTM that if: 1. We know that a better API can be created 2. The implementation is not overly difficult It makes sense to do the change even though Alpha 1 was already released. Alphas are alphas, after all :-) I suppose that we can consult with Larry and others if this is the only doubt holding the change back. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18644] Got ResourceWarning: unclosed file when using test function from formatter module
STINNER Victor added the comment: Why is the `formatter` module still part of Python 3? This was a dependency for the `htmllib` module in Python 2 only, and that module was deprecated and removed from Python 3. The formatter module was deprecated? When? -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18644 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Antoine Pitrou added the comment: Le vendredi 09 août 2013 à 20:34 +, Eli Bendersky a écrit : Antoine, I'm not yet very well versed in the release process, but ISTM that if: 1. We know that a better API can be created 2. The implementation is not overly difficult It makes sense to do the change even though Alpha 1 was already released. Alphas are alphas, after all :-) I suppose that we can consult with Larry and others if this is the only doubt holding the change back. I agree, but this assumes there is a better API. I would like to see an API proposal and a patch before I give an opinion :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0) deprecated function inspect.getargspec()
Claudiu.Popa added the comment: Here's a patch with tests attached. -- keywords: +patch nosy: +Claudiu.Popa versions: +Python 3.4 -Python 3.1 Added file: http://bugs.python.org/file31210/xmlrpc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18695] os.statvfs() not working well with unicode paths
STINNER Victor added the comment: The script above works fine on Python 3.3 but on 2.7 you'll get: ... Cool, you now have a good reason to upgrade to Python 3 ;-) I'm not sure that it's a good idea to invest time on fixing Unicode issues in Python 2, especially in a minor version (Python 2.7.x). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18695 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18571] Implementation of the PEP 446: non-inheritable file descriptors
Changes by STINNER Victor victor.stin...@gmail.com: -- title: Implementation of the PEP 446: non-inheriable file descriptors - Implementation of the PEP 446: non-inheritable file descriptors ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18571 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4708] os.pipe should return inheritable descriptors (Windows)
STINNER Victor added the comment: os.pipe() creates non-inheritable pipes on Windows, whereas it creates inheritable pipes on UNIX. IMO the reason is an implementation artifact: os.pipe() calls CreatePipe() on Windows (native API), whereas it calls pipe() on UNIX (POSIX API). The call to CreatePipe() was added in Python in 1994, before the introduction of pipe() in the POSIX API in Windows 98. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4708 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18698] importlib.reload() does not return the module in sys.modules
New submission from Eric Snow: Currently reload() returns the module that loader.load_module() returns, rather than returning the one in sys.modules. This is different from what happens during normal import. I would expect reload() to return what's in sys.modules. Perhaps this got overlooked when we moved reload()? I haven't had a chance to verify, but I do recall that the switch to importlib-based import in 3.3 exposed a bug where importlib wasn't returning the module in sys.modules during normal import. -- components: Library (Lib) messages: 194776 nosy: brett.cannon, eric.snow priority: normal severity: normal status: open title: importlib.reload() does not return the module in sys.modules type: behavior versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18698 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18699] What is Future.running() for in PEP 3148 / concurrent.futures.Future?
New submission from Guido van Rossum: From glyph (in a particularly snarky mood): P.S.: I realize that this isn't really within the scope of this message, but as I was reviewing Future's documentation while writing it, I realized what Future.running() does. Wow. What a completely pointless bug magnet. Why does this method even exist? It seems like the only possible use would be to introduce look-before-you-leap bugs into concurrent code, like 'if not my_future.running(): my_future.cancel()'. If it were for tracking the state of long-running Future operations for UI purposes or something, then 'my_future.add_start_callback(callback)' would be a much more useful interface, which at least has a hope of being used correctly. Independently of the rest of stuff in this message, it would be great if that could be deprecated and removed. Despite the snarkiness, he does have a point. Perhaps it was copied mindlessly from Java? -- components: Library (Lib) messages: 194777 nosy: gvanrossum priority: normal severity: normal status: open title: What is Future.running() for in PEP 3148 / concurrent.futures.Future? type: enhancement versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18699 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18416] Move to absolute file paths for module.__file__
Madison May added the comment:
I quickly ran the tests with each of the above edits to see what bits of the
test suite would break.
With option 1 (edits to PathFinder only):
``1 test failed:
test_importlib``
With option 2 (edits to FileFinder only):
``3 tests failed:
test_import test_importlib test_support``
With option 3 (edits to PathFinder and FileFinder):
``3 tests failed:
test_import test_importlib test_support``
So using the cwd as a key in sys.path_importer_cache seems to break fewer tests
than using '' as a key does. Perhaps that counts for something.
In test_importlib, the only test to fail was
`test_path_importer_cache_empty_string()`, for rather obvious reasons.
I haven't spent much time looking at failing tests in test_import and
test_support yet, though.
In regard to sys.path_importer_cache behavior -- at first glance, I'd lean
toward either:
1) Creating a new entry in sys.path_importer_cache after changing directories
and importing a new module (as is the case in option 1).
Key: os.getcwd() = Value: FileFinder(os.getcwd())
2) Keeping the current behavior in sys.path_importer_cache and somehow changing
the __file__ attribute a bit further down the line (perhaps in
`FileFinder._init_file_attr()` or `FileLoader.get_filename()`).
Key: '.' = Value: FileFinder('.')
or with a minor tweak for consistency with sys.path:
Key: '' = Value: FileFinder('.')
Have you given the issue any more thought, Brett?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18416
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18660] os.read behavior on Linux
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18660 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18699] What is Future.running() for in PEP 3148 / concurrent.futures.Future?
Roundup Robot added the comment: New changeset 922c0fe6ebee by Guido van Rossum in branch 'default': Get rid of Future.running(); see bug 18699. http://hg.python.org/peps/rev/922c0fe6ebee -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18699 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18673] Add and use O_TMPFILE for Linux 3.11
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18673 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18699] What is Future.running() for in PEP 3148 / concurrent.futures.Future?
Guido van Rossum added the comment: (Note that my change to PEP 3156 is somewhat separate -- Tulip's Future doesn't have to follow all of the PEP 3148 API and its running() method did nothing anyway. But concurrent.futures.Future has been released for several cycles and we must consider the removal of running() there more carefully.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18699 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18606] Add statistics module to standard library
Steven D'Aprano added the comment: On 31/07/13 20:23, Antoine Pitrou added the comment: I suppose you should write a PEP for the module inclusion proposal Done. http://www.python.org/dev/peps/pep-0450/ I hope to have an updated reference implementation, plus unittests, up later today or tomorrow. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18606 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18700] test_cgi raises ResourceWarning
New submission from Madison May: I'm currently running the tests on a 64-bit Ubuntu 13.04 laptop using the default branch of python. ``/home/mmay/cpython/Lib/test/test_cgi.py:276: ResourceWarning: unclosed file _io.BufferedRandom name=3`` -- components: Tests messages: 194782 nosy: madison.may priority: normal severity: normal status: open title: test_cgi raises ResourceWarning versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18700 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18695] os.statvfs() not working well with unicode paths
Giampaolo Rodola' added the comment: I'm not sure that it's a good idea to invest time on fixing Unicode issues in Python 2, especially in a minor version (Python 2.7.x). I admit I sort of share the same doubts, but considering 2.7 a minor python version, especially at this point, would be a mistake. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18695 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17741] event-driven XML parser
Stefan Behnel added the comment: I agree, but this assumes there is a better API. I would like to see an API proposal and a patch before I give an opinion :-) Well, I have already proposed an API throughout this thread, and then given a usage example and an almost complete sketch of the implementation. Please comment. I really can't accept the current wart for lxml, that's why I'm asking to not have it in ET either. This would be the first time I can remember that ET has a wrong API that lxml won't copy. I was asking for removal now, because if we can't manage to come up with a new implementation quickly enough and keep the code in, we'll end up with a quirk that we'll have to keep alive basically forever, in addition to whatever clean API we add later. Time's currently running against us. If we back out the current code, definitely before alpha 2, it'll start running for us again. I clearly prefer that situation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
