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
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?
Currently a raw literal cannot end in a single backslash (e.g. in
r"C:\User\"). Although there are reasons for this. It is an old gotcha,
and there are many closed issues about it. This question is even
included in FAQ.
The most common workarounds are:
I tried to experiment. It was easy to make the parser allowing a
trailing backslash character. It was more difficult to change the Python
implementation in the tokenizer module. But this change breaks existing
code in more sites than I expected. 14 Python files in the stdlib (not
counting tokenizer.py) will need to be fixed. In all cases it is a
If only one type of quotes is used in a string, we can just use
different kind of quotes for creating a string literal and remove escaping.
If different types o quotes are used in different parts of a string, we
can use implicit concatenation of string literals created with different
quotes (in any case a regular expression is long and should be split on
several lines on semantic boundaries).
You can also use triple quotes if the string contain both type of quotes
4. In rare cases a multiline raw string literals can contain both `'''`
and `"""`. In this case you can use implicit concatenation of string
literals created with different triple quotes.
See https://github.com/python/cpython/pull/15217 .
I do not think we are ready for such breaking change. It will break more
code than forbidding unrecognized escape sequences, and the required
fixes are less trivial.
I am meanwhile the PySide maintainer at The Qt Company,
and we are trying to make the mapping from Qt functions
to Python functions as comparable as possible.
One problem are primitive pointer variables:
In Qt, it is natural to use "sometype *varname" to make a
mutable variable. In Python, you have to turn such a thing
into a result-tuple. Example:
void QPrinter::getPageMargins(qreal *left, qreal *top, \
qreal *right, qreal *bottom, QPrinter::Unit unit) const
(meanwhile deprecated, but a good example)
is mapped to the Python signature
def getPageMargins(self, \
unit: PySide2.QtPrintSupport.QPrinter.Unit) \
-> typing.Tuple[float, float, float, float]: ...
NOW my question:
I would like to retain the variable names in Python!
The first idea is to use typing.NamedTuple, but I get the impression
that this would be too much, because I would not only need to create
an extra named tuple definition for every set of names, but also
invent a name for that named tuple.
What I would like to have is something that looks like
def getPageMargins(self, \
unit: PySide2.QtPrintSupport.QPrinter.Unit) \
-> typing.NamedTuple[left: float, top: float, \
right:float, bottom:float]: ...
but that is obviously not a named tuple.
Possible would be to derive a name from the function, so maybe
a definition could be used like
but then I would have some opaque PageMargingResult type. This would
work, but as said, this is a bit too much, since I only
wanted something like a tuple with names.
What do you suggest to do here? Something what I am missing?
Cheers -- Chris
Christian Tismer :^) tismer(a)stackless.com
Software Consulting : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : https://github.com/PySide
14482 Potsdam : GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776 fax +49 (30) 700143-0023