Python 3 is coming soon. It's scheduled for release at the end of October 2019,
and you can already download test versions today.
Given that Python ships on an 18-month cycle,
it's time to talk about what's coming for us Python developers in the fall.
On this episode, I meet up with Lucas Lenga and Anthony Shaw
to chat about the highlights of this upcoming version of Python.
Also, a quick show note, we recorded this on location in Cleveland at PyCon 2019.
There may be a small amount of background noise, but I think you'll barely notice.
This is Talk Python to Me, episode 214, recorded May 5th, 2019.
Welcome to Talk Python to Me, a weekly podcast on Python,
the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy. Follow me on Twitter where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm,
and follow the show on Twitter via at Talk Python.
This episode is brought to you by Microsoft.
Be sure to check out what they're offering during their segments.
It really helps support the show.
Lucas, Anthony, welcome back to Talk Python, both of you guys.
Hello.
Hi, Michael. Good to be back.
Yeah, it's great to have you back.
We are not recording over Skype far distances,
but in fact, we're right here at PyCon,
and who knows how the audio for this is going to come out,
but hopefully it'll sound good enough.
But it's great to be here on site in Cleveland with both of you.
It's a unique experience to actually see you doing the recording.
Yeah, it's really good to be here in Cleveland.
The sun has finally come out today after the third day of PyCon.
The fog was pretty incredibly epic, and that was pretty special.
And yeah, Lucas, the latency on this video call is incredible, man.
It's so, it's lifelike.
Yeah, so this video call is like 3D.
It's amazing.
Yeah, it's amazing.
So thank you both for being here.
We're going to talk about Python 3.8
and maybe looking a little bit beyond that,
some of the peps that are out there and all the cool stuff there.
But, you know, let's just start with PyCon.
Like, how's your experience this year?
It felt a little different to me.
I'll say why in a minute, but you go first.
I'm Kosh Langa.
I've been co-chairing the Language Summit this year with Mariata,
and this is an absolutely new experience for me.
So that was interesting, actually herding all the cats at the right time,
to the right spots, you know, pre-selecting talks,
actually making sure that everybody has the opportunity to speak,
making sure that everybody is engaged.
That was new.
So I was very happy, like, you know, to have it over with, you know,
after that day.
I've heard it went pretty well, so I was happy about this.
Like, the rest of PyCon was also rather intense so far for me.
I've had a talk about Black,
and then, like, an extended Q&A that I just performed
during the poster session on Sunday morning.
That's really awesome.
You know, I feel like Black is one of these things
that has just taken off.
Like, I often ask people, you know,
what module do they recommend or package
or what is, like, special that they've seen,
and it's way more than any other single answer is Black.
That's awesome.
Congratulations.
Yeah, thank you.
I'm very happy about it.
In fact, I think there was at least five talks
that mentioned, you know, using Black as a good thing in them.
So it seems like, you know, we've solved an issue that people had.
We've solved a problem that people had.
Yeah, we've had these linters,
and they tell us, well, you're doing wrong,
and we're just like, can't you just fix it?
Like, I don't want to be told what's wrong.
I just want it to be better.
Yeah, well, the difference between Black and other other formatters,
of which we have a few in the Python community,
is that, well, Black was kind of brave,
obnoxious enough to tell you, like,
that it's going to just be, you know, done in one way.
It's not really configurable.
But that kind of changes it to a workflow tool,
where if you decide to use the tool,
like, now the question of auto-formatting sort of disappears.
The question of how to format your code
is no longer a problem
when you're developing your own projects.
Yeah, and if you're on a team,
you don't have to have this debate anymore
of how we do stuff, right?
You just run Black, and that's how you do it.
Absolutely.
Awesome.
Okay, Anthony, how's your PyCon going?
Like, what do you notice this year that's special?
Yeah, this is the first PyCon I've actually given a talk.
So that was definitely a milestone for me.
Yeah, what was the talk?
It was on code complexity,
and I talked about Y-Day,
which is a project I've been working on,
and the principles of code complexity
and why complexity is bad.
So how awesome cyclomatic complexity is?
I actually talk about how it's inevitable,
the more users you have,
to have more cyclomatic complexity.
People ask me how the talk went,
and my response so far has been,
I don't remember,
because I was so nervous
that it was just a sort of adrenaline-fueled dream.
So that was, yeah, really cool.
And then yesterday, there was mentored sprints.
That's new, right?
Which is a new thing this year,
and that's probably the highlight, actually,
for PyCon so far,
is actually just being in there and mentoring people
to contribute to different projects
and working with someone who ended up
being able to send a pull request through to CPython
by the end of the day,
and I think it was their first one,
which is awesome.
Yeah, that's super cool.
That's got to help adoption and contributions, right?
Because even me personally,
I think about,
okay, well, I'd love to do something,
but I really don't even know how to get started,
how to build it,
what the right rules or expectations are.
Like, it's a lot of work.
And if somebody can sit down who's done that
or is at least knowledgeable about that
and walks you through it,
like the second time onward
is much more likely to be smooth.
Yeah, and it was a proper amount of time allocated as well.
It was, I think it was just over four hours
on the second day in the afternoon.
So it's good enough time to actually sit
and work on a proper issue or a proper feature
and actually work through it from start to finish.
Yeah, you actually got a PR in place,
not just started or whatever, right?
Yeah, exactly.
Yeah, that's awesome.
To me, it felt like when I walked into the expo hall
that the booths were a little bit bigger,
there were a little bit more people.
It just seemed like a little bit,
I don't know, there are a little more people,
a little more energy even than last year.
And last year was amazing.
I don't know, did you have this feeling?
Yeah, I was particularly impressed
with the portrait of Guido at the Capital One booth,
which you've got to see online
if you haven't seen a picture of it already.
Yeah, their booth was really artistic.
It was pretty cool.
Nice.
All right, so it's great to be here at PyCon,
but let's talk about the future.
Let's start with the idea of when is Python 3.8
going to be out?
How precisely do we know that?
And Lucas, maybe just say a little bit about,
like, you're mostly in control of this
at the moment, right?
Like the release schedule and management
and whatnot, right?
Currently, I'm serving as the release manager
of Python 3.8.
And I wrote the schedule for where things are going to go.
Traditionally, Python has been released
every 18 months,
which puts Python 3.8 at the end of this year.
You know, in particular, like, you know,
give or take, it should be the end of October.
The reason why I'm not saying a particular date,
even though it is in the pep,
is that those things tend to be a bit fluid.
Like, in the past three alphas that I released,
like, we've been a day early or a day late
pretty much every time.
Yeah, would you be willing to, like,
hold up a release if there's some important feature
that's two days away?
In fact, like, this time,
there was a small issue,
well, but small in size,
but big in significance,
that I held up Alpha 4
that I had a bit of time for early in the week,
which kind of makes me late for my own schedule now.
And I have to release Alpha 4 tomorrow
at the start of sprints.
But those things are more important to get right
than to get on time.
And this is something.
Yeah, especially when it's 18 months.
If you were shipping monthly updates,
like, whatever, just ship what you got, right?
But if it's 18 months,
that couple days,
that means a big, big deal, right?
This is exactly the point.
We try to make the consecutive releases,
even on the Alpha level,
consecutively better
and not introduce a breakage
that is going to be later reverted
since every release,
including alphas,
is being tested by our users.
And we're happy to see,
actually, Alpha releases
being increasingly used
by the community
to test their own libraries
and applications
like that used to be our problem,
that it was only after the beta releases.
And in fact,
RCs very often
were the first releases
that users would see.
Nowadays,
with like PyPI working better,
where with CI options
being out there,
you know,
for pretty much everybody,
we see more adoption
of Alpha releases,
which is great.
But that is also
a bigger responsibility
on the Alpha releases
because you are no longer free
to just make a breaking change
and then later revert it.
Well, it's Alpha anyway.
Well, no, it isn't.
You see what it was?
It said Alpha.
Yes.
Come on.
Now we would need to have
feature toggles
that look at the Alpha version
to see whether
a particular bug exists or not.
And we don't want that.
This might be
a slightly political question,
but have the releases
of Python recently
become more stable?
Like, is it...
It feels to me
that like people
have almost zero trepidation
or worry about
just adopting 3.7
when they had 3.6
or 3.6
when they had 3.5
these days?
And it seemed like
there was more concern
about what's going to break
when I go to the next,
you know,
semi-major version.
Has that changed
or is that like perception?
For a number of years,
the only version
that people used
was 2.7
and that was for a long time.
So it created
this false perception
that like Python
is infallible,
that every particular
update of it
like never introduces
issues that
were not there before.
Because they were
just minor fixes
on a thing
that wasn't changing, right?
That was good,
you know,
at the same time
a blessing
and a curse
since every particular
version of Python,
like including
Python 2.4
to Python 2.5,
Python 2.5
to Python 2.6,
did introduce
internal changes
that made
large projects
actually complex
to migrate.
The biggest example
from the Python 2 world
where it was when
Python 2.5
was released.
Zope at the time
created like
such a problem
for itself
that it took
them enough time
that they migrated
to Python 2.6
directly.
So the previous
version worked
on Python 2.4
whereas the next
one directly
on Python 2.6
they did not migrate
in time for 2.5.
Right, it took so long
to migrate.
They're like,
let's just aim
for the next one, huh?
So like this is all
just like a long,
long introduction
to just, you know,
let you know
that in Python 3
there are also changes.
Many of those changes
are deliberate, right?
we are changing
how the internal
memory representation
of objects looks like.
We are introducing
and removing
byte codes.
We can change
how modules
get initialized.
You know,
there's multiple things
that might break
real applications
but they're breaking
them in ways
where it is impossible
for us to guarantee
eternal compatibility
with those things.
Sure, but this
greater adoption
of alpha versions
and testing
and CI
probably doesn't hurt, right?
some kind of crashers, right?
Downright bugs
and whatnot.
Like that I feel
like we are doing
a better job
these days with.
Also just because
Python 3
finally gets
enough adoption
that those versions
get vetted
much better.
Right, absolutely.
When I started
contributing
we were just working
on Python 3.2.
So for a number of years
like almost none
of the things
I worked on
were actually
very heavily used
in the industry.
Like nowadays
the situation
is different, right?
So fortunately
it's the time
between a change
and actually having
real users
report on it
is way shorter
which makes
the QLT just better.
Yeah, that's awesome.
Anthony, let me ask you
what your perception
of that's like
and you work
for a pretty major
company that probably
has like stability
in mind and stuff.
Like what's
your perspective
and what are you seeing
at like Dimension Data
and places like that?
It's definitely
become easier
for people to install
newer versions of Python
which is really helping.
So in terms of
I guess moving towards
things running
as microservices
on Docker
for example
there's this
it's not a single system
running a specific version
that's got to support
all these different applications.
Right, it's not
cross your fingers
or upgrading the server.
Yeah, we're not running
on the mainframe anymore
so I think that
that's really helping
in terms of
there's more automation
for systems deployment
and there's a lot more
tooling being used
to automate
like the building
of new environments.
There's this kind of
idea of immutable
infrastructure now
where you basically
create compute infrastructure
in the cloud
and you build it
on a specific version.
You don't change it
right, ever.
Yeah, so I think
that has actually
made it easier
to move to newer versions
because you can just
spin up new infrastructure
with the new version
test how it works
and you can inspect
it properly
whereas like
10 years ago
you were talking about
we need to go and buy
a million dollars
of hardware
to build an identical
environment
to see if this new
version is going
to work for us.
Right, and maybe
you have like
downtime the whole weekend
the team stays all night
and they do the testing
and the rollout
and you know
these days
when I go to websites
and I see
we're down for maintenance
or we have even
like we have scheduled
maintenance over this
like two to four hour
window
I'm just like
what are they doing?
Like what possibly
could take
four hours
to upgrade?
Like
I understand
maybe there's like
a migration
and you're down
for a few moments
but four hours
it doesn't take
anyway
it just seems
pretty wild
when you see it
but that used
to be common
right?
So I guess
yeah
so it doesn't
matter as much
Yeah, it still
matters for some
really big applications
I know some of the
biggest software vendors
still have four hour
maintenance windows
every Saturday
we definitely have to
live through some
of that pain
at the moment
but more and more
I think people
are using this
sort of
automated deployment
and automated
infrastructure
which is making
it a lot easier
to upgrade
That's awesome
What about the
beta version
or the alpha
version even
of 3.8
you guys said
late October
for
The main release
for the main release
but we work that back
like when will we see
stuff that we can start
playing with
can we already
I know Anthony
like get it and build
from source a lot
and play with it
and you guys do as well
but you know
when does the average
person who just wants
to install a beta
or something like that
get access to it?
Any alpha release
is released in both
the form of sources
that you can freely build
if you're cloning
the repository
from GitHub
there's tags
that tell you
exactly when
a particular release
was made
but also for
alphas, betas
and later
release candidates
and actual versions
that we release
we do have binaries
right
so for both
macOS and
Windows
we have plenty
of binaries
that you can use
to test out
your software
I would advise
to do it
like as early
as possible
like especially
3.8 was
kind of like
a shy release
right
because we had
the whole
governance thing
all the major
changes were
sort of put
on hold
right
so now
we are
just four weeks
before the first
beta
which is the
feature freeze
for us
right
since beta 1
to the main
3.8.0 release
we are just
fixing bugs
in some
unlikely cases
maybe even
reverting
features
that we
identified
are not
ready for
prime time
unlikely to
happen
like what
is more
likely to
happen
is like
this is
the time
where you
know that
breaking
changes
are no longer
being you know
new breaking
changes are no
longer being
accepted
so it's a
great time
to actually
you know
start using
your CI
to test
your libraries
your applications
on Python 3.8
as well
expect problems
there's things
that we have
not identified
even though
we have our
other extensive
regression suite
of tests
but it's great
like to be
able to
identify
those things
early
so by the
time the
distributors
come in
and package
Python 3.8
its quality
is good
and you know
we're transparent
we just can run
your application
with minimal
churn
that's pretty cool
can you test it
with talks
or like
what's the best
way to sort
of test on
3.7 and
3.8 beta
or whatever
there's many
possible ways
depending on
what particular
operating system
you're using
for open source
projects
that are already
using a CA
system like
Travis
there are
ways to just
utilize the latest
development version
of Python
and at the
moment it's
3.8
so just by
just saying
that you
would also
like to run
your tests
on the
development
version of
Python
you're gonna
get beta
version like
in a month
that currently
is gonna be
a form of
alpha
so that is
probably easiest
because you
don't have to
actually install
anything locally
on your computer
which tends to
make things
complex when
you have
many
interpreter
versions
with you
homebrewing
Patrick likes
to default
to one
Python 3
version
one
Python 2
version
so there's
PyEnv
that you can
use to have
multiple
installations
and obviously
yes there's
talks
they actually
work rather
well together
so you can
set up your
matrix of
tests that
later are
run online
but you can
also run
them locally
which is what
I'm doing
yeah okay
that seems
pretty easy
all right
Anthony let's
kick off
this pep
section
and talking
about the
actual features
which as we
all know
appear as
Python enhancement
proposals and
they go through
a life cycle
and whatnot
if people are
wondering what
peps are out
there what
might make it
into 3.8 and
so on like
where would
they go to
find that out
so I think on
the python.org
website and
there's a list
of peps
there's also a
PEP index
on the list
of peps
I've also made
like a small
web app
called pep
explorer where
you can go
and search
and filter
and pull
specific python
versions
and get the
status of the
peps
so I use
PEP explorer
because I
spend time
looking at
peps and
reading about
them and
trying to
understand what's
coming in
future versions
so yeah if
you're just
curious I'd say
the PEP explorer
is probably a
good way to go
yeah the pep
explorer is pretty
awesome it's just
a nice little
grid it's on
github pages
right yeah
yeah and
I'll just link to
that and of
course people can
go to python.org
but yeah it's
really nice to
just keep track
of that and
I find that
super helpful
all right so
let's kick it
off maybe since
you're holding the
mic we'll go
with you first
you know what's
like one of the
notable things that's
coming that you
want to talk about
what PEP or
feature so I
thought I'd cover
off the two
ones that changed
the language
first so there's
assignment expressions
colloquially known
as the walrus
operator
walrus operator
yeah so this is
PEP 572
yeah PEP 572
so in python
if you want to
assign a value
to a variable
you use the
equals symbol
that doesn't
return anything
so if you just
do a equals
one in the
REPL then that
won't return
anything in the
REPL
an assignment
expression is
basically a way
of combining
the assignment
of a value
to a variable
and returning
the variable
back again
so the reason
you would want
to do that
is in some
statements
for example
within list
comprehensions
within while
statements
for example
within if
statements
and the thing
in the if
statement
the comparison
for example
you can actually
do assignments
inside the
comparison
and it just
removes some
additional code
that you might
have to do
and also
there's a few
other examples
in list and
dictionary
comprehensions
where you can
do some fairly
smart things
inside the
comprehension
yeah when I
first saw this
I thought
interesting
I don't know
it's really
needed
but it's
I wasn't
super against
or anything
but certainly
seeing it
in the list
comprehension
space
and seeing it
used in other
places as well
I think I'm
pretty positive
on this language
change
it's pretty nice
certainly
anytime you need
an expression
right within
like some kind
of comprehension
maybe a lambda
or something like
that like
this often is
the only way
to you know
do it like so
if you want
to create
a variable
but also
test it
in a list
comprehension
and that
might be
the response
of a function
like you
can maybe
have to call
that twice
once when
you test
it and once
when you
put it
into the
list
now you
could assign
it and then
test it
right
like so
these things
get simpler
yeah they get
simpler
I think
looking at
the syntax
people's initial
responses
often I can't
see where I
would use that
but it
it takes a
while for
these types
of pieces
syntax to
become common
because
once you
know the
patterns
in which
you would
use it
and you've
memorized
then and
then you
start to
use it
more and
more over
time
this portion
of talk
Python to me
is brought
to you by
Microsoft
and Azure
Pipelines
Azure Pipelines
is a CI
CD service
that supports
Windows
Linux
and Mac
it lets
you run
automatic
builds
and tests
of your
Python
code
on each
commit
or pull
request
it is fully
integrated
with GitHub
and it
lets you
define your
continuous
integration
and delivery
pipelines
with a
simple
YAML
file
Azure
Pipelines
is free
for individuals
and small
teams
if you're
maintaining
an open
source
project
you'll even
get unlimited
build minutes
and 10
concurrent
pipelines
many Python
projects are
already using
Azure
Pipelines
so get
started for
free at
talkpython.fm
slash
Microsoft
and then
the second
PEP
I guess
changes
the language
slightly
is
positional
only
arguments
and basically
this is
PEP 570
which has
also been
accepted
and merged
into
Python 3.8
it wasn't
part of
alpha 3
so it'll
be in
the alpha
4 release
I believe
and basically
this one
is you
add a
forward slash
in the
list of
parameters
in a
function
definition
so that
it says
that it's
only
positional
arguments
in this
function
the reason
for that
is basically
to protect
an API
to ensure
that people
only use
positional
arguments
and they
don't
start to
use them
as keyword
arguments
yeah it's
pretty interesting
it's like
the anti
keyword only
argument
one right
which
so with
the keyword
argument
one
I don't
know that
many people
actually know
about it
but it's
pretty cool
so if
you say
you know
function
star
comma
argument
those
all have
to be
explicitly
called
as keyword
arguments
this is
like
I want
to make
it
impossible
at least
in this
section
of the
parameters
to call
them
as keyword
arguments
right
yeah it's
a cool
feature
and it's
also going
to help
with a lot
of the
standard
library
that's
the other
justification
and there's
a lot of
the Python
standard
library
where the
API needs
to be
protected
so that it
can be
iterated
on
and where
this feature
is basically
going to help
lock that
down
and also
in 3.7
there were
some improvements
to the
performance
of method
calls
that performance
improvement
doesn't work
with keyword
arguments
I see
so basically
you could
potentially use
this as a
way of enforcing
that performance
improvement
okay that's
interesting
the example
that I saw
I think if I
remember this
correctly
was just like
range
like even
just knowing
when you see
stuff if you
quickly read it
like you could
have range
and say stop
and then start
and then step
or you could
have start
and then stop
or you could
have step
and then start
and just
just seeing
I mean even
the words
are kind of
similar
and it's
going no
I want you
to always
to say
start
and then stop
and then step
or whatever
right like
just requiring
them to not
have this sort
of almost
arbitrariness
of the order
of the parameters
seemed like
an interesting
idea there as
well
yeah
an additional
detail is
the fact
that you
know many
of the
functions
that are
implemented
in C
don't
implement
keyword
arguments
so they're
effectively
positional only
by the
sheer fact
that they are
just being
implemented in
C
and this
just enables
us to express
those same
APIs in Python
faithfully
so that alternative
implementations
recreate the
API in exactly
the same way
oh yeah
that's interesting
so you don't
want like
the leaky
abstraction
of the C
implementation
to leak out
and maybe
break PyPy
or something
like this
yeah so
currently
like the
issue is
actually
the opposite
where
PyPy does
not
necessarily
care
that
you know
some
argument
is
positional
only
in
C
Python
so
they
allow
for
keyword
use
of it
and then
that piece
of code
is problematic
going back
to C
Python
so that
is just
you know
caring of
you know
making
your library
code
your application
code
sort of
exchangeable
between
runtimes
yeah
interesting
what about
Cython
it's
its
own
kind
of
thing
because
it's
a
language
that
is
being
compiled
or
rather
transpiled
to a bunch
of C
or C
plus
which
is
then
compiled
to a
C
module
they
are
kind
of
free
to do
a lot
of
modifications
that
Python
itself
is not
free
to do
because
they're
compile
time
modifications
right
their
transpiler
can make
the
adjustment
it
needs
anyway
right
yes
the source
code
that
you're
reading
is not
the source
code
that is
being
executed
interesting
all right
what's
the next
pep
that you
want
or feature
you want
to talk
about
let's
cover a few
of them
and in fact
like the
slew of
peps is
all related
to typing
let me start
with something
old
which is
pep
544
protocols
so that
pep
should have
been accepted
a long
time ago
but it
did not
because of
the
governance
situation
so
protocol
is this
kind of
like
interface
inheritance
type of
thing
like what's
going on
protocols
essentially
is a way
to introduce
duck typing
to static
typing
to type
checkers
so you
can have
interfaces
well
or like
protocols
they are
called
protocols
across the
python
documentation
too
which is
why we're
using that
name
in the
pep
too
but you
can have
essentially
implicit
interfaces
that are
being
implemented
by a
class
by a
type
and then
the
type
checker
is able
to act
on them
when you
express
a need
for a
given
one
as an
argument
to a
function
for example
if your
function accepts
anything
that has
a read
method
now you
can express
that type
before
that's really
cool
i'm super
excited about
this
because
if you
take two
things like
maybe
a set
and a
dictionary
but you
want to
express
i'm going to
have
those
types
and i
work
with
them
but
really
all
i
care
about
is
i
can
iterate
it
or
that's
probably
not
the
perfect
example
but you
know
like
it's
hard
to
kind
of
make
the
type
system
express
that
now
and
this
just
says
well
if it
has
an
add
and
pop
method
we're
good
like
whatever
right
that's
is that
protocols
yes
so
protocols
is the
answer
like
to
a
question
that
we've
received
a lot
early
on
when
PEP 484
came out
like
the
original
you know
formation
of
static
typing
for
Python
that
isn't
static
typing
in
direct
opposition
to
what
we
have
been
telling
everybody
to do
for
all
those
years
which
is
duck
typing
if
it
quacks
like
a
duck
and
looks
like
a
duck
it
is
a
duck
we
don't
care
if
this
instance
is
working
we
just
care
that
the
calls
find
the
right
methods
with
the
right
arguments
and
everything
is
fine
so
now
with
protocols
you can
actually
structurally
express
this
all you
care
about
is
a
given
field
or
a
given
method
I
like
it
I
know
you're
a
proponent
of
type
hints
and
my
pie
and
all
that
kind
of
stuff
how do
you see
the
state
of
that
these
days
well
we're
definitely
on
the
rise
there
at
my
time
at
Instagram
and
at
Facebook
we've
seen
a lot
of
improvements
both
in
terms
of
security
team
velocity
and
as
well
just
being
able
to
comprehend
the
source
code
when
types
were
introduced
to
the
biggest
PHP
component
of
Facebook.com
and so
since
I guess
2013
I wanted
to see
something
similar
in
Python
so
like
pep484
came out
you know
soon enough
Python 3
started getting
adopted
more and
more
and
you know
this is
when
annotations
which are
the nice
way to
express
types
have been
gaining
adoption
and
these
days
like
from
what
I've
heard
at
the
conference
now
90%
of
functions
in
the
Instagram
code
base
which is
north
of
2
million
lines
of
code
at
the
moment
is
covered
in
types
which is
amazing
right
that is
a big
achievement
so
definitely
this trend
is on
the rise
which
I am
very happy
about
yeah
that's
awesome
Anthony
what are
your
thoughts
on
type
hints
annotations
and
do you
like
them
have
they
changed
your
code
do you
use
them
I
actually
use
them
very
rarely
in
3.7
there's
the
type
annotations
the delayed
evaluation
type
annotations
yeah
it's gotten
a little
nicer
in that
way
in
3.7
which
makes
it
a bit
easier
in
terms
of
what
you
have
to
import
and
when
but
the
only
reason
I
use
them
seldomly
is
because
I
mainly
work
on
libraries
which
I
publish
to
PyPI
and
which
are
used
by
people
who
have
Python
3.5
3.6
and
some
2.7
as well
so
I
really
have
to
cover
the
lowest
common
denominator
when it
comes
to
users
because
they're
mainly
utility
libraries
that I
work
on
not
single
deployment
applications
yeah
or something
like
black
that
doesn't
really
get
consumed
directly
but
is
more
executed
right
like
black
or
py
test
or
something
what's
the
next
one
all
right
so
the
next
pep
would
be
pep
585
that I
actually
wrote
well
it's
still
in
draft
form
so
to
kind
of
set
the
stage
for
the
pep
what
Anthony
said
is
like
there's
plenty
of
cases
where
currently
typing
that was
added
rather
carefully
to
the
language
requires
you
to
import
names
that
you're
later
using
as
types
there's
some
situations
where
you are
introducing
names
to
your
global
scope
just
for
type
aliasing
or
to
introduce
type
variables
right
for
example
if
you've
got
a
function
and
you
want
to
say
its
return
type
is
this
object
you
now
have
to
import
at
the
top
if
you
had
never
actually
had
that
part
called
maybe
it
would
have
never
been
imported
until
lazily
or
there's
changes
in
behavior
because
of
that
right
yeah
this
is
often
problematic
right
like
what is
even
more
like
just
cumbersome
for
the
user
is
that
there's
plenty
of
either
built-in
types
or
abstract
based
classes
that
have
their
equivalents
in the
typing
module
meaning
if you
want to
express
that
some
argument
is a
list
of
string
you
have
to
import
an
uppercase
list
from
the
typing
module
and say
uppercase
list
of
string
and I
always
found
that
clumsy
right
I
always
found
that
it
is
something
new
that
you
have
to
explain
to
new
programmers
that
are
first
interacting
with
typing
and
there's
not
really
a
great
reason
for
that
it
was
just
you
know
we
wanted
the
actual
lowercase
list
to be
orthogonal
and
not
know
anything
about
the
starting
typing
concept
which
is
mostly
used
by
an
external
type
checker
it
does
not
have
a
big
runtime
component
does
have
a
little
right
because
you
can
inherit
from
generic
types
so
you
can
actually
create
your
own
data
structure
where
you
say
that
this
is
a
collection
of
types
T
so
this
is
a
possibility
but
for
very
many
cases
this
runtime
component
is
just
a
hindrance
something
that
you
have
to
remember
to
import
the
names
look
different
because
they're
uppercase
and
lowercase
they might
look
exactly
the
same
in
form
of
set
but
they
actually
mean
something
else
now
because
the
point
being
like
so
that's
the
first
issue
and
the
second
issue
is
that
this
is
something
that
sits
in
memory
right
this
is
something
that
you
spend
time
on
when
you're
starting
up
your
program
so
I
always
felt
like
this
is
something
that
we
can
maybe
live
without
hence
pep
563
which
actually
postpones
evaluation
of
annotations
that
was
introduced
in
python
37
and
stemming
from
that
you
know
having
that
foot
in
the
door
that
like
now
the
annotations
are not
evaluated
anymore
we can
regain
some
of
the
usability
that
people
expect
just
by
the
fact
that
this
can
be
still
valid
python
syntax
but
it
doesn't
have
to be
valid
at
runtime
so
we
can
get
away
without
importing
things
from
typing
you
know
the
type
checker
will
know
exactly
what
you
mean
anyway
right
we
can
go
come
back
to
using
a
lowercase
list
of
string
instead
of
uppercase
list
of
string
and a few
other
things
you
still
do
the
bracket
of
string
yeah
on the
lowercase
list
type
yeah
so
like
we
will
never
do
like
you
know
pointy
brackets
for
that
like
in
Java
or
C++
because
our
LL1
parser
is
like
unable
to deal
with
that
case
like
maybe
if
we
switch
to
a
different
one
of
which
there
is
discussion
like
you
know
maybe
then
that
would
be
possible
but
at
that
point
it
will
still
be
way
too
late
and
yeah
I
think
it's
fine
the way
it works
it's
different
but
it's
a way
of
expression
there's
nothing
that
makes
the
angle
brackets
in
templates
or
generics
necessarily
the
right
way
yeah
yes
exactly
it's
like
as
long
as
humans
understand
what
those
things
mean
the
goal
has
been
achieved
so
yeah
the
rest
of
the
PEP
585
is
just
an
attempt
to
reform
some
of
the
pre-existing
constructs
in
the
typing
module
like
creating
new
types
casting
aliasing
or
type
variables
into
variable
annotations
so
that
they
are
also
not
evaluated
at
import
time
which
enables
again
usage
of
types
that
are
not
imported
and
some
of
those
tricks
with
syntax
like
lowercase
list
and
dict
and
whatnot
so
that's
while we're on this
performance
and type
annotations
and stuff
what's the story
of mypyc
oh this is actually
a very interesting
story
so
like
mypy has
traditionally
been slow
like to the
point where
running it
over the
entire
Instagram
code
base
like was
taking
over
five minutes
right
so this
was a
thing
that you
could do
in
continuous
integration
but you
could not
absolutely
like run
it in an
editor
or whatnot
you know
we had
some
hacky
workarounds
to at least
make people
in the
editors
happy
I wrote
like a
silly
flake
8
mypy
plugin
at some
point
that
kind of
brought us
somewhere
you know
it was useful
for a while
but all of
that was just
not very
great
so in the
meantime
mypy started
implementing
incremental
typing
meaning
the graph
of your
modules
which did
not change
can be
cached
so that
with every
change
like most
of your
computation
is already
pre-done
and that is
evolving to
this point
now
I can
with well
populated
cache that
cuts the
time to
around 40
50 seconds
so it's like
yeah
it's like a
six seven
times improvement
yeah it's a
big improvement
so that's
good but
still the
cold
type checking
was like
rather
slowish
the meantime
Facebook
started developing
its own
type checker
for Python
well more
with the
goal of
creating
static
analysis
tooling
that
just
uses
types
so the
type
checker
part
was only
the base
of the
you know
static
analysis
that was
being
performed
on that
very code
with the
important
use case
of doing
security
checks
and one
of the
goals
of that
you know
new type
checker
was like
we have
to be
faster
than mypy
right
yeah
like so
that created
competition
and competition
is always
good
so in the
meantime
like
yukal
like
to
style
or
like
revived
his
original
idea
that
hey
if we
have
types
we can
actually
try to
compile
the
Python
code
in a way
that
runs it
way faster
now
what is it
compiled to
so that's
interesting
right
so the
mypyc compiler
actually creates
C extension
like it
actually transpiles
to C
this sounds
weird until
you think
about the
C API
that Python
provides
and the
Python
C API
is meant
to be
consumed
by C
so it
is just
natural
that you
would have
a generator
that emits
valid C
for your
given use
case
and it
turns out
that with
just a few
constraints
on how your
program works
you can achieve
20 to 30
times performance
boosts
with that
so that's
great
and in a real
production application
like mypy
it's consistently
four times faster
this portion
of talk
Python
is sponsored
by Microsoft
and Visual
Studio Code
Visual Studio Code
is a free
open source
and lightweight
code editor
that runs
on Mac
Linux
and Windows
with rich
Python support
download Visual
Studio Code
and install
the Python
extension
to get
coding
with support
for tools
you love
like Jupyter
black formatting
pilot
py test
and more
and just
announced
this month
you can
now work
with remote
Python
code bases
using the new
Visual Studio Code
remote extensions
use the full power
of Visual Studio Code
when coding
in containers
in Windows
subsystem for Linux
and over SSH
connections
yep that's right
auto completions
debugging
the terminal
source control
your favorite extensions
everything works
just right
in the remote
environment
get started
with Visual Studio Code
now at
talkpython.fm
slash Microsoft
do you see
use cases
for that outside
just mypy
like random
person
doing data science
that needs
their Python
parts
to go
faster
or
currently
mypyc
tries to
limit their
scope
since
they perceive
the
attempts
by previous
projects
that meant
to
speed up
Python
those attempts
failed
mostly
on trying
to be
100%
compatible
with
every
single
feature
of
Python
so
they're
focusing
on a
subset
but they're
growing
that subset
like as
you know
as much
as they
needed
and
the big
missing piece
currently
is like
there is
no async
await support
and with
that support
I could
actually
have
Black
compiled
which could
also
you know
significantly
speed up
the
formatter
which is
already pretty
performance
already does
pretty well
but that would
just make it
so much
better for
the users
so in
fact
I think
I managed
to get
Soli
the
core
developer
of
mypyC
rather
excited
about
the
prospect
of
having
Black
as the
next
production
customer
of
mypyC
so we'll
see
I have
my fingers
crossed
yeah
that's
exciting
all right
Anthony
what's
the next
one on
our list
of cool
features
in 3.8
so this
one
is
still
in
draft
it
hasn't
actually
been
decided
and
potentially
might
be
deferred
to a
later
release
if it
gets
accepted
but
when
I've
talked
about
features
at least
proposed
PEPs
this one
gets quite
a bit
of
attention
and
they're
called
runtime
audit
hooks
and
basically
the
PEP
is
a
way
of
setting
a
callable
when
certain
system
methods
within
the
Python
standard
library
get
called
for
example
opening
a
network
socket
or
requesting
a
URL
or
opening
a
file
or
lots
of
different
cases
I guess
of
low
level
standard
library
functions
or
you
get
notified
that's
super
cool
so
like
if
for
some
reason
I'm
in a
lockdown
environment
I want
to
use
some
package
or
write
some
app
and
it's
we
think
it's
not
talking
to
the
network
or
the
file
system
but
it
turns
out
all
of a
sudden
it's
opening
sockets
or
DNS
stuff
that
might
be
something
to
inspect
yeah
so
potentially
you
could
lock
down
a
Python
distribution
or
a
Python
process
to
not
be
able
to
open
certain
URLs
or
open
network
sockets
under certain
circumstances
and it's
cool
so with
the hooks
do I get
to say
I saw
what you
did
and okay
or I saw
what you
did
and no
you don't
get it
is it
like a
place
to stop
it
yeah
the default
is just
as an
FYI
yeah
but if
you wanted
to
throw
run
raise a
runtime
error
or
something
else
in line
then it
would
actually
stop
the
request
through
to
the
function
that's
pretty
awesome
I think
this is
pretty
interesting
I know
there's
some
restricted
environments
and even
like
app stores
and stuff
that maybe
would be
cool
to
package
this
up
and
use
it
so
yeah
definitely
nice
Lucas
what do
you think
about
this
one
well
I
actually
think
this
is
very
important
like
if
you
ever
worked
for
a
organization
very
often
the
audit
trail
of
what
actually
happened
is
important
not
just
for
security
reasons
very
often
cascading
errors
that end
up
with
an
entire
site
being
down
are
very
hard
to
foresee
the
very
easy
to
make
mistakes
are
long
fixed
they're
all
patched
there's
not
a
big
red
switch
that
if
you
press
the
button
the
site
goes
down
it's
very
often
something
that
it
was
hard
to
combine
and
having
the
trail
of
this
happened
first
and
another
thing
happened
later
that
is
very
valuable
so
I
see
this
feature
not
only
as
a
security
feature
but
as
a
post-mortem
kind of
feature
as well
Anthony
do you
envision
this might
enable
a different
set
of
tooling
we have
visual
debuggers
now
could you
have
other
types
of
analysis
and
tooling
and
whatnot
in
terms
of
tooling
there's
a lot
of
things
in
standard
library
that
you
might want
to
add
hooks
in
and
also
an
easy
way
of
putting
hooks
into
additional
modules
as well
and
having
people
to
catch
those
and
deal
with
those
separately
I
can
definitely
think
of
a few
examples
of
libraries
deserialization
libraries
not naming
any
specifically
that have
security
backdoors
just in
terms of
the way
they work
so
unless
you
explicitly
specify
to
load
it
with
a
safe
mode
then
you
can
actually
run
that
was
a
different
rhyme
maybe
yeah
there's
XML
as well
is
another
one
yeah
there are
sort of
known
I guess
security
backdoors
in
certain
libraries
and
basically
this
could
be
a
way
of
protecting
against
those
okay
yeah
that's
great
because
it
should
not
be
doing
these
operations
while
loading
this
file
yeah
if
you're
if
you're
loading
a
YAML
file
or
an
XML
file
it
shouldn't
be
opening
network
sockets
yeah
probably
not
or
issuing
sub
process
commands
or
you know
any
of
these
not
so
lovely
things
that's
right
all right
Lucas
what's
next
on our
list
I would
like
to
say
that
you know
there's
quite
a few
peps
that are
still
in
draft
form
and
the
authors
have
like
an
entire
four
more
weeks
in
which
they can
decide
to
finish
their
pep
and
publish
it
so
things
might
change
but
the ones
that
I'm
personally
interested
in
is
always
of course
typing
so
let me
just
cover
two
more
like
the
first
one
is
pep
586
so
that's
literal
types
and
second
one
is
589
which
is
typed
dict
both
of
them
are
kind
of
an
example
of
you
know
our
type
system
kind
of
starting
uh
conservatively
and
then
growing
based
on
need
right
so
literal
types
are
very
interesting
because
there
are
a bunch
of
calls
where
the
behavior
like
the
return
type
or
you
know
the
cascading
other
arguments
that
you're
going
to
use
in
the
function
depend
not
on
the
type
of
an
argument
but
on
the
actual
value
that
you
are
passing
positive
integer
negative
integer
well
like
so
parametric
types
are
kind
of
hard
but
what
we
are
doing
with
literal
types
is
something
like
the
open
built
in
you
have
a
certain
number
of
modes
right
and
depending
on
whether
you're
saying
RB
or
R
the
resulting
IO
is
either
bytes
or
strings
and
currently
there
is
certain
hackery
both
in
mypy
and Pyre
to just
work
around
this
but
it
would
be
good
if
the
actual
type
system
supported
this
feature
so
literal
is
all
about
being
able
to
express
those
types
so
that
if
you
pass
none
here
it's
going
to
behave
differently
if
you
pass
on
string
here
it's
going
to
behave
differently
if
that
string
is
RB
or
is
WB
or
is
R
and so
on
and so
on
so
that's
literal
types
there's
some
very
interesting
edge
cases
and
deep
thought
in
that
pep
it
is
surprisingly
long
and
complex
I'm
not
going
to go
into
this
now
the
another
one
is
the
type
dict
originally
dictionaries
have been
envisioned
in the
static
typing
as
there's
this
key
value
store
so
there's
keys
of
a
certain
type
and
there's
values
of
a
certain
type
what
happens
in
practice
is
that
a lot
of
pre-existing
Python
applications
do
not
use
name
tuples
do
not
use
errors
or
data
classes
which
are
very
new
instead
they use
kind of
lightweight
classes
in the
form
of
dictionaries
that
have
keys
and
values
of
various
types
so
there
can be
name
which
is
a
string
but
there
can
be
a
birth
year
which
is
going
to
be
an
int
right
and
based
on
the
actual
name
of
that
key
you're
going
to
have
different
types
so
that
was
very
cumbersome
to
express
in
the
previous
form
almost
like
a
schema
yeah
yes
it's
very
much
like
schemas
so
now
there
is
a
way
to
describe
a
type
dictionary
in
the
form
of
like
a
data
class
like
type
where you
just
express
it
like
class
like
saying
this
dictionary
is
going to
have
keys
that
are
like
this
and
this
key
is
going to
be
a
string
this
other
key
is
going to
be
an
int
that
solves
already
a
lot
but
then
the
interesting
part
is
when
those
things
start
nesting
that
actually
enables
you
to
construct
rather
complex
schemas
that
can
be
used
directly
in
JSON
or
in
other
forms
of
serialization
so
that
pep
alone
is
also
very
useful
in
practice
even
though
you
could
just
say
people
are
doing
it
wrong
they
should
be
using
name
tuples
or
other
forms
of
typing
instead
well
you
have to
be
pragmatic
you
see
pre-existing
valid
use
cases
of
this
you
have
to
adhere
to
those
yeah
interesting
I guess
since
you're
really
into
typing
and
you're
on
the
core
dev
side
of
things
what
do
you
think
about
libraries
especially
I'm
thinking
of
web
frameworks
that
use
typing
for
serialization
and stuff
so like
Molten
for example
you can
have
a
class
that
has
fields
but also
those
fields
have
types
and
then
you
say
this
web
function
takes
this
class
but
it's
really
a
form
submission
and
it'll
convert
stuff
to
integers
or
validate
against
the
types
is
that
in
your
mind
awesome
or
is
that
an
abuse
of
the
type
system
so
this
is
interesting
right
because
obviously
as long
as the
type
system
is
kind
of
an
extension
of
the
type
system
we're
using
for
type
checking
or
maybe
it's
even
exactly
the
same
like
that
is
using
a
shared
vocabulary
that's
great
we support
that
we would
wish to
see
type
hints
in
more
places
in
fact
in
3.7
I
extended
single
dispatch
so that
now
you can
just
use
annotations
on
arguments
instead
of
saying
register
off
and
using
the
annotations
of
the
first
argument
it'll
behave
as
you
expect
so
you
can
use
type
annotations
at
runtime
for
whatever
you
want
as
long
as
the
type
system
is
the
same
with
what
we're
using
it
for
some
use
cases
use
annotations
function
annotations
in
incompatible
ways
and
that
creates
issues
because
an
increasing
amount
of
tooling
like
Visual
Studio
Code
PyCharm
and
whatnot
gets
confused
by
seeing
something
that
is
clearly
not
a
type
in
the
place
where
types
are
expected
so
I
kind
of
yeah
an
example
of
that
like
so
this
example
I gave
you
with
Molten
seems
like
it's
consistent
the
type
checker
says
it takes
an
int
it's
actually
an
int
at
runtime
it
is
but
I
can't
remember
but
some
of
the
other
frameworks
maybe
rest
frameworks
they
would
say
like
you
could
say
that
this
parameter
is
a
header
and
what
it
actually
is
the
string
value
with
that
name
out of
the
header
right
it's
like
the
value
comes
from
the
header
but
like
at
runtime
it's
not
a
header
it's
not
a
dictionary
whatever
the
header
is
it's
actually
a
string
or
an
int
or
something
it
seemed
like
it was
really
cool
and
clever
but
also
incongruent
with what
Python
intended
a
certain
amount
of
those
things
like
our
valid
use
cases
like
let's
say
in
the
case
of
adders
create
valid
classes
for you
from
minimal
information
that
you
provide
in
source
code
so
this
class
is being
fully
functional
at
runtime
however
the
type
checker
does
not
know
this
it
just
sees
like
just
some
magic
decorator
and
just
this
minimal
set
of
attributes
on
it
and
it
does
not
know
that
a
certain
amount
of
built
in
methods
have
been
created
and
a
certain
amount
of
functionality
within
it
has
been
added
so
at
least
in
the
case
of
mypy
Empire
additional
functionality
had to
be
implemented
in
those
type
checkers
to
understand
that
those
types
actually
behave
a bit
differently
from
regular
classes
but
that's
just
something
that
users
want
something
that
users
need
so
we're
going
to
be
extending
that
cool
Anthony
what do
you
got
next
on
our
list
here
so
ship
it
we're
good
yeah
I think
we're
done
now
that
actually
that
pep
in
particular
the
type
dictionary
pep
I've
been
thinking
if
anyone
seen
the
json
schema
project
it's
really
cool
it's
basically
a way
of
defining
a
schema
for
json
documents
you can
definitely
see
that
if
this
pep
gets
accepted
somebody
will
build
tooling
to
integrate
between
the
json
schemas
and
this
new
type
dict
type
yeah
I think
it makes
perfect
sense
I mean
dictionaries
are so
similar
to
json
in a
and
they
both
have
this
sort
of
dynamic
but
mixed
types
and
I mean
they're
very
sort
of
mappable
yeah
so
I think
it's
just a matter
of time
until
someone
builds
a
library
where
you
give it
a
json
schema
and
it
will
generate
a
type
dict
class
and
then
you
use
that
class
similar
in
the
same
way
that
you
in
an
ORM
when
you
would
describe
a
data
class
and
then
you
would
deploy
it
as
a
database
it's
basically
like
a
similar
way
of
reflecting
documents
that's
cool
I can
definitely
see
for
serialization
like
you
say
this
function
takes
a
type
dict
but
what
actually
this
is
a
form
post
or
JSON
post
or
you
know
like
a
rest
call
or
something
like
that
that's
cool
so
let's
see
did
we
talk
about
multiprocessing
is that
coming in
3.8
or is
that
beyond
that's
in
3.8
so
one
particular
thing
that
is
not
pep
worthy
but
it's
still
a
very
interesting
new
feature
is
that
traditionally
multiprocessing
which has
been created
to solve
the gill
problem
has solved
it
you know
partially
what I
mean by
this
is that
yes
there
is
a
master
process
that
creates
a
bunch
of
children
and
then
delegates
work
to
it
so
you
can
just
call
python
functions
and
those
python
functions
actually
are
executed
on
the
other
side
in
the
child
process
but
the
way
this
is
achieved
was
that
function
call
has
been
pickling
the
arguments
of
the
function
you're
calling
that
ended
up
being
on
the
child
side
that
child
unpickled
the
arguments
it
did
the
computation
it
needed
and
then
if
there
was
a
return
value
it
wanted
it
actually
had
to
pickle
that
return
value
again
and
pass
back
to
the
master
process
unpickled
the
return
value
again
and
if
that's
big
it's
very
slow
for
example
for
small
things
that
was
mostly
fine
but
if
you
had
a
gigantic
haystack
and
you
were
looking
for
a
needle
in
it
just
a
pickling
that
haystack
was
taking
a
lot
of
time
we
were
going
to
run
that
on
all
six
cores
so
here's
six
copies
of
our
10
megabyte
whatever
that
is
actually
annoying
because
if
you
had
a
master
process
that
gets
web
requests
in
the
time
that
you
are
spending
on
pickling
that
haystack
nothing
else
can
be
actually
done
in
Python
because
the
gill
is
still
there
on
that
master
process
so
you
are
solving
the
gill
problem
only
partially
so
now
multiprocessing
introduces
this
new
fantastic
feature
where
you
can
declare
a
shared
memory
between
parents
and
children
what
that
does
is
you
can
actually
get
away
with
a lot
of
serialization
and
deserialization
so
for
certain
kinds
of
tasks
like
search
like
filtering
this
will
decrease
the
churn
just
needed
to
pass
data
around
meaning
it
will
bring
us
way
closer
to
the
world
we
want
to
see
which
is
that
yes
there
are
certain
Python
processes
you
know
they
still
have
the
guild
but
it
does
not
matter
because
we
can
use
as many
of
those
processes
as we
have
cores
and
everything
is fine
yeah
and you
don't have
the replication
of memory
and the copying
and all that
that's awesome
yes
so I'm
really excited
when I saw that
come out
I'm like oh
this is going to be
great so that's in
3.8
yes that is already
in
cool and
what about
the sub
interpreter
5.5.4
that's
beyond
oh so that's
interesting
that is
kind of
related
yeah
they're
in the
same
category
yes
however
the
multiprocessing
feature
like does
have
limitations
right
like the
the shared
memory
segment
is not
right
for
any
arbitrary
Python
object
there's
like
you know
restrictions
on
what
types
you
can
use
that
was
actually
a
complex
functionality
to be
added
you know
within
particular
operating
systems
shared
memory
handling
is
way
different
so you
have to
understand
how those
differences
work
and
which
process
is
now
responsible
for
creating
that
shared
memory
segment
and
shutting
it
down
and
freeing
that
memory
when
everything
is
shutting
down
so
that
is
all
great
work
by
Davin
Potts
like
multiprocessing
is one
thing
but
sub
interpreters
is
what
if
you
had
this
multiprocessing
API
and
actually
just
had
one
process
and
just
used
many
Python
interpreters
within
it
each
with
its
own
gill
to
achieve
that
many
changes
in
the
Python
API
have
to
be
added
like
a
much
clean up
internally
in terms
of
what
constitutes
local
and what
constitutes
global
state
have to
be
done
Eric
is
working
hard
on
that
as far
as I
can
tell
this
is
deferred
to
Python
3.9
I'm
eagerly
awaiting
that
I think
this
is
going
to
be
a
great
improvement
yeah
it
could
definitely
change
the
threading
story
in
multipress
processing
strong
in
Python
async
in a way
is super
cool
for
IO
bound
stuff
but
threads
have
always
been
a
kind
of
well
sometimes
they're
helpful
sometimes
they're
not
depends
and
this
could
be
awesome
right
you
could
just
dedicate
a
sub
interpreter
to
each
thread
right
and really
get free
of that
I agree
cool
all right
well
thank you
both
for
sharing
what's
coming
pretty
excited
about
3.8
cool
that was
a pleasure
yeah
it's
going to
be
great
yeah
and
on that
topic
as well
I guess
we've
got
3.9
so some
of the
PEPs
are being
deferred
to
3.9
and on
the
topic
of
sub
interpreters
the
unpacking
of the
startup
sequence
and also
the
initialization
configuration
there's
two
proposals
for that
one
is
PEP
4.3.2
and the
there's
PEP 587
which are
interrelated
because if
you have
sub interpreters
you want
the interpreter
startup time
to be fast
and also
the configuration
to be flexible
so I think
3.9
will definitely
see
some more
proposals
related to
that
which are
going to
hopefully
improve
the startup
time
of
Python 3
as we know
it's a little
behind where
Python 2
was
for various
reasons
but that'll
be a great
step forward
yeah
that'd be
really awesome
and then
it also
might make
this sub
interpreter
stuff
even better
if those
little
sub interpreters
can get
created
faster as
well
I don't
know
how
related
they
are
but
pretty
cool
pretty
cool
all right
one
we used
up almost
all our
time
so I won't
keep you guys
much longer
but
especially
Lucas let me
ask you this
like will
there be a
Python 4
and does
it matter
I mean
on one hand
like we've
got stuff
that's 0.1
2 versions
that have been
around for 10
years with 100
releases
we've got
Python 3
if we don't
have like major
breaking changes
is there a
reason to start
calling it 4 and 5 and 6
or is that just
gonna like scare
people with the
history or like
what's your
perspective here
we are at
Python 3.8 now
we're about to
release 3.9 later
you know another
18 months later
historically
Guido expressed
his distaste
with numbers
after the
decimal point
that have more
than one digit
right and so
he disliked
the notion of
having 2.10
2.11
same with
3.10
3.11
however we have
both philosophical
and technical
challenges
with just
releasing a
Python 4
well the
obvious philosophical
one is that
the transition
between Python 2
and Python 3
was very
very challenging
right it took us
a lot of effort
and there's a lot
of fatigue
I think in the
community
we just not
go through that
again for a while
absolutely
our closets
are still full
of skeletons
so like
we are really
trying hard
not to make
that mistake
again
it's not only
a problem
for the users
it was also
unpleasant
and a problem
for the core
developers
so we are
really careful
to make changes
in a very
incremental manner
now and
communicate them
well and make
them gradually
so that we are
disrupting our
users the least
which just means
calling something
Python 4
well would
probably be just
scary on its
own just on the
power of that
number but just
more practically
speaking because
of this Python 2
and 3 transition
there is a ton
of code in the
wild that does
checks exactly
for the number
3 in this
version and
version info
and those checks
would you know
become invalid
if we introduced
Python 4
like which is one
of the reasons
why you know
like Linux had
problems when it
suddenly became
Linux 3 and
why we have
Windows 10 now
just for that
practical reason
I do expect
that we're gonna
see Python 3.10
first at least
before we ever
decide to call
the next release
Python 4
yeah yeah so
3.10 is way
more likely
maybe we should
call it Python 6
because then it's
like two times
three
well I was
wondering if
there's a proposal
to introduce
calendar versioning
to Python
oh yeah what do
you think about
calendar versioning
if Python 2.7
was called
2014.1
actually yeah
yeah yeah
maybe people
would reconsider
really 2014
what's up here
like we just
upgraded from
2013
it would
certainly
remind people
how old
that Python
distribution is
so maybe
that upgrade
faster
that's funny
well I'm in
no power to
just you know
like make that
change
I could be
in power to
create a pep
about it
but this is
probably not a
sword I'm willing
to fall on
however like let me
tell you this
like all of my
private projects
do use calendar
versioning like
that's the only
versioning that I
am familiar and
comfortable with
there's obviously
semantic versioning
but I don't know
about others but
at least I
don't see myself
being as strict
and consistent
with applying
semantic versioning
like every time
what does it mean
to push the
major version
versus minor
version like
yeah so obviously
there's rules but
like the devil is
in the application
like do you apply
those rules
consistently and
every given time
like you know I
wrote an auto
formatter because I
was not able to
apply rules of
code styling you
know consistently
and every time
so I don't trust
myself enough to
do the same for
semantic versioning
and if I'm not
doing that then my
users cannot
depend on you
know what they
expect from
semantic versioning
hence just using
calendar versioning
way easier adopted
by many popular
projects like Ubuntu
like Twisted like
others yeah I
love the calendar
versioning I don't
know that it makes
sense for like the
main Python maybe
maybe it does maybe
it doesn't it would
be effective on
showing how old
some stuff is but
certainly I feel like
semantic versioning
requires like on
libraries it requires
some expertise in
that library like I
depend on library a
it depends on
library b I see
that when I pip
installed it it's
0.1.3 six months
later is that out of
date I have no idea
like I don't even
know like roughly how
old that is but if I
saw the calendar
version on all the
dependencies or stuff
I'm not super
familiar with be like
oh yeah this is
actually this is
pretty much new or
it's old like it
just it makes it
easier for newcomers
I think yeah all
right guys thank you
for being on the show
and sharing all this
and looking forward to
when you actually
release 3.8 I'm
looking forward to
that too thank you
very much I can
imagine thanks
Michael yeah bye
this has been another
episode of talk
Python to me our
guests in this episode
have been Lucas
Lenga and Anthony
Shaw and it's been
brought to you by
Microsoft if you're a
Python developer
Microsoft has you
covered from VS Code
and their modern
editor plugins to
Azure pipelines for
continuous integration
and serverless Python
functions on Azure
check them out at
talkpython.fm
slash Microsoft
want to level up
your Python if
you're just getting
started try my
Python jumpstart by
building 10 apps
course or if you're
looking for something
more advanced check
out our new async
course that digs into
all the different types
of async programming you
can do in Python and
of course if you're
interested in more than
one of these be sure to
check out our
everything bundle it's
like a subscription that
never expires be sure
to subscribe to the
show open your favorite
podcatcher and search
for Python we should
be right at the top
you can also find the
iTunes feed at slash
iTunes the Google Play
feed at /play in
the direct RSS feed at
/rss on talkpython.fm
this is your host
Michael Kennedy thanks so
much for listening I
really appreciate it now
get out there and write
some Python code
you're welcome you're a
good one you're a good one
you're a good one you're a good one