Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #94800 > unrolled thread

GvR Europython keynote described on lwn.net

Back to article view | Back to comp.lang.python

Contents

  GvR Europython keynote described on lwn.net Paul Rubin <no.email@nospam.invalid> - 2015-07-30 23:33 -0700
    Re: GvR Europython keynote described on lwn.net Rustom Mody <rustompmody@gmail.com> - 2015-07-31 00:16 -0700
    Re: GvR Europython keynote described on lwn.net Rick Johnson <rantingrickjohnson@gmail.com> - 2015-07-31 20:08 -0700
      Re: GvR Europython keynote described on lwn.net Steven D'Aprano <steve@pearwood.info> - 2015-08-01 15:45 +1000
        Re: GvR Europython keynote described on lwn.net Rick Johnson <rantingrickjohnson@gmail.com> - 2015-08-01 11:57 -0700
          Re: GvR Europython keynote described on lwn.net Steven D'Aprano <steve@pearwood.info> - 2015-08-02 18:04 +1000
            Re: GvR Europython keynote described on lwn.net Rick Johnson <rantingrickjohnson@gmail.com> - 2015-08-02 15:34 -0700
              Re: GvR Europython keynote described on lwn.net Chris Angelico <rosuav@gmail.com> - 2015-08-03 09:25 +1000
                Re: GvR Europython keynote described on lwn.net Rick Johnson <rantingrickjohnson@gmail.com> - 2015-08-02 17:14 -0700
              Re: GvR Europython keynote described on lwn.net Steven D'Aprano <steve@pearwood.info> - 2015-08-03 11:27 +1000
                Re: GvR Europython keynote described on lwn.net Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-08-03 04:10 +0100
                Re: GvR Europython keynote described on lwn.net Chris Angelico <rosuav@gmail.com> - 2015-08-03 14:15 +1000

#94800 — GvR Europython keynote described on lwn.net

https://lwn.net/Articles/651967/

Excerpts:

He then moved on to Python 3.5, which is due in September. He would have
trouble choosing a favorite feature from the release because there are
"way too many cool things" in it....  Perhaps his favorite 3.5 feature
should be type hints, since it is a PEP he worked on himself. It took a
lot of work for the PEP to get accepted, which is a little bizarre since
he is the benevolent dictator for life (BDFL) and could accept his own
PEP. But he wanted to have independent review and acceptance of the PEP,
which Mark Shannon was graciously willing to provide as the BDFL
delegate, he said.  ... If you caught him unaware, though, he probably
would name the new async and await keywords for coroutines as his
favorite. It was the last PEP accepted for 3.5 and it provides a more
natural way of specifying coroutines.

...

[regarding age of bugs in Python bug tracker]

If you pick any bug at random, including closed bugs, you would likely
get a closed bug. Many bugs are closed quickly and bugs that are easy to
fix tend to get fixed quickly. But the average lifetime of an open bug
grows linearly with the age of the project, he said.

[On designing a new language, and the GIL]

If you were to design a new language today, he said, you would make it
without mutable (changeable) objects, or with limited mutability. From
the audience, though, came: "That would not be Python." Van Rossum
agreed: "You took the words out of my mouth." There are various ongoing
efforts to get around the GIL, including the PyPy software transactional
memory (STM) work and PyParallel. Other developers are also "banging
their head against that wall until it breaks". If anyone has ideas on
how to remove the GIL but still keep the language as Python, he (and
others) would love to hear about it.  

[PyPy, and how GvR and Dropbox use Python]

He was asked about PyPy, whether he used it and whether it might someday
become the default interpreter. He does not use PyPy, but he does
download it once in a while, plays with it for a few minutes, and likes
what he sees. He uses Python in two modes, either writing a short little
script to get something done, for which he just uses one of the
interpreters he already has built on his system, or as a Dropbox
engineer deploying Python code to its cluster.

The Dropbox cluster runs a modified Python 2.7, he said, which elicited
audience laughter. "I said it, it is no secret", he said.

[Favorites]

