This time without delays, I present you Python 3.8.0b3:
This release is the third of four planned beta release previews. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. The next pre-release of Python 3.8 will be 3.8.0b4, the last beta release, currently scheduled for 2019-08-26.
Call to action
We strongly encourage maintainers of third-party Python projects to test with 3.8 during the beta phase and report issues found to the Python bug tracker <https://bugs.python.org/> as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (2019-09-30). Our goal is have no ABI changes after beta 3 and no code changes after 3.8.0rc1, the release candidate. To achieve that, it will be extremely important to get as much exposure for 3.8 as possible during the beta phase.
Please keep in mind that this is a preview release and its use is not recommended for production environments.
Last beta coming
Beta 4 can only be released if all “Release blocker” and “Deferred blocker” issues on bugs.python.org <http://bugs.python.org/> for 3.8.0 are resolved. Please prioritize those for the next four weeks.
Thanks to our binary builders, Ned and Steve, who were very quick today to get the macOS and Windows installers ready. The Windows story in particular got pretty magical, it’s now really fully automatic end-to-end.
Thanks to Victor for vastly improving the reliability of multiprocessing tests since Beta 2.
Thanks to Pablo for keeping the buildbots green.
🍝 copy-pasta from core-mentorship mailing list.
There is now a “newcomer friendly” keyword in bpo.
My hope is that going forward, we can tag issues that are suitable for
first time contributors with this keyword.
It would be great for experienced contributors already familiar with our
workflow to not work on issues tagged with newcomer friendly and leave that
to new contributors.
I’ve added the keyword to Devguide’s Triaging section, with additional
guideline of what can be tagged as newcomer friendly. Typically it should
be straightforward, well-defined issue, and low-risk.
On Thu, Jul 25, 2019 at 4:35 AM Petr Viktorin <encukou(a)gmail.com> wrote:
> It's not the equality operator that errors: `==` means element-wise
> comparison in Numpy. The error would come from a conversion of the array
> to bool:
> >>> numpy.array([1, 2, 3]) == numpy.array([1, 3, 4])
> array([ True, False, False])
> >>> if numpy.array([ True, False, False]):
> ... print('Same!')
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> ValueError: The truth value of an array with more than one element is
> ambiguous. Use a.any() or a.all()
This is true of course. I was being overly concise, but `arr1 == arr2`
does not itself (currently) raise any exception. It's only `if arr1==arr2`
But what NumPy does is return a "special" object that has some methods to
convert it into a boolean in different ways. We COULD do that with
`d1.values() == d2.values()` in principle. This "DictValuesComparison"
object could have methods like `.equal_as_set()` and `.equal_as_list()`.
However, that's a lot of machinery for very little gain.
In contrast, a NumPy boolean array is useful for lots of purposes, and it
is something we want independently to have around. Mostly it's a great way
of indexing into another list of numeric elements. But it also can be used
in some less common, but not uncommon ways. A hypothetical
DictValuesComparison object would have nearly no use other than avoiding
wrapping d.values() in list(), which we can already do fine. Sure, maybe
that rare case could be made a little faster with this custom machinery,
but it doesn't feel worthwhile to me.
Therefore, I think the exception with guidance in the message should happen
at actual equality (or inequality) comparison time, not when casting to a
Numpy currently returns False when `==` “doesn't make sense”, but
> apparently has plans to change that:
> >>> numpy.array([1, 2, 3]) == numpy.array([1, 2])
> __main__:1: DeprecationWarning: elementwise comparison failed; this will
> raise an error in the future.
> >>> numpy.array([1, 2, 3]) == numpy.array(['a', 'b'])
> __main__:1: FutureWarning: elementwise comparison failed; returning
> scalar instead, but in the future will perform elementwise comparison
This is very interesting! I did not know about this planned change. That
NumPy will start raising exceptions on equality comparison adds a little
bit of support for my suggestion, I think.
> > So, a helpful error message including something like "Cannot compare
> > dict.values directly, consider converting to sets / lists / sorted
> > lists before comparing" ?
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.
Not sure if this is the right place to ask, but I am trying to build pywin32-224 from source for Python 3.7.4. I think this might
be the right list as this seems to be a generic problem I am having, but I want to focus on one particular module. First, I know
I could get this via 'pip install', but I want to build from source to see what it takes in terms of the Windows SDK and Visual Studio
versions for some other work I am doing.
I am using Python 3.7.4, and I have Visual Studio 2017 15.9 (released July of this year).
I see this when running 'python setup.y build':
<bunch of stuff elided>
error: Microsoft Visual C++ 14.1 is required. Get it with "Microsoft Visual C++ Build Tools": https://visualstudio.microsoft.com/downloads/
I have tried various compilers from that link (VS 2015, VS 2017, and even VS 2019), but no joy. I also have the Windows
SDK 8.1 and 10 installed (pywin32 wants the 8.1 SDK)
Does anyone have any ideas as to what I am doing wrong, or if there is some weird underlying issue with setuptools and/or
Hello good people of Python Dev!
My name is Karl and I have been a Python user since 2010, professionally since 2015. I belong to the "novice, non-technical" group of users, having got my start with programming in the 1990s using HyperTalk, possibly the easiest language of all, with the most English-like syntax. My move to Python in 2010 resulted from my move to Linux at that time. The "easy syntax, almost like pseudo code" assessment that is often repeated about Python was a big factor in choosing the language for the tools I wanted to build then. I've come a long way since those early days, but I will not forget how I got started.
However... To this day, I am bothered by the convention of certain names using 4 underscores - "__class__", "__init__", "__add__", etc. I find them foreboding and difficult to type. They are also difficult to debug because in many editors there is no space between two underscores, and it may not be immediately obvious whether there is one underscore or two, or even three. I am lucky enough to have no disabilities, but I imagine there are segments of the "novice, non-technical" user group who would struggle to a greater degree than me. Given the focus of the Steering Council on improving inclusiveness and access in the Python community, I am hopeful that my message will be heard and my suggestion for improvement considered.
I understand how this naming convention came about, no problems there. I do think it is a case of too much linear thinking though, progressing from the convention of one underscore to two, then to four. I believe by the time we get to four, it is time to say "Stop, is there not a better way?"
Looking at the non-alphanumeric symbols in ASCII and considering their existing use in Python and other languages, the dollar sign "$" presents itself as the best option: "main.$class", "$init", "$add", etc. Of course, the old convention would remain for backward compatibility, but new code would be easier to type and debug with this new symbol.
Perhaps this solution or something like it has already been considered and rejected. In that case, no big deal, this post shall vanish into oblivion with no harm done. On the other hand, if my idea is new and has potential, then I am hoping that a core dev will step up, say something encouraging, and I will write up a PEP.
Thank you for reading and I look forward to your replies.
Usually the order of operands of the == operator does not matter. bool(a
== b) should return the same as bool(b == a). Correct __eq__ should look
def __eq__(self, other):
if not know how to compare with other:
return the result of comparison
But we work with non-perfect code written by non-perfect people.
__eq__() can return False instead of NotImplemented for comparison with
different type (it is not the worst case, in worst case it raises
AttributeError or TypeError). So the order of operands can matter.
See https://bugs.python.org/issue37555 as an example of a real world issue.
The typical implementation of the __contains__ method looks like:
def __contains__(self, needle):
for item in self:
if item == needle: # or needle == item
The question is where the needle should be: at the right or at the left
side of ==?
In __contains__ implementations in list, tuple and general iterators
(see PySequence_Contains) the needle is at the right side. But in
count(), index() and remove() it is at the left side. In array it is
effectively always at the left side since its __eq__ is not invoked.
The question is whether we should unify implementations and always use
the needle at some particular side and what this side should be.
One of the required CI tests is a Travis doc build, even if a PR does
not touch any doc file. The following failure appears to be
deterministic on master and 3.8. A 3.7 backport passed. It has
happened multiple times on multiple PRs today. Example:
The failure is
Warning, treated as error:
[distutils/examples:267] "`" found in "This is the description of the
Terry Jan Reedy
I have seen multiple discussions where somebody wants to deprecate a
useless function but somebody else complains that we cannot do that
because the function in question cannot be removed (because of backwards
compatibility). See https://bugs.python.org/issue29548 for an example.
We currently have a deprecation policy saying that functions deprecated
in version N cannot be removed before version N+2. That's a reasonable
policy but some deprecation purists insist that it MUST (instead of MAY)
be removed in version N+2. Following this reasoning, we cannot deprecate
something that we cannot remove.
Personally, I think that this reasoning is flawed: even if we cannot
*remove* a function, we can still *deprecate* it. That way, we send a
message that the function shouldn't be used anymore. And it makes it
easier to remove it in the (far) future: if the function was deprecated
for a while, we have a valid reason to remove it. The longer it was
deprecated, the less likely it is to be still used, which makes it
easier to remove eventually.
So I suggest to embrace such long-term deprecations, where we deprecate
something without planning in advance when it will be removed. This is
actually how most other open source projects that I know handle
I'd like to know the opinion of the Python core devs here.