►
From YouTube: 2020-09-10 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
C
C
C
C
D
I've
noticed
the
recording,
but
I
hadn't
realized.
This
was
getting
posted
to
youtube.
C
C
An
issue
we
can,
we
can
play
the
shell
game
with
the
zoom
meetings
and
really
confuse
people
to
like
get
him
to
join,
join
our
sig.
G
C
All
right,
I
guess
we
can.
Let
me
get
started
now
that
laden's
here.
C
Yeah
cool,
so
I
had
a
good
question.
I
think
daniel
you
brought
this
up
in
in
an
issue
or
in
a
pr
or
something.
E
C
Right,
I
know
this
sometimes
can
take
a
lot
of
time,
so
I
just
wanted
to
point
out
that,
based
on
our
like
downloads
of
packages
or
whatever,
there's
there's
very
little
to
no
traffic
for
3.4
these
days,
there's
actually
more
3.10
downloads
than
3.4.
C
I
didn't
even
know
python.
3.10
was
a
thing
yet,
but
apparently
it
is.
D
So
can
we
get
rid
of
three
or
four
please.
E
I
think
one
of
the
arguments
in
the
issue
that
I
posted
in
was
that
the
datadog
client
still
supported
3.4,
but
I
think
that's
that's
still
the
case.
C
C
Of
yeah
they
they
support
two
seven
and
three
five.
Three
six
go
up
to
three
eight,
but
I
don't
know
when
they
drop
support
for
3.4,
but
I
mean
I
guess
we
don't
have
to
follow
what
they're
doing,
but
at
the
same
time,
if,
if
we're
all
confident
that
there's
not
a
lot
of
users
using
3.4
and
like
currently
we're
already
seeing
a
bunch
of
packages
that
are
only
3.5
and
up
anyways
for
the
auto
instrumentation.
B
B
C
I
mean
removing
the
3.4
support
is
something
we
could
probably
do
like
pretty
quickly
even
before
we
ga,
but
I
don't
know,
do
you
have
a
concern.
B
One
way
or
the
other
away
yeah,
I
think
after
vrga
dropping
spot
might
not
be
a
lot
of
companies.
Do
not
move
migrate
to
newer
versions
for
a
long
time.
Even
if
it's
sort
of
deprecated
or
or
the
community
has
moved
people
using
the
sdk
and
instrumentation
might
they
might
be
written
there.
B
I
think
for
for,
for
an
sdk
like
ours,
it's
it'll
probably
be
hard
to
duplicate
older
versions.
Once
we
are
ga
like,
for
example,
at
splunk,
the
single
fx
instrumentation,
we
still
have
customers
that
are
on
python
2
and
we
are
not
able
to
drop
support
for
2.7.
B
C
Yeah,
I
think
I
think
the
difference
between
dropping
two
vert
to
support
and
up
dropping
an
early
version
of
three
3.3
support
is
a
little
bit
different,
just
because
there's
less
of
a
less
of
a
migration
there
but
yeah,
but
I
think
you're
right.
If,
if
we
don't
have
a
strong
reason
to
support
python
3.4
before
ga,
we
should
just
drop
it
now,
instead
of
waiting
until
after
gs.
I
agree
with
you.
There.
J
C
Yeah,
so
I
guess
my
my
vote
would
be
to
definitely
drop
3.4
and
we
can
add
that
into
the
issue
so
that
we
can
have
a
better
way
to
track
it
and
then
yeah
I
mean
I
guess.
3.5
support
is
going
to
have
to
go
on
because
I
think
there's
still
versions
of
ubuntu
that
use
3.5
with
their
their
main
versions.
Right.
C
C
All
right,
okay,
I
got
two
thumbs
up
I'll
go
with
it.
Next
thing
I
wanted
to
talk
about
is
just
about
the
next
release,
so
it's
been
26
days
since
the
last
release,
as
I
was
chatting
with
laden,
I
think
we've
been
kind
of
trying
to
do
monthly
ish
releases,
so
the
next
release
is
due
next
week.
If
you
have
anything
that
you're
that
you
really
care
about
getting
in
into
that
release,
I
guess
get
it
done
now.
B
I
have
a
couple
of
pr's
thanks
alex
for
giving
them
the
falcon
and
tornado
instrumentation
and
they're
pretty
straightforward,
and
I
don't
see
any
issues
with
that,
but
there's
another
one
that
might
need
further
discussion
about
automatically
setting
up
the
tracer
and
applying
instrumentations
with
the
instrument
come
on,
so
it
basically
implements
what
open
telemetry
java
has.
B
So,
if
you
with
up
until
my
java,
you
can
add
a
command
line
flag
to
your
java
executable
and
tell
it
to
auto
instrument
everything
so
so,
there's
no
need
to
add
any
modify
any
code
in
the
actual
application.
B
H
C
I
I
guess
one
thing
that
came
up
last
week
was:
do
you?
Do
you
know
if
there's
anything
in
the
in
a
spec
around
how
this
should
work
across
the
different
segs?
Because
I
know
there
was
some
some
discussion
last
week
around
that
in
this
call.
B
No,
I'm
not
I'm
not
aware
of
any
spec.
I
can
go
and
look,
but
as
far
as
I
know,
I
haven't
come
across
any
so
initially
I
ported
this
from
signalfx
repository,
but
also
java.
Hotel
has
the
same
thing,
but
I
don't
know
if
it's
in
the
spec
or
not
I'll,
go
and
take
a
look.
If
not
do
you
think
we'll
need
it?
We
need
to
define
the
spec
first
before
we
can
merge
this
or.
C
I
don't
know
if
we
needed
to
have
it
in
a
spec,
but
I
think
it
would
be
really
good
to
have
at
least
a
common
common
language
to
talk
about
how
the
different
eggs
should
be
implementing
this.
Otherwise
we
might
end
up
just
going
all
over
the
place
with
that
yeah.
B
Yeah,
probably
some
some
guidelines
would
be
nice
and
it's
it's
a
bit
harder
or
probably
not
that
big
of
a
priority,
because
this
doesn't
apply
to
any
every
every
single
language,
only
a
handful
of
them
all
right.
But
let
me
go
over
and
see
if
there's
if
something
exists
already
I'll,
let
you
know
on
getter
and
add
a
comment
to
the
vr.
C
Yeah
because
then
I
know
at
least
like
javascript
kind
of
went
off
and
implemented
something
kind
of
like
this,
or
at
least
partially
like
this,
and
I
know
that,
like
you
said
java,
has
it
and
like
ruby
will
probably
want
to
have
something
similar
and
all
like
all
the
other
runtime
languages
will
probably
want
to
have
something
similar
to
what
we're
doing.
But
if
we,
if
we
don't
have
a
spec
to
kind
of
reference,
then
there's
a
good
chance
that
people
will
just
go
and
implement
it
very
differently.
In
each
language.
C
All
right
cool,
any
other
topics
that
people
have
in
mind.
C
F
I
C
F
D
Okay,
thank
you.
So
yes,
this
br,
it's
about,
of
course,
the
global
error
handler
it's
a
an
issue
that
was
mentioned
around
in
the
specification.
D
D
If
no
error
handler
is
registered
for
any
specific
exception
that
is
being
raised,
then
there
is
a
default
error
handler
and
that
will
handle
the
exception.
So,
of
course,
you
can
see
all
that
in
the
pr,
but
pretty
much.
I
like,
of
course,
your
opinion
on
this.
I
think
I
already
got
a
review
ffe4.
D
So
this
is
a
feature
that
it's
pretty
much
done
and
it's
quite
independent
from
the
rest
of
the
code,
since
it
doesn't
affect
any
of
the
metrics
or
spans
or
anything
else.
It
can
really
it
lives
outside
of
it
is
in
the
sdk,
but
actually
it
could
be
anywhere
because
it
has
no
dependencies.
D
E
E
If
we
internally
have
an
error,
do
we
have
to
register
error
handlers
for
all
those
errors
in
in
the
entry
points,
or
do
we
do
that
in
the
default
error
handler
and
if
we
do
it
that
way,
wouldn't
it
be
better
to
have
the
error
handling
code
still
where
the
error
occurs?
E
The
way
we
where
we
have
it
now.
D
Code
think
we
basically
locked
the
exception
via
standard
login.
That
is
what
the
default
error
handler
does,
so
it
will
mean
refactoring
our
code
and
switching
the
tri
except
blocks
that
we
already
have
in
our
internal
code
for
the
context
manager
that
the
the
end
result
would
be
the
same,
and
the
other
thing
that
the
side
effect
that
that
will
cause
is
that
the
error
handlers
registered
by
the
users
will
also
be
called
if
the
exception
that
is
raised,
matches.
E
I'm
not
sure
if
I'm
answering
your
question,
video
yeah,
yes
part
of
it,
but
another
thing
is
one
example
in
the.
I
think
in
the
discussion
for
the
specification
or
the
specification
itself
was,
for
example,
a
user
provides
an
invalid
value
to
whatever
function,
for
example,
and
the
sdk
might
choose
a
default
value.
Instead,
that's
sensible
instead
of
the
invalid
invalid
value
that
the
user
provided.
So
in
that
case,
we
would
have
also
some
error
handling
code
other
than
just
the
logging
itself.
D
That's
the
context
manager.
Yes,
yes,
that's
an
excellent
point
daniel.
I
just
think
that
it's
a
bit
outside
of
the
scope
of
these
pr,
I
mean
every
individual
function
that
wants
to
do
their
own
error,
handling
that
they
can
do
by
themselves.
D
They
can
do
I
mean,
for
example,
if
you
write
a
function
and
you
know
how
to
handle
invalid
values
that
the
user
may
pass,
you
can
do
that
and
implement
it
by
yourself,
and
you
won't
need
to
use
this.
I
think
this
is
just
reserved
for
the
situations
where
the
the
code
that
we
have
done
doesn't
know
what
to
do
with
an
exception
that
is
being
raised.
D
So
this
is
this
is
the
last
resort.
E
Yeah,
I
mean
I
don't
really
know
how
most
of
the
errors
in
the
codebase
are
handled.
So,
like
I
said
it's
just
from
the
example
in
the
spec
of
the
discussion
for
it,
I
thought
that
maybe
maybe
a
callable
that
returns
whether
the
error
was
handled
by
an
external
externally
provided
error
handler.
So
so,
basically,
we
could,
for
example,
have
the
error
handler
pass
it
an
exception.
E
So
we
can
just
create
that
on
the
fly
and
then
return
whether
it
was
handled
by
an
external
handler,
and
that
way
we
could
still
do
all
the
error
handling.
We
might
want
to
do
ourselves
in
our
code
directly
without
registering
or
a
handler
like.
E
I
said
this
is
just
from
from
one
of
the
examples
that
was,
I
think
in
the
discussion
for
the
issue
where
I
thought
this
might
be
a
use
case
where
the
context
measure
might
not
be
enough,
but
it
depends
on
how
we
want
to
handle
the
errors
in
our
code
in
general.
E
Don't
know
if
we,
for
example,
have
some
of
some
coder,
for
example,
we
have,
and
this
instance
check,
and
if
it's
not
an
instance,
we
provide
a
default
value.
In
that
case,
we
don't
even
have
an
error,
but
we
are
doing
something
that
the
example
in
this
in
the
spec
of
the
discussion
was
referring
to
when
a
user
might
provide
an
invalid
value,
which
should
raise
an
error.
If
the
user
decides
that
it
is
serious
enough.
H
D
Move
to
the
next
issue,
would
you
like
to
add
your
question
as
a
comment
in
the
pr?
Please
thank
you
so
that
you
can
take
a
good
look
at
it.
Make
sure
that
I
understand
what
you
want.
K
Right
go
to
the
next
prs.
G
One
yeah
pretty
straightforward:
it's
what
I
discussed
about
two
weeks
ago,
just
trying
to
you
know
you
utilize,
the
is
recording
check
for
our
instrumentations
instead
of
just
passing
it
through
and
utilizing
the
fact
that
it's
a
default
span
so
just
starting
with
the
request
instrumentation.
C
Yeah
the
do
you
have
a
way
you
want
to
tackle
the
instrumentation
or
like
do
you
want
to
keep
issues
for
each
one,
or
do
you
want
to
create
separate
issues
for
each
one,
and
then
we
can
get
other
people
to
kind
of
help
help
along
the
way,
because
we
do
have
a
fair
amount
of
instrumentation.
Now
it
seems
like
it
might
be
a
lot
of
work
too
to
take
it
all.
On.
G
Yeah,
I
was
thinking
of
just
like
what
I
did
for
the
migrations
as
well.
The
first
one
is
just
like
all
the
http
clients
and
then
the
second
one
is
the
like.
The
database,
clients
and
the
third
one
would
be
like
everything
else,
so
even
then,
like
each
of
them
have
like
eight
or
so
so
it's
not
like
you
know
like
it's
not
going
to
be
a
not
time
consuming.
C
Yeah
yeah,
although
I
guess
if,
if
we
did
it
per
instrumentation,
it
might
get
the
reviews
through
faster
because
then
it'll
be
a
fairly
small
reviews
but
anyways.
C
G
C
G
Yeah,
just
my
personal
experience,
it's
just
that
there's
an
overhead
to
get
people
to
look
at
pr's
anyways,
so
with
flexible
changes
as
these.
Hopefully
it's
like
it
just
takes
one
pass
through
to
look
at
it.
F
C
L
Yeah
this
one
is
adding
an
auto
instrument,
an
instrument
and
an
auto
instrumentation
for
the
a
I
o
http
sensor,
so
instrumentation
so
yeah
more
or
less.
That's
it
because
you
really
had
to
do
it.
Money
manually
set
up
the
instrumentation.
If
you
wanted
that,
and
now
you
can
just
use
the
auto
instrumentation
for
that.
F
C
Okay,
this
one:
oh
this
one's
still
on
draft.
E
Is
that
it's
currently
blocked
on
the
spec,
because
we
discussed
last
week-
that's
not
really
clear
what
exactly
the
values
should
be
and
now
I'm
not
sure
if
the
variable
itself
will
stay
for
now.
So
that's
one
issue
and
the
other
issue
is
that
I've
put
the
code
for
the
variable
in
an
inner
file
that
isn't
actually
packaged
with,
which
is
the
issue
I've
linked
in
the
dock
107.8.
E
C
Yeah,
I
think
the
discussion
at
the
sig
meeting
was
around
whether
this
should
just
be
a
debug
flag
instead,
but
it
sounds
like
based
on
the
discussion
here,
there's
still
stuff
to
be
decided
here,
so
it
makes
sense
to
just
kind
of
keep
this
on
pause.
Until
then,.
E
C
C
Any
thoughts
around
what
to
do
with
this
one,
like
this
example,
there's
kind
of
there's
two
piers
that
are
kind
of
sitting
here,
actually
there's.
I
guess
three
pr's
that
have
been
sitting
here
for
a
while.
G
Yeah
so
for
the
exemplars
one
conor
was
saying
like
he
was
gonna,
leave
it
up
and
like
possibly
work
on
it,
but
there
is
the
issue
of
like
having
stale
prs
up
and
everything
in
our
repo.
So
I
think
what
would
be
good
would
be
just
to
like
just
ping
him
one
more
time
you
know
saying
like.
Are
you
still
gonna
be
working
on
this?
Are
we
still
pushing
for
this,
and
you
know
if
there's
no
response,
we
probably
would
close
it.
G
However,
that
being
said
like
this,
didn't
really
get
a
lot
of
traction
from
reviews,
even
when
he
was
working
on
it
like
this
was
at
a
state
where,
like
he
was
trying
to
merge
it
right,
even
when
he
was
on
the
team.
G
It's
just
that,
like
you
know,
not
many
people
know
about
metrics.
The
metrics
sdk
specs
is
still
like,
you
know
not
complete,
and
I
think
I
think
aaron
and
like
josh
were
the
only
ones
who
were
able
to
really
look
at
it,
and
I
just
didn't
have
the
time
to
look
at
it
either.
G
So,
and
now
with,
like
you
know
the
specs
changing
and
like
I
don't
know
if
conor
is
available
to
answer
questions
right
like
I
don't
know
if
it's
worth
it
for
me
to
spend
time
on
this,
so
it's
it's
kind
of
a
weird
position.
Right
now.
J
J
At
this
point
he
was
so
so
his
otep
was
merged,
so
the
exemplars
is
happening
as
far
as
I
can
tell,
but
we
still
it's
not
written
into
the
spec
yet
and
originally
conor
was
saying
he
would
do
it,
but
I
imagine
he's
back
at
school
now
and
he
probably
doesn't
have
time
to
do
that
yeah,
but
other
than
that
I
mean
yeah
like
the
otep
was
merged
and
also
otlp
has
like
fields,
for
example
ours.
G
C
G
I
G
Well,
we
already
tried,
like
messaging
the
guy
for
this
one
right,
and
so
I
would
say,
like
I
would
probably
close
the
first
one
and
be
like
oh
close,
due
to
inactivity
or
something
like
that
like
like,
if
you,
if
you
want
to
take
it.
If
anyone
wants
to
take
this
on
again
like
you
could
just
like
reopen
it
or
you
know,
make
a
comment.
G
The
second
one
it
was
open
like
22
days
ago
right,
I
would
just
ping
this
guy,
just
be
like,
oh,
like
any
updates
on
the
cla
or
whatever
and
then
for
next
week.
If
there's
no
response,
we'll
just
close
it
because
next
week
it
would
be
like
a
month
so,
like
I
think,
that's
a
pretty
safe
cutoff
point.
G
It's
gotta
be
gotta,
be
gotta,
be
hard
on
these.
These
randoms
man
just
can
I
make
the
python
sig
look
like
the
the
soft.
C
K
Yeah
are
the.
C
Affect
each
other,
I
think
they're
trying
to
fix
the
same
thing
yeah
this
one.
The
only
way
that
the
only
way
they're
different
is
this
is
using
like
a
json
detail
to
flatten
the
strings.
I
think,
whereas
the
other
one
just
casts
everything
to
strings,
which
I
think
it's
fine
either
way,
it's
fine
yeah
and
the
other
pr
that's
been
sitting
open
indefinitely.
Here
is
diego's
favorite
topic
in
the
world.
G
C
D
Yes,
I.
L
D
That's
important,
I
don't
know
alex.
If
you
see
I
I
I
would
like
to
to
proceed
further
with
this
pr.
C
Yeah,
so
there
was
a
mention
of
configuration
files
at
the
spec
meeting
this
week.
I
don't
I
don't
remember
what
the
outcome
was,
but
it
was
brought
up
in
there.
G
Was
it
required
for
ga.
C
C
Oh
yeah,
sorry,
this
was
not
it
yeah
I
mean,
maybe
maybe
the
thing
to
do
here.
There
goes
to
find
out.
If
there's
any
any
talk
about
this
in
the
in
the
spec,
and
if
there
is
then
maybe
we
can
try
and
move
that
along.
I
guess
the
other
thing
is
to
determine
whether
or
not
it's
been
required
for
ga
or
not,
and
if
it's
not
recorded
yet,
then
maybe
we
just
put
this
on
the
back
burner
until
all
the
js
stuff
is
done.
G
Yeah,
I
think
realistically,
it's
not
like,
even
if
you
push
forward
it's
not
going
to
be
looked
at
until
after
first
of
all,
it's
like
not
in
the
feature
matrix
and
the
second
of
all.
During
like
the
triaging,
I
don't
recall,
seeing
it
or
any
word
it
being
brought
up
in
any
of
the
stakes.
So
it'd
be
nice
to
be.
G
You
know
brought
up
to
the
specs,
but
I
realistically
like
in
my
personal
opinion,
it
wouldn't
be
really
escalated
or
moved
along
to
a
velocity
and
which
would
be
it
would
make
sense
to
for
it
to
start
right
now.
So
it's
up
to
you.
B
B
So
mainly,
I
was
trying
to
such
as
something
that
will
allow
us
to
have
a
config
file
along
with
environment
variables
and
and
something
that
will
allow
both
to
play
nice
with
each
other.
B
On
zoom,
I
think
alex
is
looking
at
it
on
the
screen
as
well.
It's
issue
number
105.
G
G
B
G
Is
this
something
that
you
want
to
be
driving
or
something
it's
just
that
like
yeah,
I
know
where
we
should
be
like
discussing
possible.
You
know
like
implementation,
details
and
ideas,
and
whether
or
not
this
is
worth
it
in
the
issue.
It's
just
that,
like
you
know,
we've
just
been
focusing
on
ga
tasks.
Yeah.
H
G
Missed
the
meeting
like
two
weeks
ago,
yeah
yeah,
we
don't
have
the
resources
right
now
to
focus
on
anything
else.
So.
B
Yeah,
definitely
I
mean
that's,
that's
totally
on
me.
I
didn't
bring
this
up
and
get
her
and
wasn't
able
to
join
the
meetings,
but
just
like
I
just
shared
it
in
case
anyone
wants
to
to
pursue
this.
I
can
drive
it
if
we
if
we
feel
like
this
is
like
if
we
agree
on
the
proposal
or
like
I
would
like
diego
to
take
a
look
since
he
has
been
thinking
about
it,
a
lot
and
yeah.
I'm.
D
I'm
looking
at
at
least
right
now
and
it's
pretty
much-
is
the
almost
exactly
the
same
thing
that
I've
been
thinking
about.
That
is
mainly
adding
support
for
configuration
files
for
the
configuration
manager
backwards.
C
L
D
Thing
I
want
to
mention
is
that
configuration
files
will
probably
some
something
that's
going
to
be
used
in
in
every
language,
so
at
least
we
I'm
okay
with
the
implementing
hidden
python,
but
at
least
once
that
is
done.
We
should
present
it
to
the
communities
who
are
in
our
languages
can
be
aware
of
this
and.
K
All
right
moving
on
to.
C
Issues
all
right
danielle,
do
you
want
to
talk
about
this?
One.
E
I
mentioned
it
earlier,
but
that's
the
one
which
makes
the
tests
from
my
graph
pr
fail.
Basically,
the
issue
is
that
the
init
file,
that's
in
the
code
base,
isn't
packaged.
So
when
you
install
the
package,
the
internet
file
just
isn't
there
and
since
I
I'm
completely
clueless
about
packaging,
I
thought
I'd
ask
if
someone
here
is
maybe
a
bit
more
knowledgeable.
G
E
Yeah
yeah,
because
when
I
tested
it
locally
with
with
the
with
talks,
I
think
even
yeah.
It
worked,
but
oh
no
with
talks.
It
doesn't
work
but
with
the
script
the
each
disc
script
there
it
works,
but
it
doesn't
work
with
talks
when
the
package
is
installed
so
and
I
I
even
tried
pip
install
from
pipe
ui,
so
the
commands
in
in
the
reproduction,
the
fire
trust,
isn't
there.
D
Yeah,
like
I
remember
this
issue,
I
tried
reproducing
it
and
yeah.
These
results
that
you
have.
There
is
a.
D
J
E
I
I
think,
that's
what
the
issue
was
yeah,
because
it
when
yeah
exactly
my
pr,
I
tested
it
locally
with
the
each
desk
script
and
it
was
fine
and
then
I
pushed
it
and
opened
the
pull
request
and
then
the
ci
didn't
work.
So
in
tux
it
didn't
work.
G
Okay,
can
you
can
you
put
those
details
too
in
the
issue.
C
H
J
Oh
yeah,
I
put
this
wait
so
layton
posted
that
link
josh
has
been
working
on
those
sdk
metrics
spec.
I
think
we
talked
about
this
a
little
bit
last
week
and
I
saw
that
you
commented
on
his
newest
pr
layton.
I
think.
Maybe
is
it.
Do
you
think
it's
time
that
we
start
discussing
like
if
we
should
try
to
like
how
much
we
should
try
to
match
on
this?
With
regard
to
like
that,
you
know
like
accumulator
and
all
these
different
things
that
he's
talking
about.
G
Have
you
have
you
been
following
like
what
his
conversation
with
the
john
about
like
the
java
instrumentation
too,
or
the
java
repo
as
well?
Basically.
G
Yeah,
like
the
argument
right
now
is
like
a
lot
of
the
sdk
outlining
what
josh
is
doing
is
like
very
specific
ways
of
doing
something
more
specifically
like
it's,
how
the
go
sdk
is
working
and
then,
like
many
people,
similar
to
us,
has
already
implemented
the
metrics
sdk
in
a
different
way
or
like
not
using
the
same
terms
or,
like
you
know,
the
implementation
details
are
just
like
slightly
different
in
the
java
case.
I
think
there's
like
significant
changes,
especially
when
it
comes
to
this
accumulator
meter.
Separation.
G
The
other
six
that
were
smart,
I
guess,
didn't
implement
anything
at
all,
so
they
don't
have
any.
What's
it
called
like
opinions
about
how
we
should
be
able
to
do
things
because
they're
just
gonna,
listen
to
what
the
spec
says
and
do
it.
G
So
I
think
that's
the
major
thing,
that's
kind
of
like
blocking
his
pr
right
now
for
python,
like
I'm,
okay,
with
like
just
changing
and
adhering
to
whatever
the
specifications
is
or
how
it's
working
like.
That
was
the
plan.
Originally,
it's
just
that
right.
We
have
to
make
it
make
sense.
G
You
know
and
cover
all
the
use
cases
that
we've
been
coming
across
as
like
python,
consumers
have
been
complaining,
the
the
biggest
one
is
like
you
know
the
concept
of
like
stateful,
you
know-
and
I
I
still
don't
really
know
who
is
responsible
for
that
or
how
we're
gonna
be
configuring
this,
and
so
this
is
kind
of
what
we
need
to
make
sure
that
what
whatever
gosh
proposes
we'll
be
able
to
cover
our
use
cases.
So
we
don't
come
later
and
be
like
wait.
What
about
this?
You
know
like.
J
J
I
can
help
with
updating
the
python
one
or
or
proposing
changes
but
yeah.
I
agree
with
the
stateful
the
stateful
issue
and
but
I
will
say,
like
I
looked
at
java
and
I
looked
at
go
and
I
looked
at,
maybe
I
don't.
J
I
don't
think
I
looked
at
the
js
one
too,
and
they
all
seem
more
similar
to
each
other
than
the
python
one
does
I
haven't
seen
stateful
in
any
of
the
other
ones,
and
I
haven't
seen
they
all
have
like
this
metric
descriptor
yeah
that
that
they
pass
around
so
instead
of
getting
the
instrument
you
just
kind
of
get
like
a
like
a
descriptive
like
an
object
with
some
descriptions
of
it.
So
I
don't
know
so.
J
Not
not
that
I've
seen,
and
I
think
it's
more
so
if
you
see
josh's
comments
on
this
one
at
the
bottom,
I
think
he
added
something
about
cumulatives
and
deltas,
which
is
essentially
the
same
thing
right.
It
might
be
at
the
bottom.
Maybe
it
wasn't
in
here,
but
I
think
I
think
what
he's
planning
to
do
and
I'm
gonna
read
more
of
the
go
code,
but
I
think
he's
planning
to
have
it
be,
like
the
exporter
says
what
it
wants
and
then.
G
Yeah,
I
don't
exactly
know
how
it
works
yet,
but
I
think
the
go
sdk
like
have
some
sort
of
like
the
entire
pipeline
tells
like
a
story
of
what
exactly
what
the
instrument
is
supposed
to
do
and
behave
and
like
what
we
expect
from
the
exporter
instead
of
one
thing
controlling
each
piece
of
configuration.
G
So
I'm
still
not
too
clear
about
that,
but
regardless,
I
think
it's
fine
to
just
like
try
to
keep
pushing
the
specs
forward
in
in
terms
of
your
previous
question
on
like
whether
or
not
we
should
start
working
on
it.
J
I
think
are
important
that
we're
missing
so
the
main
one
being
like
the
start
and
end
times.
I've
seen
their
pass
for
sure
in
java
and
go
along
with
metric
record,
which
I
think
is
really
important
for
don't
make
a
at
least
the
google
cloud
exporter
easier,
as
well
as
the
otlp
one
from
what
I
can
tell
and
and
then
there's
also
yeah
the
statefulness
I
haven't
seen
in
any
of
the
other
ones,
but
we
can.
We
can
definitely
wait
on
that
yeah
and
maybe
my
metric
descriptor
thing.
G
Right,
yeah,
okay,
sure
yeah,
that's
fine!
I
was.
G
Of
let's
go,
I
was
just
kind
of
like
worried
that,
like
it's,
it's
like
doing
this
piecework
kind
of
thing.
It's
just
a
asking
for
like
multiple
iterations,
but
you
know,
I
guess
that's
the
theme
of
like
the
specs
anyways.
So
it's
not
a
big
deal.
J
G
Yeah
so
right
now
I'm
just
gonna
be
trying
to
push
the
specs
to
merge
and
then
maybe
start
implementing
it.
So.
G
E
Yes,
I
just
added,
because
I've
looked
at
the
pylon
repo
and
there's
no
issue
open
for
the
unresolved
part
of
this
issue.
So
I
was
wondering
if
we
are
going
to
leave
this
open
indefinitely
or
if
someone
wants
to
open
an
issue
for
pyland
or
not.
The
plan
is
because
I
assume
we
want
to
close
it
at
some
point
and
not
leave
it
open.
E
C
I
was
kind
of
expected,
like
steve
flanders,
to
open
this
issue
if
he
had
already
opened
all
of
these
other
issues.
J
E
No,
the
pull
request
replaces
the
blacklist
in
the
comments,
but
the
section
of
the
init
file
is
called
master,
which
I
think
is
the
only
one.
That's
still
open.
H
E
This
issue
doesn't
doesn't
want
us
to
do
it,
but
it
wants
us
to
replace
the
master,
or
rather
it
wants
us
to
do
something
about
pilot
having
master
in
its
in
it.
E
J
G
I
I
C
E
I
mean
that's
not
part
of
this
specific
issue,
but
right,
I
think
I
think
github
is
even
thinking
about
renaming
the
default
branch,
which
might
also
be
confusing
in
future
yep.
G
G
E
E
Well,
I
mean
you
would
think,
but
I
mean
I
guess
writes
open.
Our
repository
is
because
we
have
a
code
of
conduct
that
enforces
inclusivity,
so
there's
a
point
to
be
made
that
we
should
do
our
best
to
remove
that
kind
of
language
if
it's
deemed
not
inclusive.
D
C
Yeah,
that's
so
that's
why
I
asked
steve
to
go
back
and
open
the
nation
with
pyland.
If
there
isn't
one
I
mean
regarding
the
option
of
replacing
pilot,
I
guess
that
would
be
one
option,
but
I
don't
know
if
that's.