Thanks for doing this. I hope it encourages more participation.
The capabilities of a triager mostly look good except for "closing PRs and issues". This is a superpower that has traditionally been reserved for more senior developers because it grants the ability to shut-down the work of another aspiring contributor. Marking someone else's suggestion as rejected is the most perilous and least fun aspect of core development. Submitters tend to expect their idea won't be rejected without a good deal of thought and expert consideration. Our bar for becoming a triager is somewhat low, so I don't think it makes sense to give the authority to reject a PR or close an issue.
ISTM the primary value of having triager is to tag issues appropriately, summon the appropriate experts, and make a first pass at review and/or improvements.
FWIW, the definition of the word triage is "in medical use: the assignment of degrees of urgency to wounds or illnesses to decide the order of treatment of a large number of patients or casualties." That doesn't imply making a final disposition.
Put another way, the only remaining distinction between a "triager" and a "core developer" is the ability to push the "commit" button. In a way, that is the least interesting part of the process and is often a foregone conclusion by the time it happens.
On Wed, Aug 21, 2019 at 2:43 PM Steve Dower <webhook-mailer(a)python.org> wrote:
> commit: 75e064962ee0e31ec19a8081e9d9cc957baf6415
> branch: master
> author: Steve Dower <steve.dower(a)python.org>
> committer: GitHub <noreply(a)github.com>
> date: 2019-08-21T13:43:06-07:00
> bpo-9949: Enable symlink traversal for ntpath.realpath (GH-15287)
> A Misc/NEWS.d/next/Windows/2019-08-14-13-40-15.bpo-9949.zW45Ks.rst
> M Doc/library/os.path.rst
> M Doc/whatsnew/3.8.rst
> M Lib/ntpath.py
> M Lib/test/test_ntpath.py
> M Lib/test/test_os.py
> M Lib/test/test_shutil.py
> M Lib/unittest/test/test_discovery.py
This change seems to have broken the windows buildbots.
Could you please let me know what is the license for the file Modules/ossaudiodev.c ?Inside the description there is a statement :"XXX need a license statement" which creates some confusion.Can we simply disregard that statement as for the other .c files which do not have such statements?Please note that we need this information for our OSS clearance report.
Thank you, Mihaela
Recently, on Discuss, I created a new topic: https://discuss.python.org/t/should-news-entries-contain-documentation-li...
However, many may not have the time to read the full post or don’t regularly check the core workflow category on Discuss, so I'll provide a shortened version here.
During my experience thus far reviewing PRs on GitHub, I've noticed a significant degree of inconsistency when it comes to the usage of inline links with reST and Sphinx in Misc/NEWS entries. Since many of my contributions have involved documentation changes, I've familiarized myself most of the syntax.
Many of the features in markup languages provide visual modifications rather than functional ones. However, with the inline markup supported by reST and processing from Sphinx, there's a functional improvement as well. For example, the usage of :func:\`<function name>\` (escaped for mailman) provides a link to the relevant docs for the function.
In the context of news entries, this allows readers to click on a function, method, class, etc for more information. This can be useful if it's something they're not familiar with, or when the changes affected the docs. For those who are familiar with the structure of docs.python.org, the cross link to the docs may not seem at all necessary.
However, for readers that are either newer or not familiar with the structure, they might be led astray into 2.7 docs or an entirely wrong page. This happens especially frequently when using external search engines.
I'm not at all suggesting that every PR author should be required to use it or know all of the reST constructs. However, I would like for everyone to be aware of the potential usefulness of including inline links in news entries, and mention it in the devguide.
Also, I would like to understand why some developers dislike including it, even when the reST syntax is provided. The majority of authors so far would add my suggestion to their PR, but there have been some that don't want anything besides plaintext in their news entry.
Personally, I think it provides further inclusiveness to readers of all levels of experience and QoL at a very minimal cost.
I found a bug in subtype_dealloc causing segfaults when used with C heap types. Given that it modifies the deallocation routine of every instance, I thought it was important to surface this in here as well. Also worth noting, this blocks the adoption of PEP384 in C Extension modules that depend on subclassable types.
The bug and the fix are explained in detail in the PR: https://github.com/python/cpython/pull/15323
This is something that the development team are best placed to answer, and
I'm sure that they'd be happy to know if there are bumps in the road coming
up with Catalina.
I am copying this reply to the core developer list to alert them. It would
be helpful if you could make as full a report as possible via
bugs.python.org. A reply-all to this email can be used to let the
development team know the report reference should you do so, and the bug
tracker is a better medium for such focused communication than the list.
I've moved the webmaster address to Bcc to relieve it of further traffic.
On Fri, Aug 16, 2019 at 11:04 AM Ana Simion via Webmaster <
> Can you advise when you’re going to update Python to work with Mac OS X
> Catalina? I am running the beta of Mac OS X Catalina but am unable to
> install the python software - I get a message advising the Developer hasn’t
> updated the software to work with the new OS yet. I’d be most grateful if
> you could get back to me as soon as possible.
> Many thanks
> Ana Simion
> Webmaster mailing list
We should revisit what we want to do (if anything) about invalid escape sequences.
For Python 3.8, the DeprecationWarning was converted to a SyntaxWarning which is visible by default. The intention is to make it a SyntaxError in Python 3.9.
This once seemed like a reasonable and innocuous idea to me; however, I've been using the 3.8 beta heavily for a month and no longer think it is a good idea. The warning crops up frequently, often due to third-party packages (such as docutils and bottle) that users can't easily do anything about. And during live demos and student workshops, it is especially distracting.
I now think our cure is worse than the disease. If code currently has a non-raw string with '\latex', do we really need Python to yelp about it (for 3.8) or reject it entirely (for 3.9)? If someone can't remember exactly which special characters need to be escaped, do we really need to stop them in their tracks during a data analysis session? Do we really need to reject ASCII art in docstrings: ` \-------> special case'?
IIRC, the original problem to be solved was false positives rather than false negatives: filename = '..\training\new_memo.doc'. The warnings and errors don't do (and likely can't do) anything about this.
If Python 3.8 goes out as-is, we may be punching our users in the nose and getting almost no gain from it. ISTM this is a job best left for linters. For a very long time, Python has been accepting the likes of 'more \latex markup' and has been silently converting it to 'more \\latex markup'. I now think it should remain that way. This issue in the 3.8 beta releases has been an almost daily annoyance for me and my customers. Depending on how you use Python, this may not affect you or it may arise multiple times per day.
P.S. Before responding, it would be a useful exercise to think for a moment about whether you remember exactly which characters must be escaped or whether you habitually put in an extra backslash when you aren't sure. Then see: https://bugs.python.org/issue32912