Five short questions about his favorites was up next. Favorite web
framework? He said he only writes one web app in any framework and that
the last he tried was Flask. Favorite testing library? He mostly just
uses unittest and mock from the standard library. Editor? He uses Emacs,
but started out with vi (both of which were greeted with applause,
presumably by different sets of audience members). He still uses vi (or
Vim) occasionally, but if he does that for five minutes, it takes him
fifteen minutes to get used to Emacs again.

[Anti-favorites]

The final question was about what he hates in Python. "Anything to do
with package distribution", he answered immediately. There are problems
with version skew and dependencies that just make for an "endless
mess". He dreads it when a colleague comes to him with a "simple Python
question". Half the time it is some kind of import path problem and
there is no easy solution to offer.

[toc] | [next] | [standalone]

#94801

On Friday, July 31, 2015 at 12:03:36 PM UTC+5:30, Paul Rubin wrote:
> The final question was about what he hates in Python. "Anything to do
> with package distribution", he answered immediately. There are problems
> with version skew and dependencies that just make for an "endless
> mess". He dreads it when a colleague comes to him with a "simple Python
> question". Half the time it is some kind of import path problem and
> there is no easy solution to offer.

Heh! I'm in good company!

[toc] | [prev] | [next] | [standalone]

#94824

On Friday, July 31, 2015 at 1:33:36 AM UTC-5, Paul Rubin wrote:
> The Dropbox cluster runs a modified Python 2.7, he said, which 
> elicited audience laughter. "I said it, it is no secret", he said.

Yep, even the BDFL is actively developing in 2.7! He's no fool.

[toc] | [prev] | [next] | [standalone]

#94828

On Sat, 1 Aug 2015 01:08 pm, Rick Johnson wrote:

> On Friday, July 31, 2015 at 1:33:36 AM UTC-5, Paul Rubin wrote:
>> The Dropbox cluster runs a modified Python 2.7, he said, which
>> elicited audience laughter. "I said it, it is no secret", he said.
> 
> Yep, even the BDFL is actively developing in 2.7! He's no fool.

Of course not. Dropbox pay him to work on their systems, and he wants to
keep his job.

Are you aware that Dropbox are heavily pushing for static type hints in
Python 3 as a prerequisite for them porting their masses of Python 2 code
to Python 3? That's one of the motives for the masses of effort put into
PEP 484, and its support PEPs, 482 and 483:

https://www.python.org/dev/peps/pep-0484/
https://www.python.org/dev/peps/pep-0483/
https://www.python.org/dev/peps/pep-0482/

As I understand it, Dropbox are paying Guido to work on static type hinting
for Python, with the emphasis on proving program correctness, not speed,
specifically because they want a big positive gain for moving to Python 3.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#94853

On Saturday, August 1, 2015 at 12:45:45 AM UTC-5, Steven D'Aprano wrote:

> > Yep, even the BDFL is actively developing in 2.7! He's no fool.
> 
> Of course not. Dropbox pay him to work on their systems,
> and he wants to keep his job.

Thanks for confirming my point that Python3 is not worth
developing with for at least the next five years.

> Are you aware that Dropbox are heavily pushing for static
> type hints in Python 3 as a prerequisite for them porting
> their masses of Python 2 code to Python 3? 

Well then, i hope they are ready to wait at least 10 years
before adopting Python3, because it will take that long to
work out all the kinks! Of course, with the cloud service
wars heating up, no one can be sure how long any of them
will survive. Web technology is moving much faster than 
Python.

> That's one of the motives for the masses of effort put
> into PEP 484, and its support PEPs, 482 and 483:

I do find it flattering that many of my ideas regarding
Python have been implemented: (1) It was me who recommended
"optional type checking" way back around 2008 (Heck, you
even agreed that it would be a good idea, but at the time, a
moratorium was preventing new features) (2) The fresher look
of Python.org is a result of my suggestions (3) The
interactive online console was my idea to compete with the
Ruby equivalent (4) I have pestered tutorial owners to
upgrade their tutorials to py3 compatibility, and many did!
(5) and last but not least, my courage to face down the
trolls has given courage to the shadow lurkers, who now
participate in open discussions on this list, and some have
even moved over to more dangerous grounds like Python-ideas.
All in all, my presence here has resulted in a fundamental
transformation of this group, and this language.

