> Separately, I am curious what the precise symptoms of dropping Python 2.7
support will be. I admit I haven't been able to follow all the threads on
the topic. Is it moving on to newer dependencies, or also wanting to use
new language features, or something more subtle?
Once we remove Py2
Regardless of the outcome, it would be good to have some more details here.
Can you share links for people to find out more about Python 3 support in
those products and their timeline? I did some quick searching out of
curiosity but I do not believe I found the authoritative information.
I have reviewed Slack, Twitter and User@ channels [1-3] we used to
communicate our consideration to make 2.23.0 a final release supporting
Py2.
I did not see any objections or negative feedback there.
I suggest we hold a VOTE to decide whether 2.24.0 should be the final
release supporting Py2. I
The release cut date for 2.24 is in a couple of weeks; if this is the last
release supporting 2.7 we should make the call and announce it soon.
On Mon, Jul 6, 2020 at 2:26 PM Robert Bradshaw wrote:
> Note that just because Beam drops 2.x support in new releases doesn't
> mean that the old
Note that just because Beam drops 2.x support in new releases doesn't
mean that the old releases won't continue to work. One can even use an
expansion service to run 2.x transforms (on an older version of Beam)
within a Python 3 pipeline running the newest version of Beam until
such a time that
+1 for removing Python 2.7 support sooner than later.
I recently added a small feature in Beam Python and I found that having to
write code that worked with Python2 was quite awkward and time consuming
(needing to make sure code works for both 2 and 3 and doubling the Jenkins
running time), and I
Good to hear from you and good to hear the news. Release branch cut date
for 2.24 is 8/12.
On Thu, Jun 18, 2020 at 5:01 PM Chad Dombrova wrote:
> Hi all,
> Sorry I've been AWOL. I've been pulled in a number of different
> directions.
>
> We are still increasing our use of Beam, and I have it
Hi all,
Sorry I've been AWOL. I've been pulled in a number of different directions.
We are still increasing our use of Beam, and I have it on my todo list to
reach out to Kenneth about how Beam could be expanded into the VFX /
Animation industries.
Our industry uses a number of specialized
Thank you! Shared on Slack as well.
On Thu, Jun 18, 2020 at 4:33 PM Ahmet Altay wrote:
> OK, tweeted the message. Could you share on Slack?
>
> On Thu, Jun 18, 2020 at 4:28 PM Valentyn Tymofieiev
> wrote:
>
>> Alright, let's publish the message on Twitter and echo on Slack once
>> that's done.
OK, tweeted the message. Could you share on Slack?
On Thu, Jun 18, 2020 at 4:28 PM Valentyn Tymofieiev
wrote:
> Alright, let's publish the message on Twitter and echo on Slack once
> that's done.
> Thank you!
>
> On Tue, Jun 16, 2020 at 5:31 PM Ahmet Altay wrote:
>
>> That sounds reasonable to
Alright, let's publish the message on Twitter and echo on Slack once that's
done.
Thank you!
On Tue, Jun 16, 2020 at 5:31 PM Ahmet Altay wrote:
> That sounds reasonable to me. I agree, it is better to get specific
> reasons rather than a yes/no answer.
>
> On Tue, Jun 16, 2020 at 1:50 PM
That sounds reasonable to me. I agree, it is better to get specific reasons
rather than a yes/no answer.
On Tue, Jun 16, 2020 at 1:50 PM Valentyn Tymofieiev
wrote:
> After thinking about it for a bit, I am not sure whether a poll would be
> actionable. For example, if 1000 users provide a
After thinking about it for a bit, I am not sure whether a poll would be
actionable. For example, if 1000 users provide a positive response and 5
users provide a negative response, how do we interpret that and where do
we draw a line? How about instead we encourage users to reach out, and tell
On Tue, Jun 16, 2020 at 11:38 AM Valentyn Tymofieiev
wrote:
> I have reached out to user@ for feedback on Python 3 migration[1].
>
Maybe also ask on slack? There are quite a bit of users there as well.
>
> Could somebody from PMC please help with Twitter poll?
>
I can try to do this. What
I have reached out to user@ for feedback on Python 3 migration[1].
Could somebody from PMC please help with Twitter poll?
Technically, we can proceed with the change between 2.23.0 and 2.24.0, so
that's after 2.23.0 is cut and we give sufficient time for users to
respond.
[1]
Yes we need to poll this outside as Robert proposed.
The proposed last support version corresponds with the next release that will be
cut in two weeks. Sounds a bit short if we count the time to poll people on this
subject but still could be.
I remember Chad mentioned in this thread the
I like that option as a concrete proposal. I think we should circulate it
more widely (the users list, twitter poll, at least a new thread...), maybe
phrasing it as "is there any reason you couldn't migrate to Python 3 (or
stick with an older version of Beam) after 2.23 (due to be cut here in a
+1
On Mon, Jun 15, 2020 at 6:52 PM Udi Meiri wrote:
> +1
>
> On Mon, Jun 15, 2020 at 4:27 PM Ahmet Altay wrote:
>
>> As a concrete proposal, could we commit to removing python 2 support by
>> 2.24? In other words, mark the next release 2.23 as the last python 2
>> compatible Beam version.
>>
+1
On Mon, Jun 15, 2020 at 4:27 PM Ahmet Altay wrote:
> As a concrete proposal, could we commit to removing python 2 support by
> 2.24? In other words, mark the next release 2.23 as the last python 2
> compatible Beam version.
>
> On Mon, Jun 15, 2020 at 2:09 PM Valentyn Tymofieiev
> wrote:
>
As a concrete proposal, could we commit to removing python 2 support by
2.24? In other words, mark the next release 2.23 as the last python 2
compatible Beam version.
On Mon, Jun 15, 2020 at 2:09 PM Valentyn Tymofieiev
wrote:
> Another input here:
>
> If you opened a Python PR in the last few
Another input here:
If you opened a Python PR in the last few days, you probably noticed that
our test suites were broken by a transitive dependency of Beam that dropped
python 2 support, but did not declare python_requires>=3 in its setup.py
[1]. This temporarily broke a subset of Beam Py2 users
Thank you for re-opening this Valentyn. I am in favor of EOLing py2 support
sooner than later. The reality is that we will not be effectively
supporting beam python 2 for a long time while the ecosystem already EOLed
python 2. That said, a significant chunk (but no longer a majority) of our
users
Back at the end of February we decided to revisit this conversation in 3
months. Do folks on this thread have any new input or perspective regarding
us balancing "user pain/contributor pain/our ability to continuously test
with python 2 in a shifting environment"?
Some new information on my end
That's good news! Thanks for sharing.
Another datapoint, here are a few of Beam's dependencies that no longer
release new py2 artifacts (I looked at REQUIRED_PACKAGES + aws, gcp, and
interactive extras):
hdfs
numpy
pyarrow
ipython
There are more if we include transitive dependencies and
It hasn't been 3 months yet, but I wanted to call out a milestone that
Python 3 downloads crossed the 50% threshold on pypi, if just briefly.
On Thu, Feb 13, 2020 at 12:40 AM Ismaël Mejía wrote:
>
> > I would suggest re-evaluating this within the next 3 months again. We need
> > to balance
> I would suggest re-evaluating this within the next 3 months again. We
need to balance between user pain/contributor pain/our ability to
continuously test with python 2 in a shifting environment.
Good idea for the in 3 months evaluation, at that point also distributions
will probably be phasing
On Wed, Feb 12, 2020 at 1:29 AM Ismaël Mejía wrote:
> I am with Chad on this, we should probably extend it a bit more, even if it
> makes us struggle a bit at least we have some workarounds as Robert
> suggests,
> and as Chad said there are still many people playing the python 3 catchup
> game,
I am with Chad on this, we should probably extend it a bit more, even if it
makes us struggle a bit at least we have some workarounds as Robert
suggests,
and as Chad said there are still many people playing the python 3 catchup
game,
so worth to support those users.
But maybe it is worth to
On Tue, Feb 4, 2020 at 12:12 PM Chad Dombrova wrote:
>>
>> Not to mention that all the nice work for the type hints will have to be
>> redone in the for 3.x.
>
> Note that there's a tool for automatically converting type comments to
> annotations: https://github.com/ilevkivskyi/com2ann
>
> So
>
>
> Not to mention that all the nice work for the type hints will have to be
> redone in the for 3.x.
>
Note that there's a tool for automatically converting type comments to
annotations: https://github.com/ilevkivskyi/com2ann
So don't let that part bother you.
I'm curious what other
For reference, this was last discussed in September [1]. I agree, that it
is a good time to re-think about this, and I also lean towards deprecating
sooner.
/cc +Valentyn Tymofieiev +Robert Bradshaw
+Chad
[1]
31 matches
Mail list logo
