►
From YouTube: 2019-10-17 Python SIG
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
B
C
C
C
C
D
D
D
D
D
D
D
Yeah
so
I
put
a
note
in
the
agenda
here
that
I,
you
know
we
still
have
that
big
block
of
everybody's
name
and
contact
info,
so
I
just
move
this
out
to
your
spreadsheet.
I
didn't
put
everybody's
contact
info
in
because
I
wasn't
sure
that
everybody
wanted
it
like
their
email
address
out
on
the
internet,
but
I
just
I
grabbed
everybody's
information
from
the
last
couple
cells
and
just
put
them
in
here.
D
So
if
you
want
to
add
your
information,
I
just
add
it
here
and
then
that
way
we
can
have
like
one
list
of
everybody's
name
and
you
know
get
up,
handle
an
email
address.
So
hopefully
this
is
useful
to
find
other
people
in
your
same
time,
zone
or
figure
out
like
when
some
reviewer
is
likely
to
respond.
I
thought
it
was
better
to
add
some
in
one
spot
then
keep
putting
it
in
the
agenda.
D
D
So,
if
there's
anything
that
you
think
belongs
to
one
of
these
milestones,
just
you
know,
feel
free
to
add
it
and
it's
it's
kind
of
arbitrary.
What's
what's
in
three
and
four
and
I
think
probably
as
we
get
closer
to
the
due
dates
for
each
of
these,
we
can
figure
out
what
we're
actually
going
to
put
in
them.
D
D
So,
in
that
case,
I
think
it's
up
to
like
basically
everyone
and
all
of
this
things
just
to
go
push
the
spec
forward.
Yeah,
like
I,
think
at
that
point
we
have
two
options
right:
it's
as
we
go
ahead
with
the
release
and
say
do
the
same
thing
that
we
did
with
with
metrics
for
the
the
first
alpha
or
just
say,
here's
a
limited
set
of
features
and
we're
just
gonna
release
this
anyway
got
it
or
we
change
the
dates.
We
say
if
we
want
to
do
the
same
thing
that
the
spec
sig
is
doing.
D
A
So
I've
been
closely
following
the
PR
that
Josh
put
up
for
user
facing
API
I.
Think
it's
really
well
written
like
if
you
guys
have
not
sure
at
all
of
the
home
metrics
works,
I
really
recommend
reading
it.
It
spells
out
a
lot
on
how
a
user
can
create.
You
know
metrics.
Unlike
sin
sin
like
you,
know
the
corn
metrics
in
three
different
ways.
A
It
also
outlines
a
lot
of
things
that,
like
we
don't
have
in
the
SDK
yet
and
I'm
starting
the
API.
Yet
it
was
kind
of
what
I
was
waiting
on.
I
haven't
been
doing
much
open
flow
entry
stuff
this
week,
I
was
gonna,
wait
on
like
until
it
gets
approved,
but
it
seems
like
the
general
consensus.
Is
that,
like
we're,
gonna
be
going
ahead
with
this
they're
just
still
fleshing
out
some
certain
details
like
whether
to
still
include
deletion
of
life
handles?
A
D
D
A
So
both
of
them
are
for
the
for
exporters,
for
metrics
and
I
was
economy.
Dhensby
cuz,
like
I,
wanted
to
rush
them
out
for
the
previous
alpha,
but
it
actually
didn't
really
make
sense,
because
we
didn't
have
a
good
exporter
story
and
we
kind
of
still
don't
have
a
good
exporter
story
about
like
how
we're
gonna
handle
this
and
so
think.
A
D
A
D
Okay,
I
said
so
so
no
reviews
on
either
one
of
these
until
until
like
this
next,
yes,
yes,
okay,
okay,
so
yeah
Riley.
You
asked
on
the
Oklahoma
tree
project,
page
yeah
in
the
in
the
website
repo.
There
is
a
paste
into
the
dock,
there's
a
script
that
just
like
polls
github
to
see
how
many
issues
in
each
of
the
milestones
are
done,
and
it
looks
for
milestones
named
like
oh
two
or
three,
oh
four,
and
then
it
just
takes
a
percentage
from
like
the
the
smallest
milestone
or
like
that.
The
most
recent
complete
milestone.
D
D
D
F
D
D
D
F
Yes,
yes,
yeah
yeah,
I,
remember
yeah,
sorry,
it
yeah
the
last
time.
I
had
seen
this.
There
was
no
specific.
You
know.
I
mean
there
was
not
the
details
of
every
version,
so
yeah
I
get.
It
was
changed,
but
it's
static.
Yes,
I'm
sure
it's
not
code
related.
D
So,
like
one
big
obvious
woman
is
just
like
have
automated
releases.
So
if
you
create
a
github
tag,
we'll
push
the
release
out.
So
we
have
some
open
questions
about
how
we
version
each
of
the
packages.
You
know
whether
we're
trying
to
keep
them
in
sync
with
each
other,
whether
we
keep
them
in
sync
with
the
like
the
other
client
libraries
and
we're
gonna
solve
that
before
the
beta.
Definitely
but
I
would
love
to
get
this
figured
out.
You
know
before
the
next
release.
It's
just
so
they
can
be.
D
You
know
as
easy
as
updating
the
changelog
pushing
a
get
tagged
and
then
having
everything
go
to
pi
PI,
so
I,
don't
think
Allen,
Allen,
Feldman
you're
on
the
call
I
don't
see
in
the
gallery
that
he
has
a
cool
solution.
Very
pushy,
think
that
using
cell
tools
SCM,
which
we
might
try
to
use,
but
then
we're
locked
into
a
certain
version
numbers.
If
we
do
that.
C
C
D
Okay,
yes,
I
will
leave
it
up
to
us
k
to
respond
to
the
comments
here.
Although
a
question
looks
like
you
got
blocking
comments
here:
okay,
yeah
I.
Don't
to
make
sure
that,
like
this
one,
because
I
noticed
that
we
you
know,
while
we
don't
have
coverage,
we
continue
to
add
new
tests.
The
new
codes
new
code
that
does
not
have
tests
so
I
think
there's
a
good
argument
for
getting
a
version
of
this
in
that
works
and
then
taking
some
of
the
blocking
comments
out
to
sever
PR.
D
C
D
C
C
And
so
it
it
looks
like
who
using
the
PI
test
is
a
still
an
issue
for
someone
I.
D
D
D
B
Sure,
thanks
for
rescheduling
the
agenda
Frank,
so
the
PR
has
been
open
for
a
while.
Now
I've
got
some
really
good
points
of
feedback.
I
think
I've
addressed
most
of
them.
By
now
there
was
still
some
open
stuff
by
them
on
it.
The
biggest
thing
I've
been
doing
recently
was
working
on
adding
typing
information
more
or
less.
Tomorrow
is
everything
and
for
that
I
needed
to
basically
write
that
five
six
one
stub
for
open
tracing
because
of
interesting
is
not
typed.
B
For
now,
I
just
created
it
as
a
stab
only
package
under
the
ext
package,
our
folder,
but
I
guess
we
can
I
mean.
If
we're
not
releasing
a
new
version
of
open
tracing,
then
we
cannot
contribute
it
there
right
and
then
it
has
to
be
a
standalone
package.
It
only
contains
typing,
but
yeah
I
guess
I
mean
we
can
start
with
kind
of
a
package.
That's
that's
part
of
the
facility
of
the
open
to
entry
path,
library
and
then
we
can
later
decide
to
I.
B
F
B
I'm
doing
just
to
clarify
I'm
doing
the
absol
just
to
get
a
green.
My
pie
run
so
that
we
can
basically
have
proper
CI
for
the
bridge
as
well.
That's
all
I'm
not
really
investing
on
the
open
tracing
side
of
things
too
much
just
a
minimum.
You
know
the
bare
minimum
stops
that
I
can
so
that
I
can
run
my
pie.
B
Other
than
that,
does
you
see
yeah?
There
is
one
yeah.
There
is
one
pretty
big
technical
issue
that
is
isn't
dressed
yet,
which
is
saving
the
state
of
wrapper
objects
that
are
related
to
the
currently
active
span,
so
that
when
someone
activates
his
fan
and
receive
the
scope
and
then
queries
for
the
active
spam,
it,
the
user,
receives
the
same
object.
The
same
scope
wrapper
object.
This
is
kind
of
tricky.
B
There's
been
some
nice
ideas,
mainly
from
Christian
I,
think,
but
it's
not
implemented
yet,
and
this
is
kind
of
I
mean
there
are
two
dues
in
the
code
all
over
the
place
regarding
that
and
it's
not
resolved
yet
so
I
guess
we
should
decide
whether
we're
gonna
wait
until
I
manage
to
dress
up
or
live
that
reduces
their
marriage.
The
initial
version
without
handling
that,
because
if
the
user
isn't
doing
comparison
like
of
object
identity,
they
just
check
the
data,
is
I
drop
the
object
like
context,
for
example,
then
this
is
fine.
B
F
By
the
way
we
don't
in
open
tracing,
we
don't
require
these,
but
it's
an
improvement
that
I
would
like
to
see
anyway.
So
my
my
take
on
this
is
that
we
should
merge
it
and
either
a
total
or
a
ticket
for
that,
because
there
are
a
pair
of
things
to
take
into
account
that
we
need
to
discuss.
You
know
when,
when
we
do
this,
it's
not
so
tricky
because
of
how
they
are
been
tracing
API,
so
on
so
yeah.
This
might
you
know
yeah.
F
B
And
one
last
question
on
the
same
topic:
there
are
still
two
Doosan
extract,
an
engine
extract
and
inject
I.
Don't
have
a
good
estimation
of
how
complicated
should
be
to
implement
these
it.
Just
I
did
look
at
this.
Yet
so
should
we
wait
for
that
with
merging
or
also
merge
and
open
full
of
issues
for
inject
and
extract
as
well
now.
D
Cool
so
I
got
one
question
about
the
bridge.
Is
there
think
this
is
a
question
for
Carlos
to
do?
You
guys
have
like
some
like
like
small
example,
app
that
is
already
instrumented
using
open
tracing
that
we
could
try
like
plugging
in
this
bridge
and
then
seeing
what
it
exploit
may
not
exports,
but
we.
F
D
F
F
F
B
F
B
Just
want
to
say
that
they
also
included
the
tiny
snippet
of
just
if
you
dummy
lines
of
code
with
with
damn
instrumentation
using
the
bridge
in
the
description
of
the
BR,
just
so
that
you
can
see
that
the
bridge
works
but
I'm,
not
testing
like
I
mean
it's
not
extensive
in
any
way
or
comprehensive,
em
and
you're
I'm,
not
testing
like
strange
scenarios
and
stuff
I'm,
just
initializing
the
bridge
and
see
the
second
update.
Jake
and
I've
used
a
memory
span
exporter
just
to
print
stuff.
Basically,
so
no
real
exporter
and
Oh.
F
D
D
Okay,
so
next
thing
back
up
on
the
earlier
part
of
the
agenda,
I
I
noticed
that
I
am
spending
a
lot
of
time,
just
fixing
type
errors.
A
lot
of
these
are
like
spurious
or
real,
but,
like
ultimately
useless
type
annotations
right
now
we
have
three
different
mypie
configs
that
we
run
as
part
of
the
lint
check.
I
am
curious
if
anybody
has
a
solution
for
typing.
D
This
is
kind
of
an
open-ended
question
and
I
think
it's
probably
one
that's
faster
to
talk
about
in
person,
then
on
like
something
like
a
github
issue.
But
my
my
impression
is
that
typing
right
now
is
adding
more
detriment
than
benefit
and
like
it
takes
a
lot
of
extra
like
working
time
to
add
type
annotations,
and
it
doesn't
doesn't
give
us
a
whole
lot,
because
we
only
get
this
ecstatically
and
a
lot
of
the
like.
B
It
a
general
Python
question
I
mean
it
sounds
to
me
like
this.
Is
you
just
more
or
less
describe
how
things
are
in
the
Python
community
right
I
mean
unless
another
word
of
something
so
I
mean
that's,
that's
the
problem,
I
guess
with
with
Python
typing
right
now,
it's
optional!
It's
it's
only
it's
not
really
enforced.
You
need
to
run
static
checks
to
figure
out
things.
I
mean
I
personally
already
caught
like
one
or
two
small
problems
in
the
bridge,
for
example,
while
adding
typing
information,
but
for
the
most
part
coming
at
run
time.
D
D
Well,
we
do
this,
like
particular
problem
that
if
we
were
only
releasing
something
like
the
API
package
like
or
if
we
were
like
are
our
own
only
consumer,
then
it
would
be
easy
to
like
just
type
part
of
the
library
right,
but
as
it
is
now
where
we
have
this
like
this
weird
SDK,
API
separation,
and
we
want
to
type
the
API
so
that
you
know
the
types
are
effectively
part
of
the
documentation,
but
we
don't
necessarily
want
to
type
the
whole
SDK.
Then
we
run
into
this
problem.
D
Where
you
know
type
checks
are
either
they're
not
meaningful
because
we're
not
type
checking
SDK
or
it's
exhausting,
to
write
them,
because
then
we
have
to
like
add
it
everywhere.
We
call
the
API,
so
I
think
it's
like
also
because
of
the
structure
of
our
project
that
I
think
becomes
kind
of
a
hassle
but
I'm
curious.
How
much
time
do
people
spend
like
adding
type
annotations?
It's
like
Riley
I
know
like
I'm,
looking
at
your
PRS
and
there's
like
a
ten
commits
that
I'll
say
typing.
E
Yeah
I
spend
five
minutes
writing
code
and
spend
a
day.
Okay,
be
honest,
but
I
I
think
like
having
that
type
information
in
the
API
is
not
just
going
to
benefit
us.
It's
for
people
who
consume
the
API
package
if
they
use
some
like
ID
tools,
they
want
some
alcohol
like
hint
or
they
want
some
like
hijacking
in
in
their
project.
It
gives
them
the
flexibility
whether
it's
benefiting
us
on
us
like,
based
on
my
personal
experience,
I
I,
think
I'm
actually
spending
more
than
what
I
got.
E
B
I
mean
it's
exactly
the
same
situation
that
I
had
right
now
with
open
tracing
of
interesting
did
not
include
typing
info
I'm,
an
unopened
Racing
consumer,
so
I
need
to
create
a
stub
for
it.
So
if
we
don't
create
that
for
the
public
facing
that
the
public
ap
has
them,
one
of
the
first
users
is
going
to
write
a
stub
because
they
happen
to
use
typing
in
their
instrument.
Applications.
E
Probably
one
one
option
is
to
split
the
file,
so
put
all
the
thing
that
you
want
people
to
consume
in
a
separate,
folder,
so
case
file.
As
long
as
we
don't
mess
up
the
module,
Hiraki
horror
from
aside
I
think
they're
like
different
personas.
One
is
the
end
customer
who
has
no
idea
about
how
open
telemetry
project
works.
Oh,
who
they
are?
They
just
take
this
SDK
or
API,
and
the
instruments
do
their
stuff
and
they
follow
the
document.
E
They
have
a
paid
job
to
to
do
this,
and
if
it
sucks
like
they,
don't
have
this
Auto
compassion
from
the
idea,
though,
since
they
wouldn't
complain
so
treat
this
developers
similar
like
me
to
worry
in
the
same
situation
where
the
developers
that
contributed
to
the
open
telemetry
product-
and
with
this
we
we
spend
some
time
on
the
hiking
and
also
we
get
something
in
this
case.
I
feel,
like
probably,
were
spending
more
than
what
we
got
and
I'm
the
exporter.
Developer.
I,
don't
know
open
climate
I
probably
will
be
fine
without
type.
E
E
E
D
Okay,
this
to
me
sounds
like
an
argument
for
yeah
like
like
coming
up
with
a
package
structure
that
separates
the
like
the
vendor
facing
API
and
the
user
facing
API
and
then
like
having
good
documentation
and
type
checks
for
one
and
not
really
the
other,
or
rather
to
like
separate
these
in
the
way
that,
instead
of
both
people
reading
both
sets
of
documentation,
we
have
like
different
docs
for
different
users.
Yeah
and
maybe
that'll
inform
the
back
of
structure
too
I.
A
D
Yeah,
so
I
I
think
there's
still
a
lot
of
work
for
us
to
do
here,
and
if
people
like
work
on
other
projects
and
see
that
they
have
a
good
solution
of
typing
or
like
even
if
you
just
come
up
with
like
a
better
workflow
for
working
with
types,
I
think
everybody
be
interested
to
hear
it.
There
are
people
like.
Are
you
guys
using
something
like
vs
code
that
actually
uses
the
type
annotations
in
the
editor.
E
E
D
E
D
Okay,
so
one
thing
that
you
know
because
I
was
just
looking
at
the
the
double
underscore
all
special
attribute
that
we
got
on
a
bunch
of
net
files.
I
noticed
that,
like
basically,
there
are
two
ways
we
can
structure
this
project
right.
One
is
that
we
have
top
level
in
that
files
that
expose
all
of
the
attributes
like
classes,
and
you
know,
modules
or
whatever
that
we
expect
to
be
in
the
API,
but
then
we
put
them
anywhere
else.
D
We
want
in
the
package,
or
we
put
just
everything
in
like
the
the
files
that
make
sense
to
us,
and
then
people
have
to
use
those
import
paths.
The
the
reason
this
comes
up
now.
Is
that
like
we?
If
you,
if
you
look
at
some
of
the
init
files
that
import
things
from
their
sub
packages,
then
we
get
to
possible
import
paths
for
those
objects
or
for
those
classes,
and
we
right
now
we're
using
both
import
paths
right.
So
I
am
curious
to
see
what
people
think
about
this.
D
A
A
D
E
So
my
suggestion
take
context
for
them
I
just
this
is
some
like
examples
in
the
chat
window,
I.
Think,
for
example,
we
won't
be
able
to
use
that
this,
like
capitalize
the
contacts
they
should
be
within
the
the
top-level
package,
so
it's
open
to
manage
without
contacts
namespace
instead
of
having
to
expose
the
implementation
detail
in
this
case,
like
the
reason
to
put
all
here
is
with
this
module
Oh
reference,
all
the
interface
that
we
exposed
the
customers.
E
D
E
E
In
this
way,
I
feel
like
this
base
contacts
is
the
implementation
detail
if
Ike
I
could
rename
this
to
like
right,
leg,
contacts
and
people
shouldn't
be
affected,
and
these
if
they
want
to
explore
this,
is
come
imported
directly
from
their
code.
It's
our
problem
in
this
way,
I
wonder,
like
probably
even
makes
sense
to
make
a
like
underscore
at
the
beginning
of
the
folder
like
from
this.
E
Although
I
haven't
seen
this
practice
in
Python,
but
I
think
it
possible,
but
basically
these
things
are
not
considered
as
public
interface
and
because
this
is
within
package,
so
I
think
the
developer
has
a
flexibility
to
either
like
import.
That
directly
from
like
the
implementation
detail
act.
Here
we
put
the
base
contacts
or
you
can
roll
to
the
public
interface
import
from
this
package.
It
doesn't
matter
so.
E
If
then,
for
example,
if
there's
another
like
a
code
in
the
API
which,
for
example,
metrics
they
can
import
the
right
clip
from
this,
like
contacts,
thought
base
contacts
or
they
can
import
from
contacts,
we
don't
care,
because
this
is
the
same
package,
we're
not
going
to
release
them
separately
or
from
the
ice
DK.
I,
don't
expect
the
ice
DK
to
import
from
open,
telemetry
dot
tongue,
text-based
comebacks,
because
this
breaks
the
package
level
contract.
E
D
Yeah
that
makes
sense,
I
I,
think
it's
gonna
happen
now
as
we.
If
we
try
and
like
be
principled
about
this
and
expose
everything
that
we
consider
part
of
the
public
API
in
these,
like
top-level
init
packages,
it's
hitting
it
really
hard
to
come
up
with
a
package
structure
that,
like
doesn't
give
us
import
errors,
so
it
I
I
think
it
may
be
worth
doing
and.
E
I
think
about
circular
reference
photo
reference
wouldn't
happen
between
an
SDK
or
between
any
two
packages.
Right,
it
can
only
happen
within
the
same
package
way.
We
gave
people
freedom,
your
import
from
whichever
path
you
feel
convenient,
and
the
first
part
is
to
avoid
the
circular
reference.
Okay,.
D
Yeah
I
mean
I,
think
that's
a
good
argument
for
say
like
inside
the
same
package,
only
only
using
the
internal
pads
and
then
externally,
using
the
the
external
path,
but
I
think
that
I
think
the
circular
reference
will
come
from
like
even
just
the
like
importing
the
class
at
the
top
level
right,
not
not
trying
to
use
it
from
another.
Another
module
inside
the
same
package.
E
D
Get
we
didn't
I
I
can
maybe
just
like
comment
on
the
PR
I'm
working
on,
because
I
think
this
will
probably
take
more
time
than
we
have
here.
But
the
thing
that
I'm
saying
now
is
I
like
have
a
separate
sampling,
sub-packages
part
of
trace
and
I
want
to
import
the
entire
sampling
like
sub
package
and
traces
in
it,
so
that
you
can
reference
it
as
like
trace
that
sampling,
but
I
also
need
to
do
like
the
reverse.
Import
I
see.
A
D
E
D
Yeah
dagger
points
out
that
we
can
also
like
just
hide
our
our
own
internal
classes
by
giving
them
underscore
names
and
then
re
important
them
without
the
underscores,
which
is
true
but
I,
think
it's
it's
a
puzzle.
It
makes
things
a
little
bit
difficult
to
read
and
you
know
it's
the
kind
of
convention
that
we
would
like.
You
need
to
adapt.
E
It
depends
the
freedom
how,
if
you
have
a
file
where
you
have
a
hundred
things,
and
only
one
thing
that
you
don't
want
to
export,
then
probably
it's
more
convenient
to
make
an
underscore.
However,
you
have
like
a
file
with
99
things
that
you
don't
want
his
poor
export
then
having
at
all.
This
is
the
power
from
hidin
against
you,
a
better
control
and
also
that
that
all
gives
a
benefit.
E
I've
seen
like
seen
in
like
big
teams,
where
you
have
a
lot
of
developers,
contributing
and
and
some
people
will
have
different
relational
belief,
so
they
introduced
some
new
classes
and
they've.
Having
that
all
will
prevent
accidental
league
of
a
public
interface
in
people,
freedom,
you
can
introduce
your
own
helper
class,
but
if
people
want
to
expose
that
they
have
to
modify
oh,
this
is
a
red
sign
and
people
that
this
is
very
extra
place
it
and
during
Colorado
people
can
say:
oh
this
PR
you're,
trying
to
expose
something
new.
E
So
having
that
always
somewhat
like
helpful
in
this
case
yeah
the
team
size
like
I,
think
here
we
we
got
a
relatively
small
him
like
we
got
a
a
hundred
people
in
the
community
and
ten
folks
have
the
power
to
approve
and
merge
anything.
Then
we
probably
will
go
with
all
for
now.
I
I,
don't
see
a
strong
reason,
so
I'm
fine
with
either
side
I
think.
D
Is
like
a
pretty
good
argument
and
in
general,
for
sticking
to
conventions
that
are
that
are
like
obvious
to
developers
coming
from
the
outside,
so
that
like
people
can
still
read
the
source
code
and
not
be
like
very
surprised
about,
say
how
you'll
import
things
and
I
think
we
also
have
like
we
see.
This
is
like
properties
and
public
attributes
now
we're,
because
we
don't
have
a
single
standard
way
of
doing
it,
and
we
don't
like
write
this
anywhere.
C
D
D
Yeah
nominate
Riley
is
dictator,
okay,
so
I
think
we
should.
We
can
skip
air-handling
for
now,
because
this
is
kind
of
just
a
open
question
about
like
where
we
want
to
catch
errors
just
to
like
to
mention
it
quickly.
I
think
probably
it
makes
sense
for
us
to
have
something
that
looks
like
a
like
an
exception
handler
like
our
own
bit
of
code.
This
is
like
throw,
but
it's
like
utilities
that
throw
or
something
and
instead
actually
throwing
it
only
throws.
D
D
F
Came
too
late
for
that
for
reviewing
that
ticket,
but
yeah
I
was
wondering
it's
a
very
specific
technical
question
and
it
felt
correct
to
us
here
instead
of
going
and
comment
on
the
clothes
PR
yeah.
So
in
Java
we
have
both
canonical
status
codes
and
such
codes,
and
we
have
like
wilting
values
for
both
of
them.
So
you
don't
have
to
you,
know,
just
go
and
create
and
use
that
subject
you
just
go
and
use
you
know,
but
do
k1
so
I
wonder
if
there's
a
reason
to
not
have
that
in
place.
F
So
the
idea
is
that
when
you
have,
of
course,
you
have
will
team
canonical
status
codes.
So
it's
fine
and
then,
when
you
have
these
status
codes,
which
grabs
or
contains
both
are
canonical
set
of
codes
prescription,
then
you
offer
some
wilting
values
that
default
today's
to
every
canonical
status
code.
Clothes
clothes
are
no
description.
F
D
Yeah,
this
is
the
way
that
I
actually
expected.
This
would
have
been
implemented.
I
think
Christian
was
the
one
arguing
for
like
like
making
every
every
status
have
a
like
a
separate
description
and
like
having
different
instances
for
the
statuses,
your
time
so
I
to
me,
that
sounds
great,
but
I
think
you
might
want
to
take
that
up
with
Christian.
Okay.
F
Yeah,
so
it
sounds
like
a
what
I
mean:
I
will
be
doing
a
PR,
then,
because
you
know
it
was
imagined
that
we
want
give
users
flexibility
to
use
to
specify
status
code
like
we
know.
We
know
description,
you
notice,
I
just
go
fast.
Instead
of
forcing
them
to
have
something,
you
know
like
a
description
but
yeah
I
will
create
a
PR
and
then
I
will
just
go
with
it,
and
it
was
a
similar
question
with
the
status
you
know
not
having
a
default
with
having
a
default
value.
F
F
D
E
G
I
popped
in
theirs
we're
moving
on
to
the
0.3
spec
work,
and
some
of
it
is
like
a
little
invasive.
In
particular,
thing
I've
been
working
on
is
like
trying
to
step
out
separate
out
context,
propagation
and
baggage
from
tracing
right
now,
they're
all
kind
of
glued
together,
I
think
that
would
be
great
if
we
could
pull
it
off.
There's
always
been
interest
in
having
contacts
propagation
being
separate.
My
concern
is
that
this
is
something
that
may
have
some
tricky
consequences.
G
If
we
actually
do
it
and
I
don't
want
to
wait
until
to
go
through
a
whole
spectra
work.
Those
out
I
feel
like
much
like
with
named
tracers,
in
fact,
and
just
interact
with
named
tracers
that
were
we
to
kind
of
like
new
work
and
if
you
spec
it
out
in
English
what
happens?
Is
you
go
to
implement
it,
and
you've
now
suddenly
realized.
There's
like
a
bunch
of
unanswered
questions
you
have
to
deal
with
and
if
you
prototype
it
just
in
Java,
then
you
end
up
with
this
spec.
G
That's
just
like
totally
over
prescribed
for
Java,
since
I
think
this
would
be
an
important
issue
to
do.
I
think
it
would
be
great
to
start
prototyping
this
stuff
a
bit
in
at
least
a
couple
of
languages
so
that
there
are
people
from
a
couple
of
SIG's
who
have
their
head
wrapped
around
this
problem,
so
that
we
can
either
move
forward
with
it
quickly
or
decide
that
this
is
just
gonna,
be
crazy,
town
and
kind
of
like
abort
the
effort
before
it
gets
into
the
spec.
G
So
I'm
going
around
to
the
different
SIG's
just
to
check
and
see.
If
there's
anyone
interested
in
working
on
this
particular
issue
and
also
in
general,
maybe
bring
up
the
comment
of
like,
should
we
be
doing
more
prototyping
or
spiking
while
doing
some
of
this
remaining
spec
work.
I
think
this
was
an
issue
with
named
tracers,
where
it
got
all
the
way
into
the
spec
before
anyone
really
started
kind
of
hacking
on
it
and
thinking
about
the
implications
I.
D
E
G
We're
not
here
I'm
glad
people
are
interested,
but
I
do
think,
there's
like
implications
that
might
actually
really
change
some
things,
hopefully
not
dramatically,
but
it
certainly
interacts
with
some
critical
components,
especially
around
things
like
context,
switching
which
right
now
are
very
span,
centric
and
I.
Think
that's
going
to
it's
just.
G
What
it
looks
like
so,
if
there's
people
interested
I,
don't
know
we
can
form
like
maybe
just
a
working
group
in
this
particular
issue
from
some
people
from
a
couple
different
languages
just
to
make
sure
we
have
like
a
fast-moving
discussion
on
this.
So
all
all,
maybe
I'll
form
a
channel
on
this-
that
we
can
all
join.
That
seemed
like
that
was
working
from
the
metrics
people,
so
great
I'm
glad
to
hear
there's
interest.
F
D
D
D
Also
on
that,
if,
if
people
see
issues
that
don't
exist
and
they're
like
interested
in
particular
like
as
possible,
that
I
left
some
of
the
milestones
as
mostly
just
moving
existing
issues,
so
especially
if
you're
working
on
another
language-
and
you
see
something
that,
like
it's
taking
a
lot
of
time
in
another
language,
I
could
be
really
useful.
I
would
take
it
yep.
C
Can
I
ask
Carlos
directly
so
yeah
car
was
so
thank
you
for
your
work
on
Python
flash
project
in
open
place
in
country.
I
know
busy
yeah
I'd
like
to
ask
you
to
release
a
new
version
since
so
the
previous
one
version
was
released
last
year
and
it's
pinned
to
it.
It
require
required.