> As I understand it, Dropbox are paying Guido to work on
> static type hinting for Python, with the emphasis on
> proving program correctness, not speed, specifically
> because they want a big positive gain for moving to Python
> 3.

Well it's true that reducing bugs should always be
preferable to speed, but once the error potentials are
reduced, Dropbox will no doubt pivot to performance
enhancements -- this is the nature of our universe.

[toc] | [prev] | [next] | [standalone]

#94890

On Sun, 2 Aug 2015 04:57 am, Rick Johnson wrote:

> On Saturday, August 1, 2015 at 12:45:45 AM UTC-5, Steven D'Aprano wrote:
> 
>> > Yep, even the BDFL is actively developing in 2.7! He's no fool.
>> 
>> Of course not. Dropbox pay him to work on their systems,
>> and he wants to keep his job.
> 
> Thanks for confirming my point that Python3 is not worth
> developing with for at least the next five years.

If Dropbox were using Python 1.5, would you conclude that Python 2 was not
worth developing in? I happen to know that at last year's US PyCon there
was at least one company still using Python 1.5. If it works for them, and
they don't need security updates, why not? But this doesn't mean others
should emulate them.

As Laura has explained, there is at least one sector of Python users that
not only doesn't want new features, but they don't want bug fixes either.
They would rather work around bugs themselves, and stability is more
important than correctness. If that works for them, great. But it doesn't
work for everyone.

Just because company X is using 2.7, why does that mean that *you* shouldn't
using 3.x? Surely you should make your own decision, based on your own
needs.

(For the record, Dropbox isn't using Python 2.7. They're using a heavily
customized private implementation of Python based on, but not the same as,
version 2.7. Whatever benefits they get from using that, I can promise that
*you* will not be getting them from the vanilla version of 2.7 available to
the public.)
 

>> Are you aware that Dropbox are heavily pushing for static
>> type hints in Python 3 as a prerequisite for them porting
>> their masses of Python 2 code to Python 3?
> 
> Well then, i hope they are ready to wait at least 10 years
> before adopting Python3, because it will take that long to
> work out all the kinks! 

Nonsense. You can already download mypy and start using static type checking
in Python today.


> Of course, with the cloud service 
> wars heating up, no one can be sure how long any of them
> will survive. Web technology is moving much faster than
> Python.
> 
>> That's one of the motives for the masses of effort put
>> into PEP 484, and its support PEPs, 482 and 483:
> 
> I do find it flattering that many of my ideas regarding
> Python have been implemented: (1) It was me who recommended
> "optional type checking" way back around 2008 

Don't flatter yourself. People have been suggesting type checking for Python
since Python 0.1.



> (Heck, you 
> even agreed that it would be a good idea, but at the time, a
> moratorium was preventing new features) (2) The fresher look
> of Python.org is a result of my suggestions

So you're the one to blame for the horrible new design and the reliance on
Javascript to create an overall worse user experience? I'd call the new
design a triumph of style over substance, except that the new style is
worse than the old one.


> (3) The 
> interactive online console was my idea to compete with the
> Ruby equivalent (4) I have pestered tutorial owners to
> upgrade their tutorials to py3 compatibility, and many did!
> (5) and last but not least, my courage to face down the
> trolls has given courage to the shadow lurkers, who now
> participate in open discussions on this list, and some have
> even moved over to more dangerous grounds like Python-ideas.

So you're the one to blame for all the bike-shedding from people who think
that copying design principles from PHP is a great idea?

Please stop "helping".



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#94903

On Sunday, August 2, 2015 at 3:05:09 AM UTC-5, Steven D'Aprano wrote:

> If Dropbox were using Python 1.5, would you conclude that
> Python 2 was not worth developing in? 

No, if Dropbox were using py1.5, i would conclude that it was
being managed by monkeys -- since Py1.5 existed before
Dropbox was even founded (in 2007).

> I happen to know that at last year's US PyCon there was at
> least one company still using Python 1.5. If it works for
> them, and they don't need security updates, why not? But
> this doesn't mean others should emulate them.

