Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython
On 07/03/2019 19.08, Mariatta wrote: I'd like to formally present to Python-dev PEP 581: Using GitHub Issues for CPython Full text: https://www.python.org/dev/peps/pep-0581/ This is my first PEP, and in my opinion it is ready for wider discussion. One part of this PEP stands out to me: | We should not be moving all open issues to GitHub. Issues with little | or no activity should just be closed. Issues with no decision made for | years should just be closed. I strongly advise against closing bug reports just because they're old. I know that the Python developers value trying to be a welcoming community. To many people, having a bug report that they put some effort into closed for no reason other than the passage of time feels like a slap in the face which stings harder than, for example, intemperate words on a mailing list. This is even more true if there won't be an option to re-open the bug, which seems to be what the PEP is saying will be the case. If a bug has been around for a long time and hasn't been fixed, the most useful information for the bug tracker to contain is "this bug has been around for a long time and it hasn't been fixed". Leaving the bug open is the simplest way to achieve that. (I think the above only goes for issues which are actually reporting bugs. Wishlist items are a different matter.) -M- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
On 2018-04-21 19:02, Tim Peters wrote:
> [Matthew Woodcraft <matt...@woodcraft.me.uk>]
>> I would like to suggest one more motivating example for "Capturing
>> condition values": multiple regex matches with 'elif'.
>>
>> if match := re.search(pat1, text):
>> print("Found one:", match.group(0))
>> elif match := re.search(pat2, text):
>> print("Found two:", match.group(0))
>> elif match := re.search(pat3, text):
>> print("Found three:", match.group(0))
>>
>> Without assignment expressions, you have an annoying choice between a
>> cascade of 'else's with an ever-increasing indent and evaluating all the
>> matches up front (so doing unnecessary work).
>
> That's a reasonable use, but would more likely be written like so today:
>
> for tag, pat in (("one", pat1), ("two", pat2), ("three", pat3).
> ("four", pat4), ...):
> match = re.search(pat, text)
> if match:
> print("Found", tag + ":", match.group(0))
> break
Well, that's a reason to make the example a bit more realistic, then.
Say:
if match := re.search(pat1, text):
do_something_with(match.group(0))
elif match := re.search(pat2, text):
do_something_else_with(match.group(0), match.group(1))
elif match := re.search(pat3, text):
do_some_other_things_with(match.group(0))
and_also_with(match.group(1), match.group(2))
-M-
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 572: Assignment Expressions
On 2018-04-17 08:46, Chris Angelico wrote:
> Having survived four rounds in the boxing ring at python-ideas, PEP
> 572 is now ready to enter the arena of python-dev.
I would like to suggest one more motivating example for "Capturing
condition values": multiple regex matches with 'elif'.
if match := re.search(pat1, text):
print("Found one:", match.group(0))
elif match := re.search(pat2, text):
print("Found two:", match.group(0))
elif match := re.search(pat3, text):
print("Found three:", match.group(0))
Without assignment expressions, you have an annoying choice between a
cascade of 'else's with an ever-increasing indent and evaluating all the
matches up front (so doing unnecessary work).
-M-
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR
In article CAMpsgwabYhXB0OG3UhdX=fucyonajgzpwd-g8stdaukjzpj...@mail.gmail.com, Victor Stinner victor.stin...@gmail.com wrote: 2014-09-02 23:03 GMT+02:00 Matthew Woodcraft matt...@woodcraft.me.uk: In any case I think PEP 475 should be explaining what is going to happen to signal.siginterrupt(). Will setting flag=True be supported? I first proposed to deprecate the function, but Charles-François thinks that it's unrelated to the PEP (it can be addressed later). The function will still be available and work. If so, will doing so change the behaviour of those parts of the stdlib which have already been modified to retry after EINTR? I think that the stdlib should not handle InterruptedError exception anymore in the Python code, to simplify the code. That seems good to me. I think it's worth writing in the PEP. But if Python is going to provide its own higher-level model of signal handling, then I think signal.siginterrupt() will need to be documented in terms of that model; it should be saying something along the lines of if a signal arrives while Python is blocking in a system call then InterruptedError will be raised, and I suppose it will need to say what happens if the signal handler also raised an exception. (I think it would be helpful if we could tell people if you want the old EINTR behaviour, just do this simple thing. And I suppose siginterrupt flag=True is a candidate for that.) Why do you want the old behaviour? Purely to avoid breaking existing programs, particularly in ways which will require effort to fix. I think Python's backward-compatibility rules are basically the behavior of an API must not change without going through the deprecation process. If we're going to be making an exception to that here, then it would be much better to say here's a simple change to make to keep your old program working, rather than please rewrite your fiddly signal-handling code to use more modern techniques, however much nicer those modern techniques are. Or perhaps it would be better to not make an exception at all, and instead add an 'interrupt_syscalls' boolean keyword argument to signal.signal(), while strongly recommending that people set it False. -M- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR
Nick Coghlan ncogh...@gmail.com wrote: On 2 September 2014 07:17, Matthew Woodcraft matt...@woodcraft.me.uk wrote: (The program handles SIGTERM so that it can do a bit of cleanup before exiting, and it uses the signal-handler-sets-a-flag technique. The call that might be interrupted is sleep(), so the program doesn't strictly _rely_ on the existing behaviour; it would just become very slow to exit.) Making an exception for sleep() (i.e. still letting it throw EINTR) sounds like a reasonable idea to me. I think people who use sleep() in their programs could benefit from not having to worry about EINTR as much as anyone else. And I don't think there's any reason to suppose that programs using sleep() are more likely than others to want to see EINTR. I think blocking network operations are more likely to be involved. -M- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR
Antoine Pitrou solip...@pitrou.net wrote: Matthew Woodcraft matt...@woodcraft.me.uk wrote: (The program handles SIGTERM so that it can do a bit of cleanup before exiting, and it uses the signal-handler-sets-a-flag technique. The call that might be interrupted is sleep(), so the program doesn't strictly _rely_ on the existing behaviour; it would just become very slow to exit.) So, if it's just for process exit, just let the signal handler raise an exception and catch the exception at the top-level. I wouldn't recommend that anyone take this advice. The signal might come at some time other than the sleep(), and introducing an exception which can mysteriously appear at abitrary points is not a way to make life easier. Nonetheless I'm sure my program would be easy enough to fix to use set_wakeup_fd() or signalfd() if necessary. I'm not saying we shouldn't make this backwards-incompatible change because it will be hard to update existing programs to cope; I'm saying we shouldn't pretend it doesn't count as a backwards-incompatible change. In any case I think PEP 475 should be explaining what is going to happen to signal.siginterrupt(). Will setting flag=True be supported? If so, will doing so change the behaviour of those parts of the stdlib which have already been modified to retry after EINTR? (I think it would be helpful if we could tell people if you want the old EINTR behaviour, just do this simple thing. And I suppose siginterrupt flag=True is a candidate for that.) -M- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR
Victor Stinner victor.stin...@gmail.com wrote: HTML version: http://legacy.python.org/dev/peps/pep-0475/ PEP: 475 Title: Retry system calls failing with EINTR I think the proposed design for how Python should behave is a good one. But I think this proposal needs to be treated in the same way as any other backwards-incompatible change. Applications relying on the fact that system calls are interrupted with ``InterruptedError`` will hang. The authors of this PEP don't think that such application exist. The authors are mistaken here. I have a program still running which was designed around this behaviour. My company won't be inconvenienced by this change because I can't imagine the elderly program ever being ported to Python 3. But I think it's very likely there are other such programs out there. If such applications exist, they are not portable and are subject to race conditions (deadlock if the signal comes before the system call). The program is certainly not portable (which is not any kind of a problem), and as pselect is unavailable there is indeed the usual theoretical race (which has not been a problem in practice in the ten years it's been running). (The program handles SIGTERM so that it can do a bit of cleanup before exiting, and it uses the signal-handler-sets-a-flag technique. The call that might be interrupted is sleep(), so the program doesn't strictly _rely_ on the existing behaviour; it would just become very slow to exit.) -M- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Counting collisions for the win
Victor Stinner victor.stin...@haypocalc.com wrote: I propose to solve the hash collision vulnerability by counting collisions [...] We now know all issues of the randomized hash solution, and I think that there are more drawbacks than advantages. IMO the randomized hash is overkill to fix the hash collision issue. For web frameworks, forcing an exception is less harmful than forcing a many-second delay, but I think it's hard to be confident that there aren't other vulnerable applications where it's the other way round. Web frameworks like the exception because they already have backstop exception handlers, and anyway they use short-lived processes and keep valuable data in databases rather than process memory. Web frameworks don't like the delay because they allow unauthenticated users to submit many requests (including multiple requests in parallel), and they normally expect each response to take little cpu time. But many programs are not like this. What about a log analyser or a mailing list archiver or a web crawler or a game server or some other kind of program we haven't considered? -M- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed change to logging.basicConfig
Terry Reedy tjre...@udel.edu wrote: I am bothered by mutually exclusive parameters. This is one reason I was glad to see cmp eliminated from list.sort. Quick: what happens if one passes both cmp and key to list.sort? There are three reasonable possibilities. As far as I can read, the answer is not documented.# # Experiment with 2.7 shows that cmp wins. Though too late to change, I consider this the worst choice of three. I think an exception should be raised. Failing that, I think key should win on the basis that if one adds a 'new-fangled' key func to an existing call with cmp (and forgets to remove cmp), the key func is the one intended. Also, the doc clearly indicates that key is considered superior to cmp. Neither 'wins': cmp is applied to the output of key. I agree that it would have been worth documenting this explicitly. -M- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cleaning-up the new unittest API
Raymond Hettinger raymond.hettin...@gmail.com wrote: I looked at this again and think we should just remove assertItemsEqual() from Py3.2 and dedocument it in Py2.7. It is listed as being new in 3.2 so nothing is lost. One thing that would be lost is that correct Python 2.7 code using assertItemsEqual would no longer run on 3.2. The sole benefit over the more explicit variants like assertEqual(set(a), set(b)) and assertEqual(sorted(a), sorted(b)) is that it handles a somewhat rare corner case where neither of those work (unordered comparison of non-compable types when you do care about duplicates). Another benefit is that it gives better descriptions of differences. See http://bugs.python.org/issue9977 for an example. -M- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Behaviour of max() and min() with equal keys
Raymond Hettinger raymond.hettin...@gmail.com wrote: Matthew Woodcraft wrote: In CPython, the builtin max() and min() have the property that if there are items with equal keys, the first item is returned. From a quick look at their source, I think this is true for Jython and IronPython too. However, this isn't currently a documented guarantee. Could it be made so? (As with the decision to declare sort() stable, it seems likely that by now there's code out there relying on it anyway.) That seems like a reasonable request. This behavior has been around for a very long time is unlikely to change. Elsewhere, we've made efforts to document sort stability (i.e. sorted(), heapq.nlargest(), heapq.nsmallest, merge(), etc). I've submitted issue 9802 as a feature request with a concrete suggestion for the docs. -M- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Behaviour of max() and min() with equal keys
In CPython, the builtin max() and min() have the property that if there are items with equal keys, the first item is returned. From a quick look at their source, I think this is true for Jython and IronPython too. However, this isn't currently a documented guarantee. Could it be made so? (As with the decision to declare sort() stable, it seems likely that by now there's code out there relying on it anyway.) -M- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Behaviour of max() and min() with equal keys
Mark Dickinson wrote: Matthew Woodcraft wrote: In CPython, the builtin max() and min() have the property that if there are items with equal keys, the first item is returned. From a quick look at their source, I think this is true for Jython and IronPython too. It's actually not clear to me that this behaviour is ideal; it might make more sense to have max() return the first item among equal largest elements, and min() return the last item. I don't care a great deal what the behaviour is; I would like it to be consistent across Python versions, and I think the pragmatic way to achieve that is to document the current behaviour. Can you give examples of code that relies on max and min returning the first among equals? An existing regression test whose output depends on which choice is made. (I was writing some code today which had to duplicate the behaviour of a non-Python program which uses first-among-equals, which is what brought this question up. In that case I wouldn't think it unreasonable to have to hand-code the loop rather than using max(), but if in practice Python is always going to be first-among-equals, it seems to me we might as well be 'allowed' to take advantage of it.) -M- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPI comments and ratings, *really*?
Martin v. Löwis mar...@v.loewis.de wrote: Because I want to wait for the outcome of the poll first. The pypi front page says: | The poll will be closed on December 1, 2009. The option that receives | most votes will be implemented. As I write, the option with the most votes is /Allow both ratings and comments/. But between them, /Disallow comments/ and /Disallow both ratings and comments/ have more votes. It seems clear to me that, given those figures, allowing comments would not be following the result of the vote. So I think that simply implementing the option that receives most votes is not a wise plan. (There are two other options; I don't think their presence makes the plan any wiser.) -M- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPI comments and ratings, *really*?
Steven D'Aprano st...@pearwood.info wrote: Why do you think it is okay to combine the Disallow vote, without also combining the Allow vote? Less than a third of the total votes are in favour of disallowing comments, with two-thirds in favour of allowing them. I don't. I was giving one example of the problem with the plan of not combining options at all. I wasn't writing to take sides. I was trying to say that using 'first past the post' voting with five options which are combinations of different issues (comments, ratings, whether to allow package owners to opt out) can't be expected to give a good decision. I think there is no safe way to pick a winner from this vote (unless more than half the voters choose a single option). (As a general point, in any discussion it tends to be unhelpful to ask Why do you think X unless the person you're asking has clearly indicated that they do in fact think X.) -M- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Subprocesses and SIGPIPE
The documentation for the subprocess module says that it can be used as a replacement for shell pipelines, and gives an example. On *nix systems, cpython is set to ignore SIGPIPE, and this setting is inherited by child processes created by the subprocess module. This is nearly always not what you want when you're constructing a pipeline. In practice, I think most programs are not particularly designed (or tested) to run with SIGPIPE ignored, and I've had trouble caused by this a couple of times now. If you know about this, it's easy enough to avoid trouble using something like this as a preexec_fn for subprocess.Popen: def permit_sigpipe(): signal.signal(signal.SIGPIPE, signal.SIG_DFL) My question is: should subprocess.Popen do this by default? In any case, it would be good to see this issue mentioned near the pipeline example. -M- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
