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-link…
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
Something occurred to me while trying to analyze code today: profiler and
cProfiler emit their data in pstats format, which various tools and
libraries consume. tracemalloc, on the other hand, uses a completely
separate format which nonetheless contains similar data. In fact, in many
non-Python applications I've worked in, heap and CPU profiles were always
emitted in identical formats, which allowed things like visual
representations of stack traces where memory is allocated, and these have
proven quite useful in practice and allowed lots of sharing of tools across
Is there a particular design reason why these formats are different in
Python right now? Would it make sense to consider allowing them to match,
e.g. having a tracemalloc.dump_pstats() method?