Same answer, if they were using py1.5 "when it was hot", and
it still works for them today, why bother with backwards
incompatibility. They can hack 1.5 if they need to, it's
open source after all!

> As Laura has explained, there is at least one sector of
> Python users that not only doesn't want new features, but
> they don't want bug fixes either. They would rather work
> around bugs themselves, and stability is more important
> than correctness. If that works for them, great. But it
> doesn't work for everyone.

Does the word "reiterate" mean anything to you?

> Just because company X is using 2.7, why does that mean
> that *you* shouldn't using 3.x? Surely you should make
> your own decision, based on your own needs.

It's not just *ANY* company Steven, it's Guido's freaking
employer! That would imply that even GvR himself is not
motivated enough by 3000 to fight for it's adoption. More 
evidence that py3000 is not ready for mass consumption.

> (For the record, Dropbox isn't using Python 2.7. They're
> using a heavily customized private implementation of
> Python based on, but not the same as, version 2.7.
> Whatever benefits they get from using that, I can promise
> that *you* will not be getting them from the vanilla
> version of 2.7 available to the public.)

So what? If i had to guess, i would guess that the hacks are
mostly to bring py3000 features to 2.7 without suffering the
ill effects that the py3000 recipe of: "excessive backwards
incompatibility spicing" has had on the consumption of py3000.

We don't like your spicy sauce, Swedish Chef!

  https://www.youtube.com/watch?v=SGZPlvbhMIg

And if you folks think it burns at runtime, just wait until the 
exceptions are ejected!

[toc] | [prev] | [next] | [standalone]

#94905

On Mon, Aug 3, 2015 at 8:34 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Sunday, August 2, 2015 at 3:05:09 AM UTC-5, Steven D'Aprano wrote:
>
>> If Dropbox were using Python 1.5, would you conclude that
>> Python 2 was not worth developing in?
>
> No, if Dropbox were using py1.5, i would conclude that it was
> being managed by monkeys -- since Py1.5 existed before
> Dropbox was even founded (in 2007).

I have a git repository on my hard disk with commits dating back to
August 1995. That's clearly being managed by monkeys, because git
repositories can't exist before git was founded (2005), right? Well,
actually, this particular repo was started in CVS, then imported from
there into SVN, and thence into git more recently. Suppose Dropbox
(the company) inherited a codebase from an older company, which itself
inherited it from someone else - maybe they could be all set up with a
codebase that pre-existed them by a decade.

>> Just because company X is using 2.7, why does that mean
>> that *you* shouldn't using 3.x? Surely you should make
>> your own decision, based on your own needs.
>
> It's not just *ANY* company Steven, it's Guido's freaking
> employer! That would imply that even GvR himself is not
> motivated enough by 3000 to fight for it's adoption. More
> evidence that py3000 is not ready for mass consumption.

Wind the clock back to 2012, when Guido was working for Google.
Dropbox wants him. Is he going to refuse the job unless they *first*
get onto Py3, or is he going to accept the job with a view to
migrating them?

The only form of "fight[ing] for it[']s adoption" that you seem to be
advocating here is an rms-style "if it isn't what I believe in, let it
sink like the Titanic". That's not the only way to encourage
something.

ChrisA

[toc] | [prev] | [next] | [standalone]

#94906

On Sunday, August 2, 2015 at 6:25:37 PM UTC-5, Chris Angelico wrote:
> Wind the clock back to 2012, when Guido was working for Google.
> Dropbox wants him. Is he going to refuse the job unless they *first*
> get onto Py3, or is he going to accept the job with a view to
> migrating them?

Well, i don't know the specifics of why he departed from a
global and mature company for a small (although promising)
startup, but i do know that there is always the possibility
that Google will sweep in and consume Dropbox if it becomes
a threat or shows *real* potential. So there is always the
possibility that he could be working at Google again; albeit
in a "field office".

Don't play coy Chris, you know damn good and well how this
game is played, and you know that the founders of any
startup dream of a buyout so they can sail off into the
proverbial sunset. GvR is a pawn in a greater game. But we
are all pawns in one form or another; are we not?

He is but a small part of an industrious and creative young
enterprise that will quickly become consumed by one of the
powerful corporations, and for no other reason than to
smother its competition in the cradle! Large corporations
are where innovations go to die. Where spontaneity is slowly
tortured to death inside the confining walls of a cubicle,
and magnificent intellectual achievements are converted into
cheap, plastic, soulless, *TRINKETS* that are purposefully 
designed for early failure in order to achieve maximum 
profitability! 

[toc] | [prev] | [next] | [standalone]

#94911

On Mon, 3 Aug 2015 08:34 am, Rick Johnson wrote:

>> Just because company X is using 2.7, why does that mean
>> that *you* shouldn't using 3.x? Surely you should make
>> your own decision, based on your own needs.
> 
> It's not just *ANY* company Steven, it's Guido's freaking
> employer! That would imply that even GvR himself is not
> motivated enough by 3000 to fight for it's adoption. More
> evidence that py3000 is not ready for mass consumption.

No, it's evidence that *Dropbox* is not ready for Python 3.x. It tells you
ABSOLUTELY NOTHING about the suitability of Python 3.x for other companies
and other users.

Despite your earlier snarky comment about "reiterate", it is clear that you
still don't get it, so I'll say it again. There is nothing wrong with
individuals or companies choosing to stay with Python 2.7, or 2.6, or 2.5,
or 1.5, if it meets their needs. GvR doesn't need to "fight" for Python 3's
adoption.

He works for a company where, *right now*, a customised version of 2.7 meets
their needs. That doesn't mean that other companies aren't ready for 3.x,
and it doesn't mean that Dropbox aren't preparing for 3.x. They are.

You might think that they could just turn around tomorrow and say, "Right,
as of tomorrow we're using Python 3 for new projects", but that's not how
it works when you're a company running Python on hundreds, maybe thousands
of production servers, all of which will need to have Python replaced
*while running live* before the change over.


>> (For the record, Dropbox isn't using Python 2.7. They're
>> using a heavily customized private implementation of
>> Python based on, but not the same as, version 2.7.
>> Whatever benefits they get from using that, I can promise
>> that *you* will not be getting them from the vanilla
>> version of 2.7 available to the public.)
> 
> So what? If i had to guess, i would guess that the hacks are
> mostly to bring py3000 features to 2.7 

These would be the features of Python 3 that nobody needs and nobody wants
because Python 2 is good enough for everyone?

I wouldn't want to guess what the customizations do.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#94915

On 03/08/2015 02:27, Steven D'Aprano wrote:
> On Mon, 3 Aug 2015 08:34 am, Rick Johnson wrote:
>
>> So what? If i had to guess, i would guess that the hacks are
>> mostly to bring py3000 features to 2.7
>
> These would be the features of Python 3 that nobody needs and nobody wants
> because Python 2 is good enough for everyone?
>
> I wouldn't want to guess what the customizations do.
>

Is there actually a definitive list of goodies that were backported from 
3.x to 2.6 or 2.7?  Of course some bits and pieces are still being 
backported to 2.7.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#94917

On Mon, Aug 3, 2015 at 1:10 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 03/08/2015 02:27, Steven D'Aprano wrote:
>>
>> On Mon, 3 Aug 2015 08:34 am, Rick Johnson wrote:
>>
>>> So what? If i had to guess, i would guess that the hacks are
>>> mostly to bring py3000 features to 2.7
>>
>>
>> These would be the features of Python 3 that nobody needs and nobody wants
>> because Python 2 is good enough for everyone?
>>
>> I wouldn't want to guess what the customizations do.
>>
>
> Is there actually a definitive list of goodies that were backported from 3.x
> to 2.6 or 2.7?  Of course some bits and pieces are still being backported to
> 2.7.

You could probably find a definitive list of *language* features that
got backported. Trying to find a full list of the *modules* that got
backported will be harder, as they're not a part of Python 2.7 as such
(the backports are on PyPI instead) - and some of them have slightly
different names, too.

ChrisA